Per-BSP confdefs (or resource allocation)

[Joel Sherrill]

On 10/22/2015 9:42 AM, Isaac Gutekunst wrote:
>
>
> On 10/22/2015 10:30 AM, Joel Sherrill wrote:
>>
>>
>> On 10/22/2015 8:55 AM, Isaac Gutekunst wrote:
>>> On 10/22/2015 01:33 AM, Sebastian Huber wrote:
>>>>
>>>>
>>>> On 21/10/15 21:53, Isaac Gutekunst wrote:
>>>>> Hi Devel,
>>>>>
>>>>> I looked for a while, but couldn't find a way to specify what resources (semaphores, tasks,
>>>>> etc) a BSP requires for an empty project (empty Init function).
>>>>
>>>> There is no useful support for this and this is a constant source of problems.
>>>>
>>>> One way out of this situation would be to use self-contained objects for the drivers.
>>>>
>>>>>
>>>>> I took a look at this page:
>>>>> https://docs.rtems.org/doc-current/share/rtems/html/bsp_howto/Initialization-Code-The-RTEMS-Configuration-Table.html
>>>>>
>>>>> but couldn't glean the correct method.
>>>>>
>>>>> What is the preferred way to do so?
>>>>>
>>>>> Our BSP uses a number of resources for hardware drivers, including UART, CAN, SPI, I2C and
>>>>> Ethernet.
>>>>>
>>>>>
>>>>
>>>> In case an empty project includes all these drivers, then something is wrong with this BSP.
>>>>
>>> That's good to know. Is it advisable to have all the drivers disabled by default? Of course, at
>>> minimum a BSP needs a console driver.
>>
>> Technically a BSP doesn't even need that. Many applications field without one.
>> The clock tick is technically also optional but that is almost universally required
>> by applications. The minimum BSP technically only needs to startup and shutdown.
>>
>> But if you want to link/run all the tests, you need a console, clock tick, and
>> benchmark timer driver.
>>
>> I have seen bspstart.c or other initialization files pull in more than minimum
>> required. I have also seen bugs in Makefile.am that result in the entire BSP
>> being a binary blob always linked in.
> I'm not sure whether our Makefile.am is done correctly. As we move forward with getting it
> merged into mainline, I'm sure we'll get some useful feedback.
>
>>
>>> Our console driver does use one task, and one or more mutexes. Is this something we should try
>>> hard to change?
>>
>> Why does it use so many resources? The termios framework provides all the
>> buffering internally and confdefs.h accounts for them.
>
> I was a bit confused. Talking to Jay and looking at the code, the termios console does not use
> any additional kernel resources.
>
> We do use additional resources to expose serial ports via a raw interface (IMFS) to bypass the
> termios overhead. The kernel drivers for these are still in our branch, not mainline.
>
>
> It looks like for our case, the two areas that use additional resources are for two new "device
> classes", CAN and raw UART that aren't present in the kernel. If we get these new drivers
> merged into the RTEMS kernel at some point (perhaps after living in the BSP for a while, to
> shake out bugs), we can update confdefs.h to account for those resources since at that point,
> they will have the potential to be used in other BSPs.

If you are adding a CAN framework, that makes sense to add to confdefs.h as
a driver like console or clock or IDE.

But I don't understand the need for a raw UART driver. You can put termios
in raw mode and avoid a lot of overhead. You can also use line disciplines
to avoid the termios default one. This is a standard POSIX feature.

Disclaimer: Ensuring the default line discipline is completely pluggable
has not been addressed. If you had a system with no console and only
a custom line discipline, right now you would very likely pick up all
the termios default line discipline code.  This might be a desirable
modification. We haven't looked at termios AFAIK from a code space
saving perspective.

--joel