Undocumented configuration options

[Sebastian Huber]

On 31/03/2020 10:14, Chris Johns wrote:

> On 2020-03-31 00:51, Joel Sherrill wrote:
>> On Mon, Mar 30, 2020 at 8:39 AM Sebastian Huber 
>> <sebastian.huber at embedded-brains.de 
>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>
>>     On 30/03/2020 15:35, Joel Sherrill wrote:
>>
>>>         What about the
>>>
>>>         CONFIGURE_FILESYSTEM_ENTRY_DEVFS
>>>         CONFIGURE_FILESYSTEM_ENTRY_DOSFS
>>>         CONFIGURE_FILESYSTEM_ENTRY_FTPFS
>>>         CONFIGURE_FILESYSTEM_ENTRY_IMFS
>>>         CONFIGURE_FILESYSTEM_ENTRY_JFFS2
>>>         CONFIGURE_FILESYSTEM_ENTRY_NFS
>>>         CONFIGURE_FILESYSTEM_ENTRY_RFS
>>>         CONFIGURE_FILESYSTEM_ENTRY_TFTPFS
>>>
>>>         configuration options? Is this really something a user should
>>>         be able to
>>>         define?
>>>
>>>
>>>     Chris will likely chime in later but I believe these are needed so
>>>     that
>>>     filesystem type is listed in the set of mountable filesystems. 
>>>     The mount
>>>     command depends on those settings.
>>
>>     Yes, it depends on the settings, but the
>>     CONFIGURE_FILESYSTEM_ENTRY_* options give you an extra level of
>>     control. For example, you can enable the RFS with:
>>
>>     #define CONFIGURE_FILESYSTEM_ENTRY_RFS
>>
>>     Optionally, you can fine tune the entry:
>>
>>     #if defined(CONFIGURE_FILESYSTEM_RFS) \
>>        && !defined(CONFIGURE_FILESYSTEM_ENTRY_RFS)
>>        #define CONFIGURE_FILESYSTEM_ENTRY_RFS \
>>          { RTEMS_FILESYSTEM_TYPE_RFS, rtems_rfs_rtems_initialise }
>>     #endif
>>
>>     I am not sure if this fine tuning is really necessary.
>>
>>
>> Me either. Looks like a way for someone to provide their own
>> version of the definition which seems in the class of defining your
>> own Configuration Table structures. And we removed those.
>>
>> Let's wait for Chris. :)
>
> This dates back to 2010 [1] and I suspect I was attempting to follow 
> the way confdefs tables were defined then. Anything that makes things 
> simpler is good. 

Ok, good. Here is a patch which removes these configuration options:

https://lists.rtems.org/pipermail/devel/2020-March/058782.html

I will now start to document the following options:

CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER
CONFIGURE_APPLICATION_NEEDS_IDE_DRIVER
CONFIGURE_ATA_DRIVER_TASK_PRIORITY
CONFIGURE_CBS_MAXIMUM_SERVERS
CONFIGURE_DISABLE_NEWLIB_REENTRANCY
CONFIGURE_EXECUTIVE_RAM_SIZE
CONFIGURE_EXTRA_MPCI_RECEIVE_SERVER_STACK
CONFIGURE_FILESYSTEM_ALL
CONFIGURE_FILESYSTEM_DEVFS
CONFIGURE_FILESYSTEM_DOSFS
CONFIGURE_FILESYSTEM_FTPFS
CONFIGURE_FILESYSTEM_IMFS
CONFIGURE_FILESYSTEM_JFFS2
CONFIGURE_FILESYSTEM_NFS
CONFIGURE_FILESYSTEM_RFS
CONFIGURE_FILESYSTEM_TFTPFS
CONFIGURE_IMFS_DISABLE_MKNOD_DEVICE
CONFIGURE_MALLOC_DIRTY
CONFIGURE_MAXIMUM_POSIX_SHMS
CONFIGURE_SCHEDULER_ASSIGNMENTS
CONFIGURE_SCHEDULER_STRONG_APA
CONFIGURE_TASK_STACK_ALLOCATOR_AVOIDS_WORK_SPACE
CONFIGURE_TASK_STACK_FROM_ALLOCATOR

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200331/8b218b79/attachment-0001.html>