Some problems with the libbsd update

[Sebastian Huber]

On 24/08/18 04:13, Chris Johns wrote:
> 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.

Could you then please make suggestions what should be placed where? Is 
the User Manual the landing point for users? This information could be 
added here:

https://docs.rtems.org/branches/master/user/bsps/index.html

>
>> 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.

My current itch is that I want to move forward with the libbsd and not 
be burdened with work for obsolete and unmaintained architectures which 
will very likely never use libbsd.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.