date:20230206


On 06.02.23 20:47, Gedare Bloom wrote:

On Mon, Feb 6, 2023 at 8:49 AM Sebastian Huber
  wrote:

On 06.02.23 16:06, Gedare Bloom wrote:

Yes, thanks. This looks like a good analysis. I would definitely
prefer to get master and 6-freebsd-12 into harmony. Then it is a
little simpler to discuss the other problems in libbsd.

Vijay had similar kind of success (and problems) as you did with
cherry-picking off of 6-freebsd-12. I think he made it a little
further. I guess one possible route forward would be to begin working
on this effort and share results, pushing to master when some
relatively stable milestones are reached.

This branch already contains an update to FreeBSD head 2020-02-09 (about
5 months of FreeBSD development):

https://github.com/RTEMS/rtems-libbsd/compare/master...sebhub:rtems-libbsd:master-update

If you start to cherry-pick things to the current master, this effort
from my side is probably wasted.


Would it be viable to still cherry-pick on to your updated master?

The farther these branches get from each other the more effort will be
wasted by everyone. Either we continue to maintain two branches, or we
at some point decide how to continue from this master branch. It would
be good to know if NFSv4 is indeed fully supported for EPICS users
without the changes made by Chris in 6-freebsd-12.


The first four patches (up to and including "ntp: Port to RTEMS") are 
ready to get integrated. The two NFS/VFS patches are not ready.


The update to FreeBSD head 2020-02-09 was not arbitrary. The 
6-freebsd-12 branch is based on FreeBSD stable/12 2020-02-10. This 
should make it easier to cherry pick changes from 6-freebsd-12 to master 
for example for the Xilinx drivers.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] spec/bsps: Deduplicate objxilinxsupport


On 06.02.23 23:09, Gedare Bloom wrote:

ok. I'm not sure, maybe we need a note about this in
https://docs.rtems.org/branches/master/eng/build-system.html


A hint in the documentation would be helpful. Even more helpful would be 
a consistency check before patch sets are pulled in. For example, it is 
a bug if you have a diamond in the build dependency graph and the nodes 
with an indegree greater than one install files. If the nodes with an 
indegree greater than one build source files with identical build 
options, then this is also a bug. However, a valid special case could be 
a node which is built with different build flags, for example:


lib -> grp_a (-DFLAG_A) -> objxyz
 \---> grp_b (-DFLAG_B) -> objxyz

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GitLab and BuildBot

2023-02-06 Thread Chris Johns

On 30/1/2023 10:12 pm, Christian MAUDERER wrote:
> Hello,
> 
> recently the following tickets were added (beneath a few more related ones):
> 
> https://devel.rtems.org/ticket/4790 - Setup Gitlab instance
> https://devel.rtems.org/ticket/4791 - Update BuildBot
> 
> It's great that a patch review system and a CI/CD that builds every patch for
> RTEMS starts to get within reach. Thanks a lot to all involved in that for the
> efforts.

It is exciting to see this happening. It will benefit the project and all who
give their time.

> I reviewed earlier discussions related to CI/CD. From my point of view there 
> are
> mainly two points that are missing in the tickets:
> 
> First: From my point of view, we should make it simple for new users to
> register. Adding authentication using well-known services can help with that.
> GitLab supports (for example):
>   - GitHub: https://docs.gitlab.com/ee/integration/github.html
>   - GitLab.com: https://docs.gitlab.com/ee/integration/gitlab.html
>   - Google: https://docs.gitlab.com/ee/integration/google.html
>   - ...
> I think it would be good to select the most common ones (at least the three
> mentioned above) and add them as a goal to the ticket or a new one. What do 
> you
> think?

I suggest a ticket to handle authentication. If you create a ticket please
indicate it is unfunded. If this is handled else where and in another ticket
this one can be closed with a suitable reason.

The addition of these authentication methods can be done when someone funds the
work. If a person or organisation thinks it is important please reach out to
Amar directly.

> Second: It's still a bit unclear for me how the CI/CD with BuildBot will work.
> Will it be possible for anyone to help improve the CI/CD? An example to make 
> it
> clear what I want to know: Let's assume an unprivileged developer has a patch
> set that allows building device tree files using the RTEMS build system, but 
> the
> patches require a new tool like dtc. Let's further assume that the idea has 
> been
> discussed and everyone agrees that it is a good idea (currently not yet the 
> case
> for dtc). Problem is: The patches trigger a CI error because the new tool is
> missing and therefore can't be merged yet. How can the developer suggest a fix
> so that the patches can be accepted faster without having to wait for one
> specific maintainer to have enough time for adapting the CI config?

There are details that will need to be worked out. Deployment of tools for
building in a CI flow is important. How complex and automated this will be will
depends on the funding provided. At this point in time the push is to get a
basic framework up that allows us to handle simple merge requests. The approach
is more organic in nature so funding can be targeted at the most important
foundation pieces. Further funding can build on that base. Before we get to
Gitlab and CI we need to rebase the servers and software on them. This part of
the effort is funded and under way. Amar is updating the tickets with the 
progress.

The hope is gitlab admin activities can be shared. Amar and I have briefly
discussed this but nothing has been decided. We need a gitleb instance before
this becomes something we need to handle.

Chris

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

Re: [PATCH rtems-libbsd] CONTRIBUTING: Sharpen priority development goals

2023-02-06 Thread Chris Johns

On 6/2/2023 7:07 pm, Christian MAUDERER wrote:
> Hello Chris,
> 
> thanks for your feedback on the patch.

No problem :)

> On 2023-02-06 05:16, Chris Johns wrote:
>> On 3/2/2023 6:31 pm, Christian Mauderer wrote:
>>> This patch tries to make the most important goals of LibBSD development
>>> more clear based on the results of the discussion on the mailing list:
>>>
>>> https://lists.rtems.org/pipermail/devel/2023-January/074164.html
>>> ---
>>>   CONTRIBUTING.rst | 39 ++-
>>>   1 file changed, 30 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
>>> index 0b6fc7a0..31561f6a 100644
>>> --- a/CONTRIBUTING.rst
>>> +++ b/CONTRIBUTING.rst
>>> @@ -21,15 +21,36 @@ RTEMS specific support files, general guidelines on what
>>> modifications to the
>>>   FreeBSD source are permitted, and some other topics.  For building the
>>> library,
>>>   see the `README `_.
>>>   -Goals of the LibBSD activity are
>>> -
>>> -* provide functionality from FreeBSD to RTEMS,
>>> -* ease updating to future FreeBSD versions,
>>> -* ease tracking changes in FreeBSD code,
>>> -* minimize manual changes in FreeBSD code.
>>> -
>>> -We will work to push our changes upstream to the FreeBSD Project and 
>>> minimize
>>> -changes required at each update point.
>>> +Every change to LibBSD has to consider the following points in groups of
>>> +descending priority:
>>> +
>>> +#. Real-time Impacts + Maintainability Loss
>>> +   * LibBSD itself doesn't make any real time claims because it is 
>>> basically
>>> + FreeBSD and they don't make any real time claims either.  But all
>>> + development in LibBSD must make sure that the real time ability of the
>>> + RTEMS core system or the application is not affected.
>>> +   * It's utterly important that LibBSD is simple to maintain.  One of the 
>>> most
>>> + important points for that is that upgrades to newer FreeBSD versions 
>>> have
>>> + to be easy.
>>
>> Correct and it is important we adopt and use what FreeBSD provides rather 
>> than
>> adding extra complexity. I wrote about this in the FreeBSD journal years ago.
>> The bespoke handing of fd and file objects is something I consider an 
>> unneeded
>> complexity for specific system related reasons. We need NFSv4 and that uses 
>> VFS
>> and that in turn uses the FreeBSD fd and file objects.
>>
> 
> I'm trying to find out what rules are agreed by most of us.

I feel we need simplicity. I was surprised by the number of undefined rules my
changes tripped over and to be honest I still have no idea what they are, why
they exist and who made them?

> It's of course OK to
> bring examples. But I think we should try to evaluate the currently discussed
> patch set based on the results together with as many of the other maintainers 
> as
> possible as soon as we agree on the rules that we want to use to evaluate 
> them.

The rules for the changes I made are simple. It is transparency of the FreeBSD 
code.

> The file descriptors are an example where I know that Sebastian and you will
> argument that their solution is the right one.

He may but his view is only one view and fixed and I am sorry but the forceful
and sometimes short nature of his responses has not helped his cause.

I found the port of NFSv4 easy until I hit the fd/file parts. The complexity
then grew and as I attempted to sort one piece out I hit another location and in
the end I had little confidence about the changes I had made. Each change
started to appear like a slight variation of the same thing for each descriptor
type. In the end I decided the size of changes had grown to big so I decided to
switch direction and bring across the FreeBSD code as close as possible and to
move libbsd in the that direction because the closer we had VFS to FreeBSD the
simpler the testing of complex pieces like the vnode cache and lookup would be.

It is important to note we need code the project can maintain and as a result of
my deep dive I now question who can maintain the fd/file support as it was?

> I think that can only be decided with the help of some more people.

I agree. This is about the long term and beyond any one of us.

>> Source transparency is what matters and as a test of what is acceptable it 
>> must
>> be preferred between competing implementations.
>>
>>> +#. Transparency Loss + Modularity Loss + Code/RAM Size Increase
>>> +   * LibBSD code should be easy to read and easy to debug.  Changes should 
>>> be
>>> + integrated in a way that are easy to understand.  Of course that's a
>>> + subjective goal.  As a general rule: If it adds lot's of extra code or
>>> even
>>> + more layers than already exist in FreeBSD, it's harder to understand.
>>> +   * There are a number of methods used in LibBSD to make it modular.  If 
>>> you
>>> + add new functionality, use one of the existing methods to allow
>>> enabling or
>>> + disabling your module.  For example make sure that the

Re: [PATCH] spec/bsps: Deduplicate objxilinxsupport

2023-02-06 Thread Kinsey Moore


On 2/6/2023 4:09 PM, Gedare Bloom wrote:

