[PATCH] Update FreeBSD kernel timespec support

2018-08-23 Thread Sebastian Huber 
This change is based on the following FreeBSD commit:

"Make timespecadd(3) and friends public

The timespecadd(3) family of macros were imported from NetBSD back in
r35029. However, they were initially guarded by #ifdef _KERNEL. In the
meantime, we have grown at least 28 syscalls that use timespecs in some
way, leading many programs both inside and outside of the base system to
redefine those macros. It's better just to make the definitions public.

Our kernel currently defines two-argument versions of timespecadd and
timespecsub.  NetBSD, OpenBSD, and FreeDesktop.org's libbsd, however, define
three-argument versions.  Solaris also defines a three-argument version, but
only in its kernel.  This revision changes our definition to match the
common three-argument version.

Bump _FreeBSD_version due to the breaking KPI change.

Discussed with: cem, jilles, ian, bde
Differential Revision:  https://reviews.freebsd.org/D14725";

To make the change public (outside #ifdef _KERNEL) it must be integrated
in Newlib.

Update #3472.
---
 cpukit/include/machine/_kernel_time.h | 25 +
 cpukit/score/src/kern_tc.c|  2 +-
 2 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/cpukit/include/machine/_kernel_time.h 
b/cpukit/include/machine/_kernel_time.h
index 8200b6a73e..6a525fc374 100644
--- a/cpukit/include/machine/_kernel_time.h
+++ b/cpukit/include/machine/_kernel_time.h
@@ -37,22 +37,23 @@
(((tvp)->tv_sec == (uvp)->tv_sec) ? \
((tvp)->tv_nsec cmp (uvp)->tv_nsec) :   \
((tvp)->tv_sec cmp (uvp)->tv_sec))
-#definetimespecadd(vvp, uvp)   
\
+
+#definetimespecadd(tsp, usp, vsp)  
\
do {\
-   (vvp)->tv_sec += (uvp)->tv_sec; \
-   (vvp)->tv_nsec += (uvp)->tv_nsec;   \
-   if ((vvp)->tv_nsec >= 10) { \
-   (vvp)->tv_sec++;\
-   (vvp)->tv_nsec -= 10;   \
+   (vsp)->tv_sec = (tsp)->tv_sec + (usp)->tv_sec;  \
+   (vsp)->tv_nsec = (tsp)->tv_nsec + (usp)->tv_nsec;   \
+   if ((vsp)->tv_nsec >= 10L) {\
+   (vsp)->tv_sec++;\
+   (vsp)->tv_nsec -= 10L;  \
}   \
} while (0)
-#definetimespecsub(vvp, uvp)   
\
+#definetimespecsub(tsp, usp, vsp)  
\
do {\
-   (vvp)->tv_sec -= (uvp)->tv_sec; \
-   (vvp)->tv_nsec -= (uvp)->tv_nsec;   \
-   if ((vvp)->tv_nsec < 0) {   \
-   (vvp)->tv_sec--;\
-   (vvp)->tv_nsec += 10;   \
+   (vsp)->tv_sec = (tsp)->tv_sec - (usp)->tv_sec;  \
+   (vsp)->tv_nsec = (tsp)->tv_nsec - (usp)->tv_nsec;   \
+   if ((vsp)->tv_nsec < 0) {   \
+   (vsp)->tv_sec--;\
+   (vsp)->tv_nsec += 10L;  \
}   \
} while (0)
 
diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
index 99c6664fcb..d705b59a4c 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -2044,7 +2044,7 @@ pps_event(struct pps_state *pps, int event)
*tsp = ts;
 
if (foff) {
-   timespecadd(tsp, osp);
+   timespecadd(tsp, osp, tsp);
if (tsp->tv_nsec < 0) {
tsp->tv_nsec += 10;
tsp->tv_sec -= 1;
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Some problems with the libbsd update

2018-08-23 Thread Joel Sherrill 
On Thu, Aug 23, 2018 at 12:15 AM, Sebastian Huber <
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>> 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
>> >> > 
>> >> > >> 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.

>From a new user's perspective, where do they get the easy answer
to what's supported on what architectures?

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




>
>
> + Architectures that support libbsd
>>
>> A user can't determine what is usable to them in for at least those
>> features. We need a basic feature table of at least the above
>> for users.
>>
>
> I think a better question is what do I have to provide to get libbsd
> support? This is currently not that much. You just need the interrupt
> extensions API. After the update to a new FreeBSD version you probably need
> also TLS and maybe uni-processor architectures are no longer supported. You
> can still use the current libbsd.
>
>
>> Beyond that, I would consider TLS a hidden basic feature since I think
>> we now rely on it in some infrastructure pieces (language run-times?).
>> We don't have ticket(s) related to which architectures need it added.
>> And no notes on how to extract the details on what to do from GCC.
>> I randomly checked gcc for the nios2 and guess that this is the
>> register:
>>
>>(TP_REGNO  23)   ; Thread pointer register
>>
>> How I am supposed to figure that out reliably, I am not sure.
>>
>> I checked the bfin and don't get any hits for tls/TLS or THREAD_LOCAL.
>> Perhaps it doesn't support it at all. Who knows?
>>
>
> You have to check the ABI document.


And as an odd note, I found what I think is the Blackfin ABI
and it doesn't even mention TLS or thread local.

https://docs.blackfin.uclinux.org/doku.php?id=toolchain:application_binary_interface


>
>
>
>>
>> Does libbsd have suitable checks on the built RTEMS to know it
>> cannot be supported?
>>
>>
>> Without the above table, I am not sure how. Curious to hear Sebastian's
>> answer.
>>
>>
>> FWIW I do not think the idea of "one size fits all" is workable. I
>> think a
>> number of architectures would benefit from a different smaller
>> networking stack.
>>
>>
>> +1
>>
>> We are in a position where we need begin to deprecate the old stack to
>> BSPs
>> that currently support it -- perhaps move it to a separate build tree. And
>> more seriously consider LWIP.
>>
>> An even when an architecture has the infrastructure, there is at least the
>> SPARC which I don't think have any Nexus devices
>> 
>> or drivers for libbsd.
>>
>
> The generic nexus device which works well on SPARC. We used the libbsd on
> a SPARC project.


And how would one know that except by the accident of this thread.

Is network supported? I didn't see the greth in the three.

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

Re: Some problems with the libbsd update

2018-08-23 Thread Sebastian Huber 

On 23/08/18 15:40, Joel Sherrill wrote:


An even when an architecture has the infrastructure, there is
at least the
SPARC which I don't think have any Nexus devices


or drivers for libbsd.


The generic nexus device which works well on SPARC. We used the
libbsd on a SPARC project.


And how would one know that except by the accident of this thread.

Is network supported? I didn't see the greth in the three.


Do we need a document for every possible question? Everyone is free to 
ask questions on the mailing lists.


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

Re: Some problems with the libbsd update

2018-08-23 Thread Sebastian Huber 

On 23/08/18 15:40, Joel Sherrill wrote:



On Thu, Aug 23, 2018 at 12:15 AM, Sebastian Huber 
> wrote:


On 23/08/18 01:13, Joel Sherrill wrote:



On Wed, Aug 22, 2018 at 6:00 PM, Chris Johns 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
    >> mailto:sebastian.hu...@embedded-brains.de>
    >
    >> 
    >
    >> 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.

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




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.


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

Re: Some problems with the libbsd update

2018-08-23 Thread Sebastian Huber 

Hello,

I ignored this epoch memory reclamation problem and continued with the 
update. I reach the FreeBSD head today. It seems that this epoch memory 
reclamation and the use of Concurrency Kit is the only big issue.


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

Proposal for procedure for architecture/BSP removal

2018-08-23 Thread Sebastian Huber 
Hello,

I would like to propose a procedure for architecture/BSP removal since I think 
the RTEMS master carries to much historic ballast around with no active user 
base.

Once the release branch is created, an announcement is placed on the devel and 
users mailing lists and the web site news. The announcement should encourage 
all active RTEMS users to test their favourite BSP with the release branch and 
report back the status. Problems should be then be fixed with an active 
involvement of all core developers.

This announcement is repeated on the mailing lists after two weeks five times. 
This gives a testing period of three months. This should be enough to cover 
holiday seasons and urgent project schedules. Users may request an extension of 
the period.

Afterwards, the status of the BSP/architecture is recorded in the User Manual. 
Architectures/BSPs with no response will be removed from the release branch and 
the master. The removal is recorded in the User Manual. A BSP/architecture may 
not be removed if some maintainer shows up. This maintainer should be recorded 
somewhere and its duty is to fix problems with this BSP/architecture which show 
up during the development on the master branch. This includes tool chain 
problems, warnings due to compiler improvements, driver interface changes, CPU 
port API changes, new CPU port features, etc.

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

Re: Aligned operations mismatch

2018-08-23 Thread Mikhail Svetkin 
Yes, I use the legacy network stack (I did not know it is legacy, Do you
have any plans to remove it from source?).

I will create the ticket and I will send the patch.

Best regards,
Mikhail


On Thu, 23 Aug 2018 at 07:33, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 23/08/18 07:29, Sebastian Huber wrote:
> > Hello,
> >
> > On 22/08/18 16:49, Mikhail Svetkin wrote:
> >> Hi all,
> >>
> >> I have found a problem with assembler code generation in network
> >> stack on ARM processor (aligment fault).
> >>
> >> I am using:
> >> arm-rtems5-gcc (GCC) 7.2.0 20170814 (RTEMS 5, RSB
> >> a6d011e028a0776cedf0823940eb882e917a44e5, Newlib 2.5.0.20170922)
> >>
> >> The compiler generates invalid instruction 'ldmia' here
> >> (
> https://git.rtems.org/rtems/tree/cpukit/libnetworking/netinet/udp_usrreq.c#n160
> ).
> >>
> >> The instruction does not support unaligned accesses.
> >>
> >> Also i have found the bug fix in FreeBSD repository
> >> (
> https://github.com/freebsd/freebsd/commit/6cc0e8d2a0b583db5707f811d4ebfbe1ad05e628
> )
> >
> > this is a three year old commit. Which libbsd version do you use? This
> > fix is included in the libbsd 4.11 and master branch.
> >
>
> Oh, I should have read the URL more carefully. You use the legacy
> network stack. Please open a ticket for this.
>
> --
> 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

Re: Proposal for procedure for architecture/BSP removal

2018-08-23 Thread Chris Johns 
On 24/08/2018 03:51, Sebastian Huber wrote:
> I would like to propose a procedure for architecture/BSP removal since I 
> think the RTEMS master carries to much historic ballast around with no active 
> user base.

For example? We have a history of following gcc. Are you proposing we move away
from that and if yes why?

There is tier 5 ...

https://docs.rtems.org/branches/master/user/hardware/tiers.html

Tier 5 does not need to build or have working tools. Maybe that should be made
clear in the documentation.

> Once the release branch is created, an announcement is placed on the devel 
> and users mailing lists and the web site news. The announcement should 
> encourage all active RTEMS users to test their favourite BSP with the release 
> branch and report back the status. Problems should be then be fixed with an 
> active involvement of all core developers.

Why not tag the BSP as tier 5 well before the release? This gives a user of the
release and the BSP a clear indication of the BSP's status. Anything that is not
tier 5 is OK and anything that is tier 5 is to be removed unless it can be moved
to a high tier, ie someone has stepped forward.

> This announcement is repeated on the mailing lists after two weeks five 
> times. This gives a testing period of three months. This should be enough to 
> cover holiday seasons and urgent project schedules. Users may request an 
> extension of the period.

I understand the intent but do rules like this work? Do we end up with rules for
the rules, for example if you are a couple of days late posting is the process
for the removal of the BSP void and it is not removed and your start again? :)

> Afterwards, the status of the BSP/architecture is recorded in the User 
> Manual. Architectures/BSPs with no response will be removed from the release 
> branch and the master. The removal is recorded in the User Manual. 

I am not sure about this. The user manual is not a historical document, it is
forward facing. For example how long does this notice need to stay?

The tiers are currently held in an INI file in rtems-tools. Maybe building the
release documentation adds the BSP's tiers as a table to the section 8.4? The
tier 5 BSPs and archs could be noted as being for removal.

A BSP/architecture may not be removed if some maintainer shows up. This
maintainer should be recorded somewhere and its duty is to fix problems with
this BSP/architecture which show up during the development on the master branch.
This includes tool chain problems, warnings due to compiler improvements, driver
interface changes, CPU port API changes, new CPU port features, etc.

I tend to favour the tier concept, a sort of carrot approach to the problem of
maintainer-ship. Assigned maintainers and "their duty" implies a stick and I do
not have a stick plus the idea is linked to the first question about tracking
gcc as a service.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Some problems with the libbsd update

2018-08-23 Thread 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
>> > > wrote:
>>
>>     On 23/08/18 01:13, Joel Sherrill wrote:
>>
>>
>>
>>     On Wed, Aug 22, 2018 at 6:00 PM, Chris Johns >      >     >> 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
>>         >> >     
>>         >     >
>>         >> >     
>>         >     >         >>
>>         >> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Some problems with the libbsd update

2018-08-23 Thread 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
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 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
         >> mailto:sebastian.hu...@embedded-brains.de>
         >
         >> 
         >
         >> 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

Re: Some problems with the libbsd update

2018-08-23 Thread Chris Johns 
On 24/08/2018 15:31, Sebastian Huber wrote:
> 
> 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
> 

Sure, I will put this on the list and have a play. I am currently working on the
release notes generator from Dannie's GSoC effort plus the newlib docs.

I think the releases need this information more than the development branch.

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

I suggest libbsd probes a built and installed RTEMS for the features it needs to
 build and run. If the features are not present the package fails to configure
and cannot be built. It might even be possible to use some libbsd modules and
not others with some archs and BSPs. If RTEMS needs to be altered to provide or
better provide the needed bits and pieces to probe then I suggest that be 
looked at.

This however leaves open the question of what we would like libbsd to support,
what we do support and what happens with regressions? I wonder if the kernel's
tier approach could be applied to libbsd? It may mean you could concentrate on
the archs and BSPs that are in the libbsd tier 1 or 2 or whatever we decide is
the policy.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel