Some problems with the libbsd update

[Chris Johns]

On 23/08/2018 23:54, Sebastian Huber wrote:
> On 23/08/18 15:40, Joel Sherrill wrote:
>> On Thu, Aug 23, 2018 at 12:15 AM, Sebastian Huber
>> <sebastian.huber at embedded-brains.de
>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>
>>     On 23/08/18 01:13, Joel Sherrill wrote:
>>
>>
>>
>>         On Wed, Aug 22, 2018 at 6:00 PM, Chris Johns <chrisj at rtems.org
>>         <mailto:chrisj at rtems.org> <mailto:chrisj at rtems.org
>>         <mailto:chrisj at rtems.org>>> wrote:
>>
>>             On 22/08/2018 22:25, Sebastian Huber wrote:
>>             > On 22/08/18 14:06, Joel Sherrill wrote:
>>             >> On Wed, Aug 22, 2018, 6:47 AM Sebastian Huber
>>             >> <sebastian.huber at embedded-brains.de
>>         <mailto:sebastian.huber at embedded-brains.de>
>>             <mailto:sebastian.huber at embedded-brains.de
>>         <mailto:sebastian.huber at embedded-brains.de>>
>>             >> <mailto:sebastian.huber at embedded-brains.de
>>         <mailto:sebastian.huber at embedded-brains.de>
>>             <mailto:sebastian.huber at embedded-brains.de
>>         <mailto:sebastian.huber at embedded-brains.de>>>> wrote:
>>             >>
>>             >> It really is necessary to know how the other
>>         architectures implement it. Some
>>             >> may turn out to be easy. Others like Epiphany and new
>>         may never
>>             matter.
>>             >
>>             > If the niche architectures don't use libbsd (which I
>>         guess is
>>             the case), then
>>             > there is no issue at all.
>>             >
>>
>>             Do we document what is supported and what is not supported?
>>
>>
>>         This was largely the point of my response. We don't have a
>>         master list of
>>         at least the following information:
>>
>>         + Architectures that support SMP and tested to N cores
>>         + Architectures that support TLS
>>
>>
>>     We have the CPU Supplement.
>>
>>
>> You seem to be missing my point entirely. I am not saying the information
>> is not available at all. I am saying that there is no central place that
>> captures the status of SMP, TLS, libbsd for all architectures. This is
>> a marketing and project planning issue -- not a per-architecture
>> documentation issue.
> 
> The central place for SMP and TLS support is the CPU Supplement.

That is a little harsh on a new user. It is the right place, there is no
argument about that, however Joel's point is about collating this and other
similar info like libbsd into a simplified view is valid. It may duplicate the
info but that is a small price to pay.

> The libbsd has its own set of documentation files where you could add this
> information.
> 
>>
>> From a new user's perspective, where do they get the easy answer
>> to what's supported on what architectures?
> 
> Everyone is free to ask questions on the mailing lists. 

... and they are free to keep on walking past RTEMS rather than the hassle of
joining a mailing list. Mail is not as popular in the youth as it use to be.

We need to improve how we interact with our users and to make the entry path as
easy as we can. We have come a long way in the past 15 years but we have much
more we can do.

> We have now the mostly
> empty chapter with BSPs in the User Manual. You could also add some information
> here. The question is who has time/budget to do this?

There is all the time in the world and no budget so may I suggest we move terms
like "time/budget" to one side. This is an open source project with a great
community, some parts move in a timely manner and other parts do not. If you
have an itch scratch it.

>>
>> From the perspective of someone looking for a project, where's the
>> list of things that need to be done?
>>
>> From the perspective of considering deprecating an architecture,
>> support for TLS could be a factor. Without a master list to check
>> against, there is no easy answer.
>>
>> Master list unfortunately needs to exist in two forms:
>>
>> + the marketing view which is likely a table.
>> + the project planning view which is well served by a set
>> of tickets to add TLS per architecture.
> 
> Who will work on these tickets? We already have more than hundred tickets which
> are open for a long time. I am not sure if its worth to add more tickets which
> nobody will fix.

Does it matter how many there are, this is not a product? Does having 0 mean we
are finished and have nothing more to do? :) We use tickets to track open tasks
and projects, I hope we always have a number open.

Chris