ok. I'm not sure, maybe we need a note about this in
https://docs.rtems.org/branches/master/eng/build-system.html


I'll see if I can find an appropriate place for it to go in that 
document. Some parts of it are aspirational and apply to any build 
system we might use and other parts are more practical, so there should 
be a place that it can fit.



Kinsey

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

Re: [PATCH] spec/bsps: Deduplicate objxilinxsupport

ok. I'm not sure, maybe we need a note about this in
https://docs.rtems.org/branches/master/eng/build-system.html

On Mon, Feb 6, 2023 at 2:02 PM Kinsey Moore  wrote:
>
> The objxilinxsupport build object was accidentally included twice in
> some of the ZynqMP BSPs by two different drivers that required it. This
> commit manually deduplicates the inclusions by moving that inclusion to
> the BSP. Duplication of object inclusions is considered a bug and can
> cause race conditions in the build system.
> ---
>  spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml | 2 ++
>  spec/build/bsps/objnandpsu.yml| 4 +---
>  spec/build/bsps/objqspipsu.yml| 2 --
>  3 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml 
> b/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml
> index f0c3a13ffd..a00490a826 100644
> --- a/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml
> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml
> @@ -52,6 +52,8 @@ links:
>uid: ../../objdevspixil
>  - role: build-dependency
>uid: ../../objmem
> +- role: build-dependency
> +  uid: ../../objxilinxsupport
>  - role: build-dependency
>uid: ../../optcachedata
>  - role: build-dependency
> diff --git a/spec/build/bsps/objnandpsu.yml b/spec/build/bsps/objnandpsu.yml
> index a0ff1b0b9e..253c598e8c 100644
> --- a/spec/build/bsps/objnandpsu.yml
> +++ b/spec/build/bsps/objnandpsu.yml
> @@ -17,9 +17,7 @@ install:
>- bsps/include/dev/nand/xnandpsu.h
>- bsps/include/dev/nand/xnandpsu_hw.h
>- bsps/include/dev/nand/xnandpsu_onfi.h
> -links:
> -- role: build-dependency
> -  uid: objxilinxsupport
> +links: []
>  source:
>  - bsps/shared/dev/nand/xnandpsu_bbm.c
>  - bsps/shared/dev/nand/xnandpsu.c
> diff --git a/spec/build/bsps/objqspipsu.yml b/spec/build/bsps/objqspipsu.yml
> index 5f8679c83c..205172146e 100644
> --- a/spec/build/bsps/objqspipsu.yml
> +++ b/spec/build/bsps/objqspipsu.yml
> @@ -19,8 +19,6 @@ install:
>- bsps/include/dev/spi/xqspipsu-flash-helper.h
>- bsps/include/dev/spi/xqspipsu.h
>  links:
> -- role: build-dependency
> -  uid: objxilinxsupport
>  - role: build-dependency
>uid: optxpssysctrlbaseaddress
>  source:
> --
> 2.30.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] wscript: Deduplicate installed files

On Mon, Feb 6, 2023 at 1:03 PM Kinsey Moore  wrote:
>
> On 2/6/2023 8:44 AM, Sebastian Huber wrote:
> > On 06.02.23 15:30, Joel Sherrill wrote:
> >> On Mon, Feb 6, 2023 at 12:55 AM Sebastian Huber
> >>  >> > wrote:
> >> On 06.02.23 03:35, Chris Johns wrote:
> >>  > On 4/2/2023 6:11 am, Sebastian Huber wrote:
> >>  >> On 03.02.23 19:45, Kinsey Moore wrote:
> >>  >>> This is my first stab at solving this duplicate install
> >> problem. I could
> >>  >>> manually solve the problem by deduplicating the object includes
> >> and moving it
> >>  >>> up to the BSP, but that is less intuitive since these drivers
> >> both depend on
> >>  >>> the same code and the BSP doesn't depend on it directly.
> >>  >>
> >>  >> Why don't you add the shared stuff to a objxilcommon.yml?
> >>  >>
> >>  >> The approach in the wscript is a bit complex from my point of
> >> view.
> >>  >
> >>  > I am OK with adding this code or something similar. It is no more
> >> complex than
> >>  > other places I have reviewed, eg `Item._init_link()`.
> >>  >
> >>  > The issue is currently not easy to see and may be present in
> >> other places
> >>  > without us knowing. I am also fine with a spec file check that
> >> highlights a
> >>  > clash to draw attention to a problem when the spec files are
> >> parsed. I feeling
> >>  > we need something.
> >>
> >> If you install with
> >>
> >> ./waf install -vv
> >>
> >> you see the duplicate install targets. See also
> >>
> >> https://gitlab.com/ita1024/waf/-/issues/2329#note_467849523
> >> 
> >>
> >> Before we add double for loops we should first analyze the
> >> underlying
> >> problem. In this case it is a diamond shaped build dependency graph.
> >>
> >> spec/build/bsps/objnandpsu.yml:  uid: objxilinxsupport
> >> spec/build/bsps/objqspipsu.yml:  uid: objxilinxsupport
> >> spec/build/bsps/aarch64/xilinx-zynqmp/objjffs2qspinor.yml: uid:
> >> ../../objqspipsu
> >> spec/build/bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml:  uid:
> >> ../../objnandpsu
> >>
> >> In addition to the duplicate install targets you build also the
> >> objects
> >> of objxilinxsupport twice and add them to the library.
> >>
> >> I would simply move the links to grp_zu3eg:
> >>
> >> grp_zu3eg.yml:  uid: ../../objxilinxspport
> >> grp_zu3eg.yml:  uid: ../../objnandpsu
> >> grp_zu3eg.yml:  uid: ../../objqspipsu
> >>
> >>
> >> That's the solution in this case but wouldn't it be nice to detect it
> >> reliably and
> >> address it when it shows up again.
> >
> > You can detect the issue with by calling ./waf -vv install. This is
> > what the maintainer of waf recommends:
> >
> > https://gitlab.com/ita1024/waf/-/issues/2329#note_467849523
> >
> > I would rather try to get these warnings by default from waf instead
> > of tinkering with special case solutions above waf.
> >
> > The patch doesn't address the issue with the multiple object files in
> > the library.
> >
> It sounds like we consider this an error which is fine by me. I'll drop
> this patch and deduplicate the objects manually.
>
> I would like to find a way to make this an actual error which will stop
> the build instead of hiding a warning behind the -v flag. I'll see what
> I can do along these lines.
>
The linked Issue suggests that it occasionally comes up as a false
positive, which is why tnagy didn't make it an error.

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

[PATCH] spec/bsps: Deduplicate objxilinxsupport

2023-02-06 Thread Kinsey Moore

The objxilinxsupport build object was accidentally included twice in
some of the ZynqMP BSPs by two different drivers that required it. This
commit manually deduplicates the inclusions by moving that inclusion to
the BSP. Duplication of object inclusions is considered a bug and can
cause race conditions in the build system.
---
 spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml | 2 ++
 spec/build/bsps/objnandpsu.yml| 4 +---
 spec/build/bsps/objqspipsu.yml| 2 --
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml 
b/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml
index f0c3a13ffd..a00490a826 100644
--- a/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml
+++ b/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml
@@ -52,6 +52,8 @@ links:
   uid: ../../objdevspixil
 - role: build-dependency
   uid: ../../objmem
+- role: build-dependency
+  uid: ../../objxilinxsupport
 - role: build-dependency
   uid: ../../optcachedata
 - role: build-dependency
diff --git a/spec/build/bsps/objnandpsu.yml b/spec/build/bsps/objnandpsu.yml
index a0ff1b0b9e..253c598e8c 100644
--- a/spec/build/bsps/objnandpsu.yml
+++ b/spec/build/bsps/objnandpsu.yml
@@ -17,9 +17,7 @@ install:
   - bsps/include/dev/nand/xnandpsu.h
   - bsps/include/dev/nand/xnandpsu_hw.h
   - bsps/include/dev/nand/xnandpsu_onfi.h
-links:
-- role: build-dependency
-  uid: objxilinxsupport
+links: []
 source:
 - bsps/shared/dev/nand/xnandpsu_bbm.c
 - bsps/shared/dev/nand/xnandpsu.c
diff --git a/spec/build/bsps/objqspipsu.yml b/spec/build/bsps/objqspipsu.yml
index 5f8679c83c..205172146e 100644
--- a/spec/build/bsps/objqspipsu.yml
+++ b/spec/build/bsps/objqspipsu.yml
@@ -19,8 +19,6 @@ install:
   - bsps/include/dev/spi/xqspipsu-flash-helper.h
   - bsps/include/dev/spi/xqspipsu.h
 links:
-- role: build-dependency
-  uid: objxilinxsupport
 - role: build-dependency
   uid: optxpssysctrlbaseaddress
 source:
-- 
2.30.2

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

Re: [PATCH] wscript: Deduplicate installed files

2023-02-06 Thread Kinsey Moore


On 2/6/2023 8:44 AM, Sebastian Huber wrote:

On 06.02.23 15:30, Joel Sherrill wrote:
On Mon, Feb 6, 2023 at 12:55 AM Sebastian Huber 
> wrote:

    On 06.02.23 03:35, Chris Johns wrote:
 > On 4/2/2023 6:11 am, Sebastian Huber wrote:
 >> On 03.02.23 19:45, Kinsey Moore wrote:
 >>> This is my first stab at solving this duplicate install
    problem. I could
 >>> manually solve the problem by deduplicating the object includes
    and moving it
 >>> up to the BSP, but that is less intuitive since these drivers
    both depend on
 >>> the same code and the BSP doesn't depend on it directly.
 >>
 >> Why don't you add the shared stuff to a objxilcommon.yml?
 >>
 >> The approach in the wscript is a bit complex from my point of 
