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.hu...@embedded-brains.de
<mailto:sebastian.hu...@embedded-brains.de>> wrote:
On 23/08/18 01:13, Joel Sherrill wrote:
On Wed, Aug 22, 2018 at 6:00 PM, Chris Johns <chr...@rtems.org
<mailto:chr...@rtems.org> <mailto:chr...@rtems.org
<mailto:chr...@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.hu...@embedded-brains.de
<mailto:sebastian.hu...@embedded-brains.de>
<mailto:sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@embedded-brains.de>>
>> <mailto:sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@embedded-brains.de>
<mailto:sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