view.

 >
 > I am OK with adding this code or something similar. It is no more
    complex than
 > other places I have reviewed, eg `Item._init_link()`.
 >
 > The issue is currently not easy to see and may be present in
    other places
 > without us knowing. I am also fine with a spec file check that
    highlights a
 > clash to draw attention to a problem when the spec files are
    parsed. I feeling
 > we need something.

    If you install with

    ./waf install -vv

    you see the duplicate install targets. See also

    https://gitlab.com/ita1024/waf/-/issues/2329#note_467849523


    Before we add double for loops we should first analyze the 
underlying

    problem. In this case it is a diamond shaped build dependency graph.

    spec/build/bsps/objnandpsu.yml:  uid: objxilinxsupport
    spec/build/bsps/objqspipsu.yml:  uid: objxilinxsupport
    spec/build/bsps/aarch64/xilinx-zynqmp/objjffs2qspinor.yml: uid:
    ../../objqspipsu
    spec/build/bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml:  uid:
    ../../objnandpsu

    In addition to the duplicate install targets you build also the 
objects

    of objxilinxsupport twice and add them to the library.

    I would simply move the links to grp_zu3eg:

    grp_zu3eg.yml:  uid: ../../objxilinxspport
    grp_zu3eg.yml:  uid: ../../objnandpsu
    grp_zu3eg.yml:  uid: ../../objqspipsu


That's the solution in this case but wouldn't it be nice to detect it 
reliably and

address it when it shows up again.


You can detect the issue with by calling ./waf -vv install. This is 
what the maintainer of waf recommends:


https://gitlab.com/ita1024/waf/-/issues/2329#note_467849523

I would rather try to get these warnings by default from waf instead 
of tinkering with special case solutions above waf.


The patch doesn't address the issue with the multiple object files in 
the library.


It sounds like we consider this an error which is fine by me. I'll drop 
this patch and deduplicate the objects manually.


I would like to find a way to make this an actual error which will stop 
the build instead of hiding a warning behind the -v flag. I'll see what 
I can do along these lines.



Kinsey

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

Re: libbsd development policy clarification needed?

On Mon, Feb 6, 2023 at 8:49 AM Sebastian Huber
 wrote:
>
> On 06.02.23 16:06, Gedare Bloom wrote:
> > Yes, thanks. This looks like a good analysis. I would definitely
> > prefer to get master and 6-freebsd-12 into harmony. Then it is a
> > little simpler to discuss the other problems in libbsd.
> >
> > Vijay had similar kind of success (and problems) as you did with
> > cherry-picking off of 6-freebsd-12. I think he made it a little
> > further. I guess one possible route forward would be to begin working
> > on this effort and share results, pushing to master when some
> > relatively stable milestones are reached.
>
> This branch already contains an update to FreeBSD head 2020-02-09 (about
> 5 months of FreeBSD development):
>
> https://github.com/RTEMS/rtems-libbsd/compare/master...sebhub:rtems-libbsd:master-update
>
> If you start to cherry-pick things to the current master, this effort
> from my side is probably wasted.
>
Would it be viable to still cherry-pick on to your updated master?

The farther these branches get from each other the more effort will be
wasted by everyone. Either we continue to maintain two branches, or we
at some point decide how to continue from this master branch. It would
be good to know if NFSv4 is indeed fully supported for EPICS users
without the changes made by Chris in 6-freebsd-12.

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

[docs] c-user: Remove obsolete config section

This commit already clarified that the defines of the removed section
are optional BSP provided default values and not application
configuration options:

commit cf9f2121577b11f8eab5e49c48173c46cf09c627
Author: Sebastian Huber 
Date:   Wed Nov 17 08:46:56 2021 +0100

c-user: Clarify BSP related configuration settings
---
 c-user/config/bsp-related.rst | 355 --
 c-user/config/index.rst   |   1 -
 2 files changed, 356 deletions(-)
 delete mode 100644 c-user/config/bsp-related.rst

diff --git a/c-user/config/bsp-related.rst b/c-user/config/bsp-related.rst
deleted file mode 100644
index b13a91d..000
--- a/c-user/config/bsp-related.rst
+++ /dev/null
@@ -1,355 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-4.0
-
-.. Copyright (C) 2020, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
-.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
-
-.. This file is part of the RTEMS quality process and was automatically
-.. generated.  If you find something that needs to be fixed or
-.. worded better please post a report or patch to an RTEMS mailing list
-.. or raise a bug report:
-..
-.. https://www.rtems.org/bugs.html
-..
-.. For information on updating and regenerating please refer to the How-To
-.. section in the Software Requirements Engineering chapter of the
-.. RTEMS Software Engineering manual.  The manual is provided as a part of
-.. a release.  For development sources please refer to the online
-.. documentation at:
-..
-.. https://docs.rtems.org
-
-.. Generated from spec:/acfg/if/group-bsp
-
-BSP Related Configuration Options
-=
-
-This section describes configuration options related to the BSP.  Some
-configuration options may have a BSP-specific setting which is defined by
-.  The BSP-specific settings can be disabled by the
-:ref:`CONFIGURE_DISABLE_BSP_SETTINGS` configuration option.
-
-.. Generated from spec:/acfg/if/bsp-idle-task-body
-
-.. raw:: latex
-
-\clearpage
-
-.. index:: BSP_IDLE_TASK_BODY
-
-.. _BSP_IDLE_TASK_BODY:
-
-BSP_IDLE_TASK_BODY
---
-
-.. rubric:: CONSTANT:
-
-``BSP_IDLE_TASK_BODY``
-
-.. rubric:: OPTION TYPE:
-
-This configuration option is an initializer define.
-
-.. rubric:: DEFAULT VALUE:
-
-The default value is BSP-specific.
-
-.. rubric:: DESCRIPTION:
-
-If
-
-* this configuration option is defined by the BSP
-
-* and :ref:`CONFIGURE_DISABLE_BSP_SETTINGS` is undefined,
-
-then the value of this configuration option defines the default value of
-:ref:`CONFIGURE_IDLE_TASK_BODY`.
-
-.. rubric:: NOTES:
-
-As it has knowledge of the specific CPU model, system controller logic, and
-peripheral buses, a BSP-specific IDLE task may be capable of turning
-components off to save power during extended periods of no task activity.
-
-.. rubric:: CONSTRAINTS:
-
-The value of the configuration option shall be defined to a valid function
-pointer of the type ``void *( *idle_body )( uintptr_t )``.
-
-.. Generated from spec:/acfg/if/bsp-idle-task-stack-size
-
-.. raw:: latex
-
-\clearpage
-
-.. index:: BSP_IDLE_TASK_STACK_SIZE
-
-.. _BSP_IDLE_TASK_STACK_SIZE:
-
-BSP_IDLE_TASK_STACK_SIZE
-
-
-.. rubric:: CONSTANT:
-
-``BSP_IDLE_TASK_STACK_SIZE``
-
-.. rubric:: OPTION TYPE:
-
-This configuration option is an integer define.
-
-.. rubric:: DEFAULT VALUE:
-
-The default value is BSP-specific.
-
-.. rubric:: DESCRIPTION:
-
-If
-
-* this configuration option is defined by the BSP
-
-* and :ref:`CONFIGURE_DISABLE_BSP_SETTINGS` is undefined,
-
-then the value of this configuration option defines the default value of
-:ref:`CONFIGURE_IDLE_TASK_STACK_SIZE`.
-
-.. rubric:: CONSTRAINTS:
-
-The following constraints apply to this configuration option:
-
-* The value of the configuration option shall be greater than or equal to a
-  BSP-specific and application-specific minimum value.
-
-* The value of the configuration option shall be small enough so that the IDLE
-  task stack area calculation carried out by  does not
-  overflow an integer of type `size_t
-  `_.
-
-.. Generated from spec:/acfg/if/bsp-initial-extension
-
-.. raw:: latex
-
-\clearpage
-
-.. index:: BSP_INITIAL_EXTENSION
-
-.. _BSP_INITIAL_EXTENSION:
-
-BSP_INITIAL_EXTENSION
--
-
-.. rubric:: CONSTANT:
-
-``BSP_INITIAL_EXTENSION``
-
-.. rubric:: OPTION TYPE:
-
-This configuration option is an initializer define.
-
-.. rubric:: DEFAULT VALUE:
-
-The default value is BSP-specific.
-
-.. rubric:: DESCRIPTION:
-
-If
-
-* this configuration option is defined by the BSP
-
-* and :ref:`CONFIGURE_DISABLE_BSP_SETTINGS` is undefined,
-
-then the value of this configuration option is used to initialize the table
-of initial user extensions.
-
-.. rubric:: NOTES:
-
-The value of this configuration option is placed after the entries of all
-other initial user extensions.
-
-.. rubric:: CONSTRAINTS:
-
-The value of the

[PATCH 3/4] doxygen: Generalize appl config constraints

Rename the constaints section of application configuration options from
"Value Constraints" in "Constraints.  Adjust the constraint wording
accordingly.  This is in line with the RTEMS Classic API Guide.

Update #3994.
---
 cpukit/doxygen/appl-config.h | 1101 ++
 1 file changed, 576 insertions(+), 525 deletions(-)

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index d48fb11741..0a0de863bf 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -3,7 +3,7 @@
 /*
  * Copyright (C) 2019, 2022 embedded brains GmbH 
(http://www.embedded-brains.de)
  * Copyright (C) 2010 Gedare Bloom
- * Copyright (C) 1988, 2021 On-Line Applications Research Corporation (OAR)
+ * Copyright (C) 1988, 2022 On-Line Applications Research Corporation (OAR)
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -94,14 +94,15 @@
  * @par Default Value
  * The default value is 4096.
  *
- * @par Value Constraints
+ * @par Constraints
  * @parblock
- * The value of this configuration option shall satisfy all of the following
- * constraints:
+ * The following constraints apply to this configuration option:
  *
- * * It shall be greater than or equal to zero.
+ * * The value of the configuration option shall be greater than or equal to
+ *   zero.
  *
- * * It shall be an integral multiple of #CONFIGURE_BDBUF_BUFFER_MIN_SIZE.
+ * * The value of the configuration option shall be an integral multiple of
+ *   #CONFIGURE_BDBUF_BUFFER_MIN_SIZE.
  * @endparblock
  */
 #define CONFIGURE_BDBUF_BUFFER_MAX_SIZE
@@ -117,14 +118,14 @@
  * @par Default Value
  * The default value is 512.
  *
- * @par Value Constraints
+ * @par Constraints
  * @parblock
- * The value of this configuration option shall satisfy all of the following
- * constraints:
+ * The following constraints apply to this configuration option:
  *
- * * It shall be greater than or equal to zero.
+ * * The value of the configuration option shall be greater than or equal to
+ *   zero.
  *
- * * It shall be less than or equal to https://en.cppreference.com/w/c/types/integer;>UINT32_MAX.
  * @endparblock
  */
@@ -141,14 +142,14 @@
  * @par Default Value
  * The default value is 32768.
  *
- * @par Value Constraints
+ * @par Constraints
  * @parblock
- * The value of this configuration option shall satisfy all of the following
- * constraints:
+ * The following constraints apply to this configuration option:
  *
- * * It shall be greater than or equal to zero.
+ * * The value of the configuration option shall be greater than or equal to
+ *   zero.
  *
- * * It shall be less than or equal to https://en.cppreference.com/w/c/types/limits;>SIZE_MAX.
  * @endparblock
  */
@@ -165,14 +166,14 @@
  * @par Default Value
  * The default value is 0.
  *
- * @par Value Constraints
+ * @par Constraints
  * @parblock
- * The value of this configuration option shall satisfy all of the following
- * constraints:
+ * The following constraints apply to this configuration option:
  *
- * * It shall be greater than or equal to zero.
+ * * The value of the configuration option shall be greater than or equal to
+ *   zero.
  *
- * * It shall be less than or equal to https://en.cppreference.com/w/c/types/integer;>UINT32_MAX.
  * @endparblock
  *
@@ -194,14 +195,14 @@
  * @par Default Value
  * The default value is 16.
  *
- * @par Value Constraints
+ * @par Constraints
  * @parblock
- * The value of this configuration option shall satisfy all of the following
- * constraints:
+ * The following constraints apply to this configuration option:
  *
- * * It shall be greater than or equal to zero.
+ * * The value of the configuration option shall be greater than or equal to
+ *   zero.
  *
- * * It shall be less than or equal to https://en.cppreference.com/w/c/types/integer;>UINT32_MAX.
  * @endparblock
  */
@@ -217,8 +218,8 @@
  * @par Default Value
  * The default value is 15.
  *
- * @par Value Constraints
- * The value of this configuration option shall be a valid Classic API task
+ * @par Constraints
+ * The value of the configuration option shall be a valid Classic API task
  * priority.  The set of valid task priorities depends on the scheduler
  * configuration.
  */
@@ -235,19 +236,20 @@
  * @par Default Value
  * The default value is #RTEMS_MINIMUM_STACK_SIZE.
  *
- * @par Value Constraints
+ * @par Constraints
  * @parblock
- * The value of this configuration option shall satisfy all of the following
- * constraints:
+ * The following constraints apply to this configuration option:
  *
- * * It shall be greater than or equal to #CONFIGURE_MINIMUM_TASK_STACK_SIZE.
+ * * The value of the configuration option shall be greater than or equal to
+ *   #CONFIGURE_MINIMUM_TASK_STACK_SIZE.
  *
- * * It shall be less than or equal to a BSP-specific and application-specific
- *   value which depends on the size of the memory available to

[PATCH 4/4] doxygen: Use @anchor for appl config options

The application configuration options are documented in
"cpukit/doxygen/appl-config.h".  Since the application configuration
option defines are also present in multiple test program sources, the
"#OPTION" references cannot be mapped to a unique definition.  Add an
anchor for each option and reference it to avoid the issues with the
multiple definitions.

Update #3994.
---
 cpukit/doxygen/appl-config.h   | 762 +
 cpukit/include/rtems/bspIo.h   |   2 +-
 cpukit/include/rtems/config.h  |  60 +-
 cpukit/include/rtems/extension.h   |  16 +-
 cpukit/include/rtems/io.h  |   4 +-
 cpukit/include/rtems/rtems/barrier.h   |   4 +-
 cpukit/include/rtems/rtems/clock.h |   8 +-
 cpukit/include/rtems/rtems/config.h|  60 +-
 cpukit/include/rtems/rtems/dpmem.h |   4 +-
 cpukit/include/rtems/rtems/message.h   |  28 +-
 cpukit/include/rtems/rtems/part.h  |  10 +-
 cpukit/include/rtems/rtems/ratemon.h   |   5 +-
 cpukit/include/rtems/rtems/region.h|   5 +-
 cpukit/include/rtems/rtems/scheduler.h |   4 +-
 cpukit/include/rtems/rtems/sem.h   |  10 +-
 cpukit/include/rtems/rtems/support.h   |   8 +-
 cpukit/include/rtems/rtems/tasks.h |  49 +-
 cpukit/include/rtems/rtems/timer.h |   7 +-
 18 files changed, 678 insertions(+), 368 deletions(-)

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index 0a0de863bf..e13ebb8ba5 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -69,6 +69,8 @@
 /**
  * @brief This configuration option is a boolean feature define.
  *
+ * @anchor CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
+ *
  * In case this configuration option is defined, then the Block Device Cache is
  * initialized during system initialization.
  *
@@ -88,6 +90,8 @@
 /**
  * @brief This configuration option is an integer define.
  *
+ * @anchor CONFIGURE_BDBUF_BUFFER_MAX_SIZE
+ *
  * The value of this configuration option defines the maximum size of a buffer
  * in bytes.
  *
@@ -102,7 +106,7 @@
  *   zero.
  *
  * * The value of the configuration option shall be an integral multiple of
- *   #CONFIGURE_BDBUF_BUFFER_MIN_SIZE.
+ *   @ref CONFIGURE_BDBUF_BUFFER_MIN_SIZE.
  * @endparblock
  */
 #define CONFIGURE_BDBUF_BUFFER_MAX_SIZE
@@ -112,6 +116,8 @@
 /**
  * @brief This configuration option is an integer define.
  *
+ * @anchor CONFIGURE_BDBUF_BUFFER_MIN_SIZE
+ *
  * The value of this configuration option defines the minimum size of a buffer
  * in bytes.
  *
@@ -136,6 +142,8 @@
 /**
  * @brief This configuration option is an integer define.
  *
+ * @anchor CONFIGURE_BDBUF_CACHE_MEMORY_SIZE
+ *
  * The value of this configuration option defines the size of the cache memory
  * in bytes.
  *
@@ -160,6 +168,8 @@
 /**
  * @brief This configuration option is an integer define.
  *
+ * @anchor CONFIGURE_BDBUF_MAX_READ_AHEAD_BLOCKS
+ *
  * The value of this configuration option defines the maximum blocks per
  * read-ahead request.
  *
@@ -189,6 +199,8 @@
 /**
  * @brief This configuration option is an integer define.
  *
+ * @anchor CONFIGURE_BDBUF_MAX_WRITE_BLOCKS
+ *
  * The value of this configuration option defines the maximum blocks per write
  * request.
  *
@@ -213,6 +225,8 @@
 /**
  * @brief This configuration option is an integer define.
  *
+ * @anchor CONFIGURE_BDBUF_READ_AHEAD_TASK_PRIORITY
+ *
  * The value of this configuration option defines the read-ahead task priority.
  *
  * @par Default Value
@@ -230,6 +244,8 @@
 /**
  * @brief This configuration option is an integer define.
  *
+ * @anchor CONFIGURE_BDBUF_TASK_STACK_SIZE
+ *
  * The value of this configuration option defines the task stack size of the
  * Block Device Cache tasks in bytes.
  *
@@ -241,7 +257,7 @@
  * The following constraints apply to this configuration option:
  *
  * * The value of the configuration option shall be greater than or equal to
- *   #CONFIGURE_MINIMUM_TASK_STACK_SIZE.
+ *   @ref CONFIGURE_MINIMUM_TASK_STACK_SIZE.
  *
  * * The value of the configuration option shall be less than or equal to a
  *   BSP-specific and application-specific value which depends on the size of
@@ -260,6 +276,8 @@
 /**
  * @brief This configuration option is an integer define.
  *
+ * @anchor CONFIGURE_SWAPOUT_BLOCK_HOLD
+ *
  * The value of this configuration option defines the swapout task maximum
  * block hold time in milliseconds.
  *
@@ -284,6 +302,8 @@
 /**
  * @brief This configuration option is an integer define.
  *
+ * @anchor CONFIGURE_SWAPOUT_SWAP_PERIOD
+ *
  * The value of this configuration option defines the swapout task swap period
  * in milliseconds.
  *
@@ -308,6 +328,8 @@
 /**
  * @brief This configuration option is an integer define.
  *
+ * @anchor CONFIGURE_SWAPOUT_TASK_PRIORITY
+ *
  * The value of this configuration option defines the swapout task priority.
  *
  * @par Default Value
@@ -325,6 +347,8 @@
 /**
  * @brief This configuration option is an integer define.
  *
+ * @anchor

[PATCH 0/4] Improve Doxygen documentation of application configuration options

Sebastian Huber (4):
  doxygen: Use quotes for href URLs
  doxygen: Clarify CONFIGURE_DISABLE_BSP_SETTINGS
  doxygen: Generalize appl config constraints
  doxygen: Use @anchor for appl config options

 cpukit/doxygen/appl-config.h   | 2169 +---
 cpukit/include/rtems/bspIo.h   |2 +-
 cpukit/include/rtems/config.h  |   60 +-
 cpukit/include/rtems/extension.h   |   16 +-
 cpukit/include/rtems/io.h  |4 +-
 cpukit/include/rtems/rtems/barrier.h   |4 +-
 cpukit/include/rtems/rtems/clock.h |8 +-
 cpukit/include/rtems/rtems/config.h|   60 +-
 cpukit/include/rtems/rtems/dpmem.h |4 +-
 cpukit/include/rtems/rtems/message.h   |   28 +-
 cpukit/include/rtems/rtems/part.h  |   10 +-
 cpukit/include/rtems/rtems/ratemon.h   |5 +-
 cpukit/include/rtems/rtems/region.h|5 +-
 cpukit/include/rtems/rtems/scheduler.h |4 +-
 cpukit/include/rtems/rtems/sem.h   |   10 +-
 cpukit/include/rtems/rtems/support.h   |8 +-
 cpukit/include/rtems/rtems/tasks.h |   49 +-
 cpukit/include/rtems/rtems/timer.h |7 +-
 18 files changed, 1313 insertions(+), 1140 deletions(-)

-- 
2.35.3

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

[PATCH 1/4] doxygen: Use quotes for href URLs

Update #3994.
---
 cpukit/doxygen/appl-config.h | 110 +--
 1 file changed, 55 insertions(+), 55 deletions(-)

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index 964f8d0616..a8d964832e 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -625,7 +625,7 @@
  *
  * @par Notes
  * This object class can be configured in unlimited allocation mode, see https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects>Unlimited
+ * 
href="https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects;>Unlimited
  * Objects.
  */
 #define CONFIGURE_MAXIMUM_BARRIERS
@@ -662,7 +662,7 @@
  *
  * @par Notes
  * This object class can be configured in unlimited allocation mode, see https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects>Unlimited
+ * 
href="https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects;>Unlimited
  * Objects.  You have to account for the memory used to store the messages
  * of each message queue, see #CONFIGURE_MESSAGE_BUFFER_MEMORY.
  */
@@ -700,7 +700,7 @@
  *
  * @par Notes
  * This object class can be configured in unlimited allocation mode, see https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects>Unlimited
+ * 
href="https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects;>Unlimited
  * Objects.
  */
 #define CONFIGURE_MAXIMUM_PARTITIONS
@@ -737,7 +737,7 @@
  *
  * @par Notes
  * This object class can be configured in unlimited allocation mode, see https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects>Unlimited
+ * 
href="https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects;>Unlimited
  * Objects.
  */
 #define CONFIGURE_MAXIMUM_PERIODS
@@ -774,7 +774,7 @@
  *
  * @par Notes
  * This object class can be configured in unlimited allocation mode, see https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects>Unlimited
+ * 
href="https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects;>Unlimited
  * Objects.
  */
 #define CONFIGURE_MAXIMUM_PORTS
@@ -811,7 +811,7 @@
  *
  * @par Notes
  * This object class can be configured in unlimited allocation mode, see https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects>Unlimited
+ * 
href="https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects;>Unlimited
  * Objects.
  */
 #define CONFIGURE_MAXIMUM_REGIONS
@@ -849,14 +849,14 @@
  * @par Notes
  * @parblock
  * This object class can be configured in unlimited allocation mode, see https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects>Unlimited
+ * 
href="https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects;>Unlimited
  * Objects.
  *
  * In SMP configurations, the size of a Semaphore Control Block depends on the
  * scheduler count (see https://docs.rtems.org/branches/master/c-user/config/scheduler-clustered.html#configuration-step-3-scheduler-table>Configuration
+ * 
href="https://docs.rtems.org/branches/master/c-user/config/scheduler-clustered.html#configuration-step-3-scheduler-table;>Configuration
  * Step 3 - Scheduler Table).  The semaphores using the https://docs.rtems.org/branches/master/c-user/key_concepts.html#multiprocessor-resource-sharing-protocol-mrsp>Multiprocessor
+ * 
href="https://docs.rtems.org/branches/master/c-user/key_concepts.html#multiprocessor-resource-sharing-protocol-mrsp;>Multiprocessor
  * Resource Sharing Protocol (MrsP) need a ceiling priority per scheduler.
  * @endparblock
  */
@@ -899,7 +899,7 @@
  * @par Notes
  * @parblock
  * This object class can be configured in unlimited allocation mode, see https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects>Unlimited
+ * 
href="https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects;>Unlimited
  * Objects.
  *
  * The calculations for the required memory in the RTEMS Workspace for tasks
@@ -950,7 +950,7 @@
  *
  * @par Notes
  * This object class can be configured in unlimited allocation mode, see https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects>Unlimited
+ * 
href="https://docs.rtems.org/branches/master/c-user/config/intro.html#unlimited-objects;>Unlimited
  * Objects.
  */
 #define CONFIGURE_MAXIMUM_TIMERS
@@ -1873,7 +1873,7 @@
  *
  * then the event records are dumped in Base64 encoding in a fatal error
  * extension (see https://docs.rtems.org/branches/master/c-user/fatal_error.html#announcing-a-fatal-error>Announcing
+ * 
href="https://docs.rtems.org/branches/master/c-user/fatal_error.html#announcing-a-fatal-error;>Announcing
  * a Fatal Error).
  *
  * @par Default Configuration
@@ -1898,7 +1898,7 @@
  *
  * then the event records are compressed by zlib and dumped in Base64 encoding
  * in a fatal

[PATCH 2/4] doxygen: Clarify CONFIGURE_DISABLE_BSP_SETTINGS

Each BSP may optionally provide default values for some application
configuration options.  Remove the documentation of these items, since
the BSP provided defines are not application configuration options, they
are optional default values.  Clarify CONFIGURE_DISABLE_BSP_SETTINGS
accordingly and move it into the "General System Configuration" group.

Update #3994.
---
 cpukit/doxygen/appl-config.h | 250 +--
 1 file changed, 31 insertions(+), 219 deletions(-)

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index a8d964832e..d48fb11741 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -362,225 +362,6 @@
 
 /** @} */
 
-/* Generated from spec:/acfg/if/group-bsp */
-
-/**
- * @defgroup RTEMSApplConfigBSPRelatedConfigurationOptions \
- *   BSP Related Configuration Options
- *
- * @ingroup RTEMSApplConfig
- *
- * This section describes configuration options related to the BSP.  Some
- * configuration options may have a BSP-specific setting which is defined by
- * .  The BSP-specific settings can be disabled by the
- * #CONFIGURE_DISABLE_BSP_SETTINGS configuration option.
- *
- * @{
- */
-
-/* Generated from spec:/acfg/if/bsp-idle-task-body */
-
-/**
- * @brief This configuration option is an initializer define.
- *
- * If
- *
- * * this configuration option is defined by the BSP
- *
- * * and #CONFIGURE_DISABLE_BSP_SETTINGS is undefined,
- *
- * then the value of this configuration option defines the default value of
- * #CONFIGURE_IDLE_TASK_BODY.
- *
- * @par Default Value
- * The default value is BSP-specific.
- *
- * @par Value Constraints
- * The value of this configuration option shall be defined to a valid function
- * pointer of the type ``void *( *idle_body )( uintptr_t )``.
- *
- * @par Notes
- * As it has knowledge of the specific CPU model, system controller logic, and
- * peripheral buses, a BSP-specific IDLE task may be capable of turning
- * components off to save power during extended periods of no task activity.
- */
-#define BSP_IDLE_TASK_BODY
-
-/* Generated from spec:/acfg/if/bsp-idle-task-stack-size */
-
-/**
- * @brief This configuration option is an integer define.
- *
- * If
- *
- * * this configuration option is defined by the BSP
- *
- * * and #CONFIGURE_DISABLE_BSP_SETTINGS is undefined,
- *
- * then the value of this configuration option defines the default value of
- * #CONFIGURE_IDLE_TASK_STACK_SIZE.
- *
- * @par Default Value
- * The default value is BSP-specific.
- *
- * @par Value Constraints
- * @parblock
- * The value of this configuration option shall satisfy all of the following
- * constraints:
- *
- * * It shall be greater than or equal to a BSP-specific and
- *   application-specific minimum value.
- *
- * * It shall be small enough so that the IDLE task stack area calculation
- *   carried out by  does not overflow an integer of type
- *   https://en.cppreference.com/w/c/types/size_t;>size_t.
- * @endparblock
- */
-#define BSP_IDLE_TASK_STACK_SIZE
-
-/* Generated from spec:/acfg/if/bsp-initial-extension */
-
-/**
- * @brief This configuration option is an initializer define.
- *
- * If
- *
- * * this configuration option is defined by the BSP
- *
- * * and #CONFIGURE_DISABLE_BSP_SETTINGS is undefined,
- *
- * then the value of this configuration option is used to initialize the table
- * of initial user extensions.
- *
- * @par Default Value
- * The default value is BSP-specific.
- *
- * @par Value Constraints
- * The value of this configuration option shall be a list of initializers for
- * structures of type ::rtems_extensions_table.
- *
- * @par Notes
- * The value of this configuration option is placed after the entries of all
- * other initial user extensions.
- */
-#define BSP_INITIAL_EXTENSION
-
-/* Generated from spec:/acfg/if/bsp-interrupt-stack-size */
-
-/**
- * @brief This configuration option is an integer define.
- *
- * If
- *
- * * this configuration option is defined by the BSP
- *
- * * and #CONFIGURE_DISABLE_BSP_SETTINGS is undefined,
- *
- * then the value of this configuration option defines the default value of
- * #CONFIGURE_INTERRUPT_STACK_SIZE.
- *
- * @par Default Value
- * The default value is BSP-specific.
- *
- * @par Value Constraints
- * @parblock
- * The value of this configuration option shall satisfy all of the following
- * constraints:
- *
- * * It shall be greater than or equal to a BSP-specific and
- *   application-specific minimum value.
- *
- * * It shall be small enough so that the interrupt stack area calculation
- *   carried out by  does not overflow an integer of type
- *   https://en.cppreference.com/w/c/types/size_t;>size_t.
- *
- * * It shall be aligned according to #CPU_INTERRUPT_STACK_ALIGNMENT.
- * @endparblock
- */
-#define BSP_INTERRUPT_STACK_SIZE
-
-/* Generated from spec:/acfg/if/bsp-prerequisite-drivers */
-
-/**
- * @brief This configuration option is an initializer define.
- *
- * If
- *
- * * this configuration

Re: libbsd development policy clarification needed?


On 06.02.23 16:06, Gedare Bloom wrote:

Yes, thanks. This looks like a good analysis. I would definitely
prefer to get master and 6-freebsd-12 into harmony. Then it is a
little simpler to discuss the other problems in libbsd.

Vijay had similar kind of success (and problems) as you did with
cherry-picking off of 6-freebsd-12. I think he made it a little
further. I guess one possible route forward would be to begin working
on this effort and share results, pushing to master when some
relatively stable milestones are reached.


This branch already contains an update to FreeBSD head 2020-02-09 (about 
5 months of FreeBSD development):


https://github.com/RTEMS/rtems-libbsd/compare/master...sebhub:rtems-libbsd:master-update

If you start to cherry-pick things to the current master, this effort 
from my side is probably wasted.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libbsd development policy clarification needed?

uld be: Porting the stuff from 6-freebsd-12 to master
should be a few days maximum to a compile clean state. Upgrading
6-freebsd-12 to something that would follow FreeBSD master again
should be something in the range of weeks.


OK, then we should likely follow the path of porting from 6-freebsd-12
to master. I would leave the issue of what to do with FDs as a
separate concern that can be addressed once we solve this underlying
problem.

What would you think is the best way to handle the process though? It
would seem to still require some kind of cherry-picking + patching
FreeBSD and passing some tests? Perhaps it is best to do it that way,
on top of the current master branch, attempting to pick up patches
from the shared ancestor. ("Only in 6-freebsd-12").


I would usually just cherry-pick commits that don't import anything
from FreeBSD. All commits that do import files need a bit more work:
For these, the files from FreeBSD master have to be re-importet.

It's basically the same process that I use to back-port something from
master to 6-freebsd-12. And it's why CONTRIBUTING.md tells that you
should have one commit that only adds the unmodified imported files.
With that it's easy to re-import the files from a different version
and re-apply the patches.

Best regards

Christian


I tried to cherry-pick some of the commits yesterday (hobby time on
Sunday!). The first few patches should work quite well. There are some
minor problems that still have to be cleaned up to make it compile clean.

One of the early ones that makes problems is the path-mappings feature
from Jan Sommer because on master something changed the same code parts.
We need someone who understands both changes to port that.

About starting with Chris kernel symbol namespace tool patch
(59f652fe88) the changes start to get bigger and the patches are harder
to apply. I think the kernel symbol namespace is one of the core patches
that would be important to port, but I don't know the code surrounding
it well enough that I can do it fast.

How should we approach that work? One patch at a time? Maybe together
with pinging the original authors to ask them whether they can port
their patches to master or at least test them there?

For the VFS and NFS parts, it depends a bit on the solution of the
discussion. Sebastian already worked on a re-implementation of NFS on
master (not yet entirely finished):

https://github.com/sebhub/rtems-libbsd/commits/master-update

Of course that is based on his solution without the file descriptors and
without the central system calls. So it depends on the results of the
discussion between Sebastian and Chris whether that patch can be used to
have the NFS functionality in master.



When re-reading the text I noted that mentioning that branch here can
lead into a wrong direction. To make my intention clear: I think we
should concentrate on all unrelated patches at the moment. Parallel we
should try to push the NFS/VFS discussion and help Chris and Sebastian
to agree on one solution that is acceptable for both. Depending on that
solution, it could be simpler to just use that branch and maybe port
only small parts to have a functionally equivalent solution on both
branches with a slightly different history.


Yes, thanks. This looks like a good analysis. I would definitely
prefer to get master and 6-freebsd-12 into harmony. Then it is a
little simpler to discuss the other problems in libbsd.

Vijay had similar kind of success (and problems) as you did with
cherry-picking off of 6-freebsd-12. I think he made it a little
further. I guess one possible route forward would be to begin working
on this effort and share results, pushing to master when some
relatively stable milestones are reached.

Gedare


Hello Gedare,

I made sure to remove every patch that is not compile clean and pushed 
my current working version here:


https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/cm/20230206-port-patches-to-master

At the moment it's cherry-picking patches from 6-freebsd-12 to master as 
long as they apply and compile. I didn't make sure yet that everything 
works or is in a usefull order.


Comparison between this and 6-freebsd-12 is hiere:

https://gist.github.com/620ae08d88dca054c45100a84fdaaee8

Only 35 patches difference left if you ignore the "Update to FreeBSD" 
patches that are branch specific.


A big one will be Chris' 'Implement portable kernel symbol namespace 
tool' and the follow up commits that clean up the kern-symbols. That is 
an important improvement but I don't know yet what is necessary to 
update these patches to master.


Do you think we should create a new mailinglist thread?
Topic: 'libbsd master and 6-freebsd-12 cleanup; help wanted'
Goal: Port all patches from 6-freebsd-12 to master that are not branch 
specific and not related to the currently open questions regarding the 
correct aproach to NFS.

Status: Short summary of what we discussed and what we reached.

Best regards

C

Re: [patch] medit problem

Hi Zack,

thanks for this patch. Can you please provide a first line of commit
message in line with:
https://docs.rtems.org/branches/master/eng/vc-users.html#commit-message-guidance
Specifically, the first line of your commit should preferably start
with "shell:" or "libmisc/shell:" and if possible briefly summarize
what is fixed "shell: fixes cut-and-paste in main_edit ..."

Gedare

On Sat, Feb 4, 2023 at 1:24 PM zack leung  wrote:
>
> fixes #4557
> ---
>  cpukit/libmisc/shell/main_edit.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/libmisc/shell/main_edit.c 
> b/cpukit/libmisc/shell/main_edit.c
> index 191eefa19d..71bb1d931b 100644
> --- a/cpukit/libmisc/shell/main_edit.c
> +++ b/cpukit/libmisc/shell/main_edit.c
> @@ -1710,7 +1710,7 @@ static void copy_selection(struct editor *ed) {
>ed->env->clipboard = (unsigned char *) realloc(ed->env->clipboard, 
> ed->env->clipsize);
>if (!ed->env->clipboard) return;
>copy(ed, ed->env->clipboard, selstart, ed->env->clipsize);
> -  select_toggle(ed);
> +
Avoid adding white space

>  }
>
>  static void cut_selection(struct editor *ed) {
> @@ -2128,7 +2128,7 @@ static void edit(struct editor *ed) {
>
>  case ctrl('e'): select_toggle(ed); break;
>  case ctrl('a'): select_all(ed); break;
> -case ctrl('c'): copy_selection(ed); break;
> +case ctrl('c'): copy_selection(ed); select_toggle(ed); break;
>  case ctrl('f'): find_text(ed, 0); break;
>  case ctrl('l'): goto_line(ed); break;
>  case ctrl('g'): find_text(ed, 1); break;
> --
> 2.39.1
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libbsd development policy clarification needed?

On Mon, Feb 6, 2023 at 2:26 AM Christian MAUDERER
 wrote:
>
> On 2023-02-06 10:02, Christian MAUDERER wrote:
> > On 2023-02-05 11:38, Christian Mauderer wrote:
> >>
> >>
> >> Am 04.02.23 um 01:25 schrieb Gedare Bloom:
> >>> On Fri, Feb 3, 2023 at 3:29 PM Christian Mauderer 
> >>> wrote:
> 
> 
> 
>  Am 3. Februar 2023 22:52:48 MEZ schrieb Gedare Bloom
>  :
> > On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer
> >  wrote:
> >>
> >>
> >>
> >> Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom
> >> :
> >>> On Fri, Feb 3, 2023 at 12:52 PM  wrote:
> 
>  Hello Gedare,
> 
>  Am 03.02.23 um 19:51 schrieb Gedare Bloom:
> > On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER
> >  wrote:
> >>
> >> Hello Karel,
> >>
> >> On 2023-02-02 12:43, Karel Gardas wrote:
> >>>
> >>>  Guys,
> >>>
> >>> recently I needed to work with RTEMS/NFS. As this is provided
> >>> by libbsd
> >>> I took this and following two sentences below from master branch
> >>> description provided in README I took as granted that master
> >>> does have
> >>> all the features which are currently available and provided
> >>> by the project:
> >>>
> >>> "This branch must be used for libbsd development. Back ports
> >>> to the
> >>> 6-freebsd-12 are allowed."
> >>>
> >>> I was surprised to be proven wrong then by Fabrizio here:
> >>> https://devel.rtems.org/ticket/4723
> >>>
> >>> and by later investigation which shows that 6-freebsd-12 branch
> >>> accumulated NFS work by Chris done in 2021 which is not
> >>> presented on
> >>> master. I've investigated just NFS as this was my focus here.
> >>>
> >>> So if 6-freebsd-12 became development branch of some sort,
> >>> then it would
> >>> be great to have that clarified in the project README file to
> >>> prevent
> >>> users confusion? Or if the policy is still the same, then
> >>> perhaps some
> >>> branch sync is needed here?
> >>
> >> That currently is an open issue. Basically there is a pending
> >> patch set
> >> that should fix that since several months. But there is a
> >> disagreement
> >> about some of the changes in that patch set (and about the
> >> patches
> >> checked in to 6-freebsd-12). Therefore, it still hasn't been
> >> merged.
> >>
> >> If you want to know some more about the problematic points, I
> >> recommend
> >> reading this (long) thread:
> >>
> >> https://lists.rtems.org/pipermail/devel/2023-January/074164.html
> >>
> >> The statement that development has to happen on the master
> >> branch is
> >> still true. The master is intended to track the FreeBSD upstream
> >> development. Only changes on that branch are guaranteed to
> >> live through
> >> an upgrade to a newer base version of FreeBSD. It's very
> >> unfortunate,
> >> that there are some patches on the 6-freebsd-12 branch only.
> >> On the long
> >> term, that issue has to be resolved.
> >>
> >
> > I have been investigating this problem in the background, and I
> > have
> > some findings and some questions. First, I have found that
> > there is a
> > most-common ancestor between master and 6-freebsd-12 at commit
> > https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976
> > This is at least promising that the discrepancy between the
> > branches
> > can be resolved.
> >
> > The proposed pending patch set to "fix" the NFS issue does not
> > fix the
> > underlying problem. Instead, it introduces further divergence
> > between
> > the branches. I would instead suggest that we should resolve to
> > fix
> > the underlying problem. I can see two paths forward.
> >
> > 1. Abandon 6-freebsd-12 after releasing 6. This is probably not
> > ideal
> > since what I understand is some users have projects based on
> > 6-freebsd-12 and would like an upgrade path. (I guess there is
> > also
> > the option to abandon master, which also makes little sense.)
> 
>  A variant for this would be to introduce a 6-freebsd-13 that is
>  based on
>  the master branch as soon as we have one. That would allow a longer
>  maintenance because FreeBSD 12 reaches it's EoL December 2023.
> 
> >
> > 2. Pull commits from 6-freebsd-12 into master to make sure
> > master is

Re: [PATCH] wscript: Deduplicate installed files


On 06.02.23 15:30, Joel Sherrill wrote:
On Mon, Feb 6, 2023 at 12:55 AM Sebastian Huber 
> wrote:




On 06.02.23 03:35, Chris Johns wrote:
 > On 4/2/2023 6:11 am, Sebastian Huber wrote:
 >> On 03.02.23 19:45, Kinsey Moore wrote:
 >>> This is my first stab at solving this duplicate install
problem. I could
 >>> manually solve the problem by deduplicating the object includes
and moving it
 >>> up to the BSP, but that is less intuitive since these drivers
both depend on
 >>> the same code and the BSP doesn't depend on it directly.
 >>
 >> Why don't you add the shared stuff to a objxilcommon.yml?
 >>
 >> The approach in the wscript is a bit complex from my point of view.
 >
 > I am OK with adding this code or something similar. It is no more
complex than
 > other places I have reviewed, eg `Item._init_link()`.
 >
 > The issue is currently not easy to see and may be present in
other places
 > without us knowing. I am also fine with a spec file check that
highlights a
 > clash to draw attention to a problem when the spec files are
parsed. I feeling
 > we need something.

If you install with

./waf install -vv

you see the duplicate install targets. See also

https://gitlab.com/ita1024/waf/-/issues/2329#note_467849523


Before we add double for loops we should first analyze the underlying
problem. In this case it is a diamond shaped build dependency graph.

spec/build/bsps/objnandpsu.yml:  uid: objxilinxsupport
spec/build/bsps/objqspipsu.yml:  uid: objxilinxsupport
spec/build/bsps/aarch64/xilinx-zynqmp/objjffs2qspinor.yml:  uid:
../../objqspipsu
spec/build/bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml:  uid:
../../objnandpsu

In addition to the duplicate install targets you build also the objects
of objxilinxsupport twice and add them to the library.

I would simply move the links to grp_zu3eg:

grp_zu3eg.yml:  uid: ../../objxilinxspport
grp_zu3eg.yml:  uid: ../../objnandpsu
grp_zu3eg.yml:  uid: ../../objqspipsu


That's the solution in this case but wouldn't it be nice to detect it 
reliably and

address it when it shows up again.


You can detect the issue with by calling ./waf -vv install. This is what 
the maintainer of waf recommends:


https://gitlab.com/ita1024/waf/-/issues/2329#note_467849523

I would rather try to get these warnings by default from waf instead of 
tinkering with special case solutions above waf.


The patch doesn't address the issue with the multiple object files in 
the library.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] wscript: Deduplicate installed files

2023-02-06 Thread Joel Sherrill

On Mon, Feb 6, 2023 at 12:55 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 06.02.23 03:35, Chris Johns wrote:
> > On 4/2/2023 6:11 am, Sebastian Huber wrote:
> >> On 03.02.23 19:45, Kinsey Moore wrote:
> >>> This is my first stab at solving this duplicate install problem. I
> could
> >>> manually solve the problem by deduplicating the object includes and
> moving it
> >>> up to the BSP, but that is less intuitive since these drivers both
> depend on
> >>> the same code and the BSP doesn't depend on it directly.
> >>
> >> Why don't you add the shared stuff to a objxilcommon.yml?
> >>
> >> The approach in the wscript is a bit complex from my point of view.
> >
> > I am OK with adding this code or something similar. It is no more
> complex than
> > other places I have reviewed, eg `Item._init_link()`.
> >
> > The issue is currently not easy to see and may be present in other places
> > without us knowing. I am also fine with a spec file check that
> highlights a
> > clash to draw attention to a problem when the spec files are parsed. I
> feeling
> > we need something.
>
> If you install with
>
> ./waf install -vv
>
> you see the duplicate install targets. See also
>
> https://gitlab.com/ita1024/waf/-/issues/2329#note_467849523
>
> Before we add double for loops we should first analyze the underlying
> problem. In this case it is a diamond shaped build dependency graph.
>
> spec/build/bsps/objnandpsu.yml:  uid: objxilinxsupport
> spec/build/bsps/objqspipsu.yml:  uid: objxilinxsupport
> spec/build/bsps/aarch64/xilinx-zynqmp/objjffs2qspinor.yml:  uid:
> ../../objqspipsu
> spec/build/bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml:  uid: ../../objnandpsu
>
> In addition to the duplicate install targets you build also the objects
> of objxilinxsupport twice and add them to the library.
>
> I would simply move the links to grp_zu3eg:
>
> grp_zu3eg.yml:  uid: ../../objxilinxspport
> grp_zu3eg.yml:  uid: ../../objnandpsu
> grp_zu3eg.yml:  uid: ../../objqspipsu
>

That's the solution in this case but wouldn't it be nice to detect it
reliably and
address it when it shows up again.

--joel

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd] CONTRIBUTING: Sharpen priority development goals

2023-02-06 Thread Karel Gardas


On 2/6/23 05:16, Chris Johns wrote:

+   * A lot of different hardware uses LibBSD as network or USB stack or maybe 
in
+ the future even only for other subsystems.  Some of the targets have
+ hundreds of megabytes memory.  Others can only have a few megabytes (like
+ the ATSAMV71).  Make sure that changes don't increase the RAM / Flash size
+ of the default build so that it can't be used on the small targets.


This is not realistic or achievable and I find confusing the reasons it is being
pushed over and over. I would have not have agreed to this being added before
now and nothing has changed. The central reason for rejecting this statement is
a change in FreeBSD may add a few meg of memory to the footprint and this type
of statement would conflict with that addition and that in turn would conflict
with the need for transparency of source. And as stated before transparency must
be preferred.

System requirements are for the developers of those systems and not RTEMS.
Derating designs is an important part of system design and not the domain of
this project. Memory constrained systems can consider another networking stack
option or bespoke changes internally maintained. That is a cost trade off no one
here can help make.


From the discussion it looks like guys from embedded brains push that 
policy forward I mean policy that memory consumption is somehow 
important metric for patch acceptance. Seeing their commit track log I 
would not oppose that rule that much as at the end of the day somebody 
needs to do the job and from the log it looks like embedded brains stay 
behind their word.


As an RTEMS user here, I'm curious if this discussion about few 
paragraphs in CONTRIBUTING file is not too much over-thinking of the 
issue. So far majority of patches were done by just three subjects: 
embedded brains, aorcorp and you. So I would assume that engineering 
discussion with respect for each other contribution and energy spent 
should result in a policy which may be vague and compromise but working 
well for what you all guys do for us RTEMS users here...


Thanks!
Karel

rtems@silence:~/git/rtems/ssh-rtems-libbsd$ git shortlog -s -n --all 
--no-merges

  1554  Sebastian Huber
   242  Christian Mauderer
   242  Joel Sherrill
   175  Chris Johns
   163  Jennifer Averett
31  Kevin Kirspel
31  Kinsey Moore
25  Vijay Kumar Banerjee
21  Jan Sommer
12  Moyano, Gabriel
12  Sichen Zhao

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

Re: libbsd development policy clarification needed?

On 2023-02-06 10:02, Christian MAUDERER wrote:

On 2023-02-05 11:38, Christian Mauderer wrote:

Am 04.02.23 um 01:25 schrieb Gedare Bloom:
On Fri, Feb 3, 2023 at 3:29 PM Christian Mauderer
wrote:

Am 3. Februar 2023 22:52:48 MEZ schrieb Gedare Bloom
:
On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer
wrote:

Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom
:

On Fri, Feb 3, 2023 at 12:52 PM wrote:

Hello Gedare,

Am 03.02.23 um 19:51 schrieb Gedare Bloom:

On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER
wrote:

Hello Karel,

On 2023-02-02 12:43, Karel Gardas wrote:

Guys,

recently I needed to work with RTEMS/NFS. As this is provided
by libbsd

I took this and following two sentences below from master branch
description provided in README I took as granted that master
does have
all the features which are currently available and provided
by the project:

"This branch must be used for libbsd development. Back ports
to the

6-freebsd-12 are allowed."

I was surprised to be proven wrong then by Fabrizio here:
https://devel.rtems.org/ticket/4723

and by later investigation which shows that 6-freebsd-12 branch
accumulated NFS work by Chris done in 2021 which is not
presented on

master. I've investigated just NFS as this was my focus here.

So if 6-freebsd-12 became development branch of some sort,
then it would
be great to have that clarified in the project README file to
prevent
users confusion? Or if the policy is still the same, then
perhaps some

branch sync is needed here?

That currently is an open issue. Basically there is a pending
patch set
that should fix that since several months. But there is a
disagreement
about some of the changes in that patch set (and about the
patches
checked in to 6-freebsd-12). Therefore, it still hasn't been
merged.

If you want to know some more about the problematic points, I
recommend

reading this (long) thread:

https://lists.rtems.org/pipermail/devel/2023-January/074164.html

The statement that development has to happen on the master
branch is

still true. The master is intended to track the FreeBSD upstream
development. Only changes on that branch are guaranteed to
live through
an upgrade to a newer base version of FreeBSD. It's very
unfortunate,
that there are some patches on the 6-freebsd-12 branch only.
On the long

term, that issue has to be resolved.

I have been investigating this problem in the background, and I
have
some findings and some questions. First, I have found that
there is a

most-common ancestor between master and 6-freebsd-12 at commit
https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976
This is at least promising that the discrepancy between the
branches

can be resolved.

The proposed pending patch set to "fix" the NFS issue does not
fix the
underlying problem. Instead, it introduces further divergence
between
the branches. I would instead suggest that we should resolve to
fix

the underlying problem. I can see two paths forward.

1. Abandon 6-freebsd-12 after releasing 6. This is probably not
ideal

since what I understand is some users have projects based on
6-freebsd-12 and would like an upgrade path. (I guess there is
also

the option to abandon master, which also makes little sense.)

A variant for this would be to introduce a 6-freebsd-13 that is
based on

the master branch as soon as we have one. That would allow a longer
maintenance because FreeBSD 12 reaches it's EoL December 2023.

2. Pull commits from 6-freebsd-12 into master to make sure
master is

the development head. in the future, reject patches that only go
toward release branches. This has its own problems too. It can
realistically only be done in three ways:

Please note that Sebastian mentioned that the file descriptors
broke the
NTP support (at least I think it was NTP; possible that it was
another

submodule). So picking the current version of the patches into the
master without adding fixes makes the master unusable for some
cases.

Fixing the problems after making the branches the same will be
better

for the long-term, if we can find a path to do it.

2a: Rebase master and cherry-pick commits from 6-freebsd-12 and
master

back into master. This rewrites the history of master, and
unfortunately will cause the head of 5-freebsd-12 and the tags for
rtems-5 to no longer exist on the master branch. They will
still exist
in the '5' branch. The advantage is in the end there will be a
linear
history of development on master that reflects the timeline of
actual

development that spanned both branches. Theoretically, this should
make it easier to git-bisect.

2b: Cherry-pick commits from 6-freebsd-12 to master and fix
conflicts.
This puts all the missing commits from 6-freebsd-12 on to the
current

head of master. I don't know how messy this would be. It ends up
making the history of master convoluted to understand, with
fairly old

commits from 2018

Re: libbsd development policy clarification needed?

On 2023-02-05 11:38, Christian Mauderer wrote:

Am 04.02.23 um 01:25 schrieb Gedare Bloom:
On Fri, Feb 3, 2023 at 3:29 PM Christian Mauderer
wrote:

Am 3. Februar 2023 22:52:48 MEZ schrieb Gedare Bloom :
On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer
wrote:

Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom
:

On Fri, Feb 3, 2023 at 12:52 PM wrote:

Hello Gedare,

Am 03.02.23 um 19:51 schrieb Gedare Bloom:

On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER
wrote:

Hello Karel,

On 2023-02-02 12:43, Karel Gardas wrote:

Guys,

recently I needed to work with RTEMS/NFS. As this is provided
by libbsd

"This branch must be used for libbsd development. Back ports
to the

6-freebsd-12 are allowed."

I was surprised to be proven wrong then by Fabrizio here:
https://devel.rtems.org/ticket/4723

and by later investigation which shows that 6-freebsd-12 branch
accumulated NFS work by Chris done in 2021 which is not
presented on

master. I've investigated just NFS as this was my focus here.

branch sync is needed here?

That currently is an open issue. Basically there is a pending
patch set
that should fix that since several months. But there is a
disagreement

about some of the changes in that patch set (and about the patches
checked in to 6-freebsd-12). Therefore, it still hasn't been
merged.

If you want to know some more about the problematic points, I
recommend

reading this (long) thread:

https://lists.rtems.org/pipermail/devel/2023-January/074164.html

The statement that development has to happen on the master
branch is

still true. The master is intended to track the FreeBSD upstream
development. Only changes on that branch are guaranteed to live
through
an upgrade to a newer base version of FreeBSD. It's very
unfortunate,
that there are some patches on the 6-freebsd-12 branch only. On
the long

term, that issue has to be resolved.

I have been investigating this problem in the background, and I
have
some findings and some questions. First, I have found that there
is a

can be resolved.

The proposed pending patch set to "fix" the NFS issue does not
fix the
underlying problem. Instead, it introduces further divergence
between

the branches. I would instead suggest that we should resolve to fix
the underlying problem. I can see two paths forward.

1. Abandon 6-freebsd-12 after releasing 6. This is probably not
ideal

since what I understand is some users have projects based on
6-freebsd-12 and would like an upgrade path. (I guess there is also
the option to abandon master, which also makes little sense.)

A variant for this would be to introduce a 6-freebsd-13 that is
based on

the master branch as soon as we have one. That would allow a longer
maintenance because FreeBSD 12 reaches it's EoL December 2023.

2. Pull commits from 6-freebsd-12 into master to make sure
master is

the development head. in the future, reject patches that only go
toward release branches. This has its own problems too. It can
realistically only be done in three ways:

Please note that Sebastian mentioned that the file descriptors
broke the
NTP support (at least I think it was NTP; possible that it was
another

submodule). So picking the current version of the patches into the
master without adding fixes makes the master unusable for some
cases.

Fixing the problems after making the branches the same will be better
for the long-term, if we can find a path to do it.

2a: Rebase master and cherry-pick commits from 6-freebsd-12 and
master

back into master. This rewrites the history of master, and
unfortunately will cause the head of 5-freebsd-12 and the tags for
rtems-5 to no longer exist on the master branch. They will still
exist
in the '5' branch. The advantage is in the end there will be a
linear
history of development on master that reflects the timeline of
actual

development that spanned both branches. Theoretically, this should
make it easier to git-bisect.

2b: Cherry-pick commits from 6-freebsd-12 to master and fix
conflicts.
This puts all the missing commits from 6-freebsd-12 on to the
current

head of master. I don't know how messy this would be. It ends up
making the history of master convoluted to understand, with
fairly old

commits from 2018 being placed on top of newer commits from 2020s.

2c:

Re: [PATCH 2/2] RISC-V: Test rv32i and rv32imafdc on QEMU

2023-02-06 Thread Hesham Almatary

This needs to be merged for the tests to pass.


On Mon, 9 Jan 2023 at 18:28, Hesham Almatary
 wrote:
>
> Is this patchset fine to merge?
>
> On Fri, 23 Dec 2022 at 09:25,  wrote:
> >
> > From: Hesham Almatary 
> >
> > Updates #4775
> > ---
> >  tester/rtems/testing/bsps/rv32i.ini  | 37 
> >  tester/rtems/testing/bsps/rv32imafdc.ini | 37 
> >  2 files changed, 74 insertions(+)
> >  create mode 100644 tester/rtems/testing/bsps/rv32i.ini
> >  create mode 100644 tester/rtems/testing/bsps/rv32imafdc.ini
> >
> > diff --git a/tester/rtems/testing/bsps/rv32i.ini 
> > b/tester/rtems/testing/bsps/rv32i.ini
> > new file mode 100644
> > index 000..1817216
> > --- /dev/null
> > +++ b/tester/rtems/testing/bsps/rv32i.ini
> > @@ -0,0 +1,37 @@
> > +#
> > +# RTEMS Tools Project (http://www.rtems.org/)
> > +# Copyright 2020 Hesham Almatary
> > +# Copyright 2018 embedded brains GmbH
> > +# All rights reserved.
> > +#
> > +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> > +#
> > +# Redistribution and use in source and binary forms, with or without
> > +# modification, are permitted provided that the following conditions are 
> > met:
> > +#
> > +# 1. Redistributions of source code must retain the above copyright notice,
> > +# this list of conditions and the following disclaimer.
> > +#
> > +# 2. Redistributions in binary form must reproduce the above copyright 
> > notice,
> > +# this list of conditions and the following disclaimer in the documentation
> > +# and/or other materials provided with the distribution.
> > +#
> > +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> > IS"
> > +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> > +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
> > PURPOSE
> > +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
> > +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> > +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> > +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> > +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> > +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 
> > THE
> > +# POSSIBILITY OF SUCH DAMAGE.
> > +#
> > +
> > +[rv32i]
> > +bsp   = rv32i
> > +arch  = riscv32
> > +tester= %{_rtscripts}/qemu.cfg
> > +bsp_qemu_image_type = -bios
> > +bsp_qemu_opts = -no-reboot -nographic %{qemu_opts_no_net} -machine virt -m 
> > 128M
> > diff --git a/tester/rtems/testing/bsps/rv32imafdc.ini 
> > b/tester/rtems/testing/bsps/rv32imafdc.ini
> > new file mode 100644
> > index 000..2f91a9a
> > --- /dev/null
> > +++ b/tester/rtems/testing/bsps/rv32imafdc.ini
> > @@ -0,0 +1,37 @@
> > +#
> > +# RTEMS Tools Project (http://www.rtems.org/)
> > +# Copyright 2020 Hesham Almatary
> > +# Copyright 2018 embedded brains GmbH
> > +# All rights reserved.
> > +#
> > +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> > +#
> > +# Redistribution and use in source and binary forms, with or without
> > +# modification, are permitted provided that the following conditions are 
> > met:
> > +#
> > +# 1. Redistributions of source code must retain the above copyright notice,
> > +# this list of conditions and the following disclaimer.
> > +#
> > +# 2. Redistributions in binary form must reproduce the above copyright 
> > notice,
> > +# this list of conditions and the following disclaimer in the documentation
> > +# and/or other materials provided with the distribution.
> > +#
> > +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> > IS"
> > +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> > +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
> > PURPOSE
> > +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
> > +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> > +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> > +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> > +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> > +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 
> > THE
> > +# POSSIBILITY OF SUCH DAMAGE.
> > +#
> > +
> > +[rv32imafdc]
> > +bsp   = rv32imafdc
> > +arch  = riscv32
> > +tester= %{_rtscripts}/qemu.cfg
> > +bsp_qemu_image_type = -bios
> > +bsp_qemu_opts = -no-reboot -nographic %{qemu_opts_no_net} -machine virt -m 
> > 128M
> > --
> > 2.25.1
> >
___
devel mailing list
devel@rtems.org

Re: [PATCH rtems-libbsd] CONTRIBUTING: Sharpen priority development goals