Hi all,

UCLINUX is broken in LTP and nobody really cares. Actually I dare to
say UCLINUX is dead. Therefore I prepared patchset to remove UCLINUX
from LTP. We have been actively removing UCLINUX from LTP during rewrite
tests to new LTP API. This removes the rest from the old tests (which
will be sooner or later rewritten to new API).

Because the patchset is quite big, I did not want to send it to mailing
lists (but I can do it if you want).

Can you please have look at my fork on gitlab, branch: remove-UCLINUX
https://gitlab.com/pevik/ltp/-/commits/remove-UCLINUX?ref_type=heads

Build test:
https://github.com/pevik/ltp/actions/runs/7392470215

Kind regards,
Petr

Petr Vorel (36):
  m4: Remove UCLINUX detection
  make: Remove WITH_POWER_MANAGEMENT_TESTSUITE
  make: Remove UCLINUX
  test.h: Remove MAP_PRIVATE_EXCEPT_UCLINUX
  tree: Remove FORK_OR_VFORK and tst_vfork()
  lib/parse_opts.c: Remove UCLINUX
  tlibio.c: Remove UCLINUX
  clone02: Remove UCLINUX
  connect01: Remove UCLINUX
  creat06: Remove UCLINUX
  fcntl: Remove UCLINUX
  getpeername01: Remove UCLINUX
  getsockname01: Remove UCLINUX
  getsockopt01: Remove UCLINUX
  semctl06: Remove UCLINUX
  kill: Remove UCLINUX
  madvise02: Remove UCLINUX
  mlockall: Remove UCLINUX
  waitpid: Remove UCLINUX
  munmap: Remove UCLINUX
  writev05: Remove UCLINUX
  pipe: Remove UCLINUX
  pause: Remove UCLINUX
  recv*: Remove UCLINUX
  send*: Remove UCLINUX
  sock*: Remove UCLINUX
  munlockall01: Remove UCLINUX
  read02: Remove UCLINUX
  setgroups04: Remove UCLINUX
  setsid01: Remove UCLINUX
  sigrelse01: Remove UCLINUX
  sysinfo02: Remove UCLINUX
  ustat02: Remove UCLINUX
  lib: Remove -C option and self_exec.c
  Remove doc/nommu-notes.txt
  doc: UCLINUX has been removed

 Makefile                                      |   7 -
 configure.ac                                  |   1 -
 ...Maintainer-Patch-Review-Checklist.asciidoc |   3 -
 doc/nommu-notes.txt                           | 171 -------------
 include/mk/env_post.mk                        |   4 -
 include/mk/features.mk.in                     |  11 -
 include/old/test.h                            |  21 --
 lib/parse_opts.c                              |  23 +-
 lib/self_exec.c                               | 225 ------------------
 lib/tlibio.c                                  |   2 +-
 lib/tst_res.c                                 |   8 -
 lib/tst_test.c                                |  15 --
 m4/ltp-nommu-linux.m4                         |  14 --
 runtest/Makefile                              |   4 -
 testcases/kernel/Makefile                     |   7 +-
 testcases/kernel/syscalls/Makefile            |   5 -
 testcases/kernel/syscalls/access/Makefile     |   4 -
 testcases/kernel/syscalls/clone/clone02.c     |   5 -
 testcases/kernel/syscalls/connect/connect01.c |  17 +-
 testcases/kernel/syscalls/creat/creat06.c     |   6 -
 testcases/kernel/syscalls/epoll/epoll-ltp.c   |   4 +-
 testcases/kernel/syscalls/exit/exit01.c       |   2 +-
 testcases/kernel/syscalls/fcntl/fcntl07.c     |   2 +-
 testcases/kernel/syscalls/fcntl/fcntl11.c     |  16 +-
 testcases/kernel/syscalls/fcntl/fcntl14.c     |  52 +---
 testcases/kernel/syscalls/fcntl/fcntl16.c     |  29 +--
 testcases/kernel/syscalls/fcntl/fcntl17.c     |  59 +----
 testcases/kernel/syscalls/fcntl/fcntl18.c     |  12 +-
 testcases/kernel/syscalls/fcntl/fcntl19.c     |  15 +-
 testcases/kernel/syscalls/fcntl/fcntl20.c     |  16 +-
 testcases/kernel/syscalls/fcntl/fcntl21.c     |  18 +-
 testcases/kernel/syscalls/fcntl/fcntl22.c     |   2 +-
 .../syscalls/getpeername/getpeername01.c      |   2 -
 .../syscalls/getsockname/getsockname01.c      |   3 -
 .../kernel/syscalls/getsockopt/getsockopt01.c |   2 -
 testcases/kernel/syscalls/ipc/msgsnd/Makefile |   4 -
 .../syscalls/ipc/msgstress/msgstress01.c      |   4 +-
 .../syscalls/ipc/msgstress/msgstress02.c      |   6 +-
 .../syscalls/ipc/msgstress/msgstress03.c      |   4 +-
 .../syscalls/ipc/msgstress/msgstress04.c      |   6 +-
 .../kernel/syscalls/ipc/semctl/semctl06.c     |   9 +-
 testcases/kernel/syscalls/kill/kill02.c       | 101 +-------
 testcases/kernel/syscalls/kill/kill07.c       |  12 +-
 testcases/kernel/syscalls/kill/kill08.c       |  15 +-
 testcases/kernel/syscalls/kill/kill09.c       |  13 +-
 testcases/kernel/syscalls/kill/kill12.c       |   2 +-
 testcases/kernel/syscalls/madvise/madvise02.c |  25 +-
 .../kernel/syscalls/mlockall/mlockall01.c     |  12 -
 .../kernel/syscalls/mlockall/mlockall02.c     |  12 -
 .../kernel/syscalls/mlockall/mlockall03.c     |  12 -
 .../kernel/syscalls/modify_ldt/modify_ldt02.c |   2 +-
 .../kernel/syscalls/mprotect/mprotect02.c     |   4 +-
 .../kernel/syscalls/mprotect/mprotect03.c     |   2 +-
 .../kernel/syscalls/munlockall/munlockall01.c |  12 -
 testcases/kernel/syscalls/munmap/munmap01.c   |  18 +-
 testcases/kernel/syscalls/munmap/munmap02.c   |  18 --
 testcases/kernel/syscalls/munmap/munmap03.c   |   3 +-
 testcases/kernel/syscalls/pause/pause02.c     |  11 +-
 testcases/kernel/syscalls/pause/pause03.c     |  13 +-
 testcases/kernel/syscalls/pipe/pipe02.c       |   9 -
 testcases/kernel/syscalls/pipe/pipe04.c       |  23 +-
 testcases/kernel/syscalls/pipe/pipe09.c       |   4 +-
 testcases/kernel/syscalls/read/read02.c       |   4 -
 testcases/kernel/syscalls/recv/recv01.c       |  19 +-
 .../kernel/syscalls/recvfrom/recvfrom01.c     |  17 +-
 testcases/kernel/syscalls/rename/rename14.c   |   4 +-
 testcases/kernel/syscalls/send/send01.c       |  23 +-
 testcases/kernel/syscalls/sendmsg/sendmsg01.c |  16 +-
 testcases/kernel/syscalls/sendto/sendto01.c   |  23 +-
 .../kernel/syscalls/setfsuid/setfsuid04.c     |   4 +-
 .../kernel/syscalls/setgroups/setgroups04.c   |  12 -
 testcases/kernel/syscalls/setpgid/setpgid01.c |   2 +-
 testcases/kernel/syscalls/setpgrp/setpgrp01.c |   2 +-
 testcases/kernel/syscalls/setpgrp/setpgrp02.c |   2 +-
 .../kernel/syscalls/setrlimit/setrlimit01.c   |   6 +-
 testcases/kernel/syscalls/setsid/setsid01.c   |  29 +--
 .../kernel/syscalls/sigrelse/sigrelse01.c     |  20 +-
 .../kernel/syscalls/socketpair/socketpair01.c |   2 -
 .../kernel/syscalls/sockioctl/sockioctl01.c   |   2 -
 testcases/kernel/syscalls/sysinfo/sysinfo02.c |  12 -
 testcases/kernel/syscalls/ustat/ustat02.c     |   2 -
 testcases/kernel/syscalls/waitpid/waitpid02.c |  10 +-
 testcases/kernel/syscalls/waitpid/waitpid03.c |  28 +--
 testcases/kernel/syscalls/waitpid/waitpid04.c |   2 +-
 testcases/kernel/syscalls/waitpid/waitpid05.c |  28 +--
 testcases/kernel/syscalls/writev/Makefile     |   4 -
 testcases/kernel/syscalls/writev/writev02.c   |   3 +-
 testcases/kernel/syscalls/writev/writev05.c   |  15 +-
 testcases/kernel/syscalls/writev/writev06.c   |   8 +-
 89 files changed, 105 insertions(+), 1337 deletions(-)
 delete mode 100644 doc/nommu-notes.txt
 delete mode 100644 lib/self_exec.c
 delete mode 100644 m4/ltp-nommu-linux.m4

-- 
2.43.0

Hi Petr,

CC other uClinux arch lists

On Wed, Jan 3, 2024 at 2:52 AM Petr Vorel <pvorel@suse.cz> wrote:
> UCLINUX is broken in LTP and nobody really cares. Actually I dare to
> say UCLINUX is dead. Therefore I prepared patchset to remove UCLINUX
> from LTP. We have been actively removing UCLINUX from LTP during rewrite
> tests to new LTP API. This removes the rest from the old tests (which
> will be sooner or later rewritten to new API).
>
> Because the patchset is quite big, I did not want to send it to mailing
> lists (but I can do it if you want).
>
> Can you please have look at my fork on gitlab, branch: remove-UCLINUX
> https://gitlab.com/pevik/ltp/-/commits/remove-UCLINUX?ref_type=heads
>
> Build test:
> https://github.com/pevik/ltp/actions/runs/7392470215

Thanks for your series!

I see you only CCed linux-m68k, but AFAIK, uClinux is not restricted
to m68k/coldfire, but also available on arm32, riscv, sh, and xtensa.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On 1/3/24 03:46, Geert Uytterhoeven wrote:
> Hi Petr,
> 
> CC other uClinux arch lists
> 
> On Wed, Jan 3, 2024 at 2:52 AM Petr Vorel <pvorel@suse.cz> wrote:
>> UCLINUX is broken in LTP and nobody really cares. Actually I dare to
>> say UCLINUX is dead. Therefore I prepared patchset to remove UCLINUX
>> from LTP. We have been actively removing UCLINUX from LTP during rewrite
>> tests to new LTP API. This removes the rest from the old tests (which
>> will be sooner or later rewritten to new API).
>>
>> Because the patchset is quite big, I did not want to send it to mailing
>> lists (but I can do it if you want).
>>
>> Can you please have look at my fork on gitlab, branch: remove-UCLINUX
>> https://gitlab.com/pevik/ltp/-/commits/remove-UCLINUX?ref_type=heads
>>
>> Build test:
>> https://github.com/pevik/ltp/actions/runs/7392470215
> 
> Thanks for your series!
> 
> I see you only CCed linux-m68k, but AFAIK, uClinux is not restricted
> to m68k/coldfire, but also available on arm32, riscv, sh, and xtensa.

Do you mean "nommu support", or do you mean the ancient distro Jeff Dionne
stopped maintaining in 2003?

Because I've been doing nommu musl-libc systems for a few years now. Works for me...

Rob

Hi Geert,

> Hi Petr,

> CC other uClinux arch lists

> On Wed, Jan 3, 2024 at 2:52 AM Petr Vorel <pvorel@suse.cz> wrote:
> > UCLINUX is broken in LTP and nobody really cares. Actually I dare to
> > say UCLINUX is dead. Therefore I prepared patchset to remove UCLINUX
> > from LTP. We have been actively removing UCLINUX from LTP during rewrite
> > tests to new LTP API. This removes the rest from the old tests (which
> > will be sooner or later rewritten to new API).

> > Because the patchset is quite big, I did not want to send it to mailing
> > lists (but I can do it if you want).

> > Can you please have look at my fork on gitlab, branch: remove-UCLINUX
> > https://gitlab.com/pevik/ltp/-/commits/remove-UCLINUX?ref_type=heads

> > Build test:
> > https://github.com/pevik/ltp/actions/runs/7392470215

> Thanks for your series!

Thank you for your feedback.  May I add your Acked-by: tag to the series when we
agree to merge?

> I see you only CCed linux-m68k, but AFAIK, uClinux is not restricted
> to m68k/coldfire, but also available on arm32, riscv, sh, and xtensa.

Good point, I'll reply to their lists as well.

Kind regards,
Petr

> Gr{oetje,eeting}s,

>                         Geert

Hi Petr,

On Wed, Jan 3, 2024 at 12:50 PM Petr Vorel <pvorel@suse.cz> wrote:
> > On Wed, Jan 3, 2024 at 2:52 AM Petr Vorel <pvorel@suse.cz> wrote:
> > > UCLINUX is broken in LTP and nobody really cares. Actually I dare to
> > > say UCLINUX is dead. Therefore I prepared patchset to remove UCLINUX
> > > from LTP. We have been actively removing UCLINUX from LTP during rewrite
> > > tests to new LTP API. This removes the rest from the old tests (which
> > > will be sooner or later rewritten to new API).
>
> > > Because the patchset is quite big, I did not want to send it to mailing
> > > lists (but I can do it if you want).
>
> > > Can you please have look at my fork on gitlab, branch: remove-UCLINUX
> > > https://gitlab.com/pevik/ltp/-/commits/remove-UCLINUX?ref_type=heads
>
> > > Build test:
> > > https://github.com/pevik/ltp/actions/runs/7392470215
>
> > Thanks for your series!
>
> Thank you for your feedback.  May I add your Acked-by: tag to the series when we
> agree to merge?

I am not sure I agree with this series.
Removing support for UCLINUX from LTP is almost a guarantee for
not noticing when more breakage is introduced.

How exactly is UCLINUX broken in LTP?

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Hi!
> I am not sure I agree with this series.
> Removing support for UCLINUX from LTP is almost a guarantee for
> not noticing when more breakage is introduced.
> 
> How exactly is UCLINUX broken in LTP?

As far as we know noone is using it and nobody is maintaing it for a
decade, so it's bitrotting and we do not have manpower to fix it, or
rather we do not want to invest the scarcely limited resources we have
into something that is niche at best. We asked repeatedly if anyone want
to invest time into keeping it alive, but nobody answered the call so
far and I doubt that it will happen at this point.

-- 
Cyril Hrubis
chrubis@suse.cz

On 1/3/24 06:09, Cyril Hrubis wrote:
> Hi!
>> I am not sure I agree with this series.
>> Removing support for UCLINUX from LTP is almost a guarantee for
>> not noticing when more breakage is introduced.
>> 
>> How exactly is UCLINUX broken in LTP?
> 
> As far as we know noone is using it and nobody is maintaing it for a
> decade,

Nobody is maintaining "uclinux" because that was a distro, but you can build
nommu support in buildroot and such, and people do.

Rob

Hi!

My 2 cents. I'm working on refactoring growfiles test which uses UCLINUX 
flag.
During its development I had occasion to check UCLINUX support and 
(indeed) it seems pretty
broken for LTP, because nobody is maintaining it for a while and such 
tests use old API that will
be replaced in any case sooner or later. I agree with other people about 
removing it, unless there's
a valid reason to keep it.
Just in case we want to keep it, someone should take care about UCLINUX 
support, testing LTP releases for it as well, but it doesn't seem like 
something we can do inside the LTP devs team due to the lack of resources.

Regards,
Andrea

On 1/5/24 04:52, Rob Landley wrote:
> On 1/3/24 06:09, Cyril Hrubis wrote:
>> Hi!
>>> I am not sure I agree with this series.
>>> Removing support for UCLINUX from LTP is almost a guarantee for
>>> not noticing when more breakage is introduced.
>>>
>>> How exactly is UCLINUX broken in LTP?
>> As far as we know noone is using it and nobody is maintaing it for a
>> decade,
> Nobody is maintaining "uclinux" because that was a distro, but you can build
> nommu support in buildroot and such, and people do.
>
> Rob

Hi!

My 2 cents. I'm working on refactoring growfiles test which uses UCLINUX 
flag.
During its development I had occasion to check UCLINUX support and 
(indeed) it seems pretty
broken for LTP, because nobody is maintaining it for a while and such 
tests use old API that will
be replaced in any case sooner or later. I agree with other people about 
removing it, unless there's
a valid reason to keep it.
Just in case we want to keep it, someone should take care about UCLINUX 
support, testing LTP releases for it as well, but it doesn't seem like 
something we can do inside the LTP devs team due to the lack of resources.

Regards,
Andrea

On 1/5/24 04:52, Rob Landley wrote:
> On 1/3/24 06:09, Cyril Hrubis wrote:
>> Hi!
>>> I am not sure I agree with this series.
>>> Removing support for UCLINUX from LTP is almost a guarantee for
>>> not noticing when more breakage is introduced.
>>>
>>> How exactly is UCLINUX broken in LTP?
>> As far as we know noone is using it and nobody is maintaing it for a
>> decade,
> Nobody is maintaining "uclinux" because that was a distro, but you can build
> nommu support in buildroot and such, and people do.
>
> Rob

Hi all,

[ Cc also automated-testing and buildroot ML
FYI thread started here:
https://lore.kernel.org/ltp/20240103015240.1065284-1-pvorel@suse.cz/ ]

> On 1/3/24 06:09, Cyril Hrubis wrote:
> > Hi!
> >> I am not sure I agree with this series.
> >> Removing support for UCLINUX from LTP is almost a guarantee for
> >> not noticing when more breakage is introduced.

> >> How exactly is UCLINUX broken in LTP?

> > As far as we know noone is using it and nobody is maintaing it for a
> > decade,

> Nobody is maintaining "uclinux" because that was a distro, but you can build
> nommu support in buildroot and such, and people do.

Right, there are nommu users. Will anybody join LTP development to maintain
nommu support in LTP? The needed work is to add this support to LTP new C API
[1] and use it in the relevant test. There is some implementation in the old
API, I have no idea how well it worked.

If nobody stands for maintaing nommu, we will have to delete it. There is nobody
from the current maintainers who is using LTP on nommu HW (that is the reason why
nommu support have not been implemented in the new API).

Kind regards,
Petr

> Rob

[1] https://github.com/linux-test-project/ltp/wiki/C-Test-API

On 1/5/24 07:11, Petr Vorel wrote:
>> Nobody is maintaining "uclinux" because that was a distro, but you can build
>> nommu support in buildroot and such, and people do.
> 
> Right, there are nommu users. Will anybody join LTP development to maintain
> nommu support in LTP? The needed work is to add this support to LTP new C API
> [1] and use it in the relevant test. There is some implementation in the old
> API, I have no idea how well it worked.
> 
> If nobody stands for maintaing nommu, we will have to delete it. There is nobody
> from the current maintainers who is using LTP on nommu HW (that is the reason why
> nommu support have not been implemented in the new API).

I'm interested, but overwhelmed. Not sure I've got the spoons to come up to
speed on a new project and give it regular attention just now.

I see you cc'd buildroot (although the message might not go through if you
aren't subscribed, dunno how clogged their moderation queue is these days, and
the cc: list is long enough it might twig anyway). They had a nommu fix go in
earlier this week (commit 98684ba7885b).

That said, qemu supports several nommu platforms and buildroot has defconfigs to
build systems for them:

$ git clone git://buildroot.org/buildroot
$ make help
$ make list-defconfigs | grep qemu
$ make qemu_ppc_bamboo_defconfig
$ make
  (time passes...)
>>> host-gettext-tiny 0.3.2 Extracting
gzip -d -c
/home/landley/buildroot/buildroot/dl/gettext-tiny/gettext-tiny-0.3.2.tar.gz |
tar --strip-components=1 -C
/home/landley/buildroot/buildroot/output/build/host-gettext-tiny-0.3.2   -xf -
mkdir -p
/home/landley/buildroot/buildroot/output/build/host-gettext-tiny-0.3.2/gettext-gnu
xzcat /home/landley/buildroot/buildroot/dl/gettext-tiny/gettext-0.22.4.tar.xz |
tar --strip-components=1 -C
/home/landley/buildroot/buildroot/output/build/host-gettext-tiny-0.3.2/gettext-gnu
 -xf -
xzcat: /home/landley/buildroot/buildroot/dl/gettext-tiny/gettext-0.22.4.tar.xz:
No such file or directory
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
make: *** [package/pkg-generic.mk:209:
/home/landley/buildroot/buildroot/output/build/host-gettext-tiny-0.3.2/.stamp_extracted]
Error 2


Sigh, never build git pull du jour of anything, buildroot's having glitch du
jour. But the point is:

$ grep -rl bamboo board/
board/qemu/ppc-bamboo/readme.txt
$ cat board/qemu/ppc-bamboo/readme.txt
Run the emulation with:

qemu-system-ppc -nographic -M bamboo -kernel output/images/vmlinux -net
nic,model=virtio-net-pci -net user # qemu_ppc_bamboo_defconfig

The login prompt will appear in the terminal that started Qemu
-------------------

In THEORY, once it builds an image (presumably using a tagged release version
rather than expecting "continuous integration" to ever mean anything) you should
be able to launch it with qemu. Assuming the instructions aren't also
bit-rotted. (Or using one of the other nommu boards, I haven't gone through the
whole list to see what they've got. I used to use a nommu arm board, but the
linux kernel broke it when converting everything to device tree and not
regression testing it.)

Buildroot also apparently has an LTP package selectable in menuconfig:

https://github.com/buildroot/buildroot/tree/master/package/ltp-testsuite

But I haven't tried it...

Rob

P.S. I automate qemu testing all the time over in toybox, see testroot.sh under
https://github.com/landley/toybox/tree/master/mkroot for an example.

Hi Rob, all,

[ Added Niklas Cassel, who is maintainer of qemu_riscv64_nommu_virt_defconfig in
buildroot ]

> On 1/5/24 07:11, Petr Vorel wrote:
> >> Nobody is maintaining "uclinux" because that was a distro, but you can build
> >> nommu support in buildroot and such, and people do.

> > Right, there are nommu users. Will anybody join LTP development to maintain
> > nommu support in LTP? The needed work is to add this support to LTP new C API
> > [1] and use it in the relevant test. There is some implementation in the old
> > API, I have no idea how well it worked.

> > If nobody stands for maintaing nommu, we will have to delete it. There is nobody
> > from the current maintainers who is using LTP on nommu HW (that is the reason why
> > nommu support have not been implemented in the new API).

> I'm interested, but overwhelmed. Not sure I've got the spoons to come up to
> speed on a new project and give it regular attention just now.

> I see you cc'd buildroot (although the message might not go through if you
> aren't subscribed, dunno how clogged their moderation queue is these days, and
> the cc: list is long enough it might twig anyway). They had a nommu fix go in
> earlier this week (commit 98684ba7885b).

> That said, qemu supports several nommu platforms and buildroot has defconfigs to
> build systems for them:

> $ git clone git://buildroot.org/buildroot
> $ make help
> $ make list-defconfigs | grep qemu
> $ make qemu_ppc_bamboo_defconfig
> $ make
>   (time passes...)
> >>> host-gettext-tiny 0.3.2 Extracting
> gzip -d -c
> /home/landley/buildroot/buildroot/dl/gettext-tiny/gettext-tiny-0.3.2.tar.gz |
> tar --strip-components=1 -C
> /home/landley/buildroot/buildroot/output/build/host-gettext-tiny-0.3.2   -xf -
> mkdir -p
> /home/landley/buildroot/buildroot/output/build/host-gettext-tiny-0.3.2/gettext-gnu
> xzcat /home/landley/buildroot/buildroot/dl/gettext-tiny/gettext-0.22.4.tar.xz |
> tar --strip-components=1 -C
> /home/landley/buildroot/buildroot/output/build/host-gettext-tiny-0.3.2/gettext-gnu
>  -xf -
> xzcat: /home/landley/buildroot/buildroot/dl/gettext-tiny/gettext-0.22.4.tar.xz:
> No such file or directory
> tar: This does not look like a tar archive
> tar: Exiting with failure status due to previous errors
> make: *** [package/pkg-generic.mk:209:
> /home/landley/buildroot/buildroot/output/build/host-gettext-tiny-0.3.2/.stamp_extracted]
> Error 2


> Sigh, never build git pull du jour of anything, buildroot's having glitch du
> jour. But the point is:

> $ grep -rl bamboo board/
> board/qemu/ppc-bamboo/readme.txt
> $ cat board/qemu/ppc-bamboo/readme.txt
> Run the emulation with:

> qemu-system-ppc -nographic -M bamboo -kernel output/images/vmlinux -net
> nic,model=virtio-net-pci -net user # qemu_ppc_bamboo_defconfig

> The login prompt will appear in the terminal that started Qemu
> -------------------

> In THEORY, once it builds an image (presumably using a tagged release version
> rather than expecting "continuous integration" to ever mean anything) you should
> be able to launch it with qemu. Assuming the instructions aren't also
> bit-rotted. (Or using one of the other nommu boards, I haven't gone through the
> whole list to see what they've got. I used to use a nommu arm board, but the
> linux kernel broke it when converting everything to device tree and not
> regression testing it.)

> Buildroot also apparently has an LTP package selectable in menuconfig:

> https://github.com/buildroot/buildroot/tree/master/package/ltp-testsuite

> But I haven't tried it...

I'm the maintainer of the LTP package in buildroot in my private time.
BTW I spent quite a lot of time fixing LTP (and some other system packages,
e.g. nfs-utils) compilation on some old legacy architectures reported via
http://autobuild.buildroot.net/ I've never used in the reality.
But I certainly don't have time to drive nommu support in my private time.
I don't even have an interest, I don't use any nommu device.

And I would not justify to work on nommu in my working paid by SUSE, because
that's not a platform SUSE uses. Lack of resources means that there is a vast
majority of new kernel functionality not being tested. Also with very small
resources it's hard to even fix existing tests broken by changed functionality
in each mainline kernel release.

Therefore nobody who is not involved in nommu will not find a time to support it
in LTP (support does not mean just to add the functionality to the new C API,
but run tests on nommu and fix failing bugs). I suppose nobody is paid to work
on nommu platforms, it would have to be a hobby project, right?

But as I said, if anybody from nommu decides to maintain it in LTP, I'll try to
support him in my free time (review patches, give advices). And if nobody
stands, this patchset which removes the support in the old API will be merged
after next LTP release (in the end of January).

Kind regards,
Petr

> Rob

> P.S. I automate qemu testing all the time over in toybox, see testroot.sh under
> https://github.com/landley/toybox/tree/master/mkroot for an example.

On 1/8/24 03:03, Petr Vorel wrote:
> Hi Rob, all,
> 
> [ Added Niklas Cassel, who is maintainer of qemu_riscv64_nommu_virt_defconfig in
> buildroot ]

Hi Niklas!

>> Buildroot also apparently has an LTP package selectable in menuconfig:
> 
>> https://github.com/buildroot/buildroot/tree/master/package/ltp-testsuite
> 
>> But I haven't tried it...
> 
> I'm the maintainer of the LTP package in buildroot in my private time.
> BTW I spent quite a lot of time fixing LTP (and some other system packages,
> e.g. nfs-utils) compilation on some old legacy architectures reported via
> http://autobuild.buildroot.net/ I've never used in the reality.
> But I certainly don't have time to drive nommu support in my private time.
> I don't even have an interest, I don't use any nommu device.

I do, but I've never done much with LTP, and I have my hands full with toybox
and mkroot already.

> Therefore nobody who is not involved in nommu will not find a time to support it
> in LTP (support does not mean just to add the functionality to the new C API,
> but run tests on nommu and fix failing bugs). I suppose nobody is paid to work
> on nommu platforms, it would have to be a hobby project, right?

A bunch of people are paid to work on nommu platforms, and I've worked with them
a bunch, but none of them talk to linux-kernel. They find the culture toxic,
insular, and categorically dismissive of their interests.

For example, cortex-m is a large nommu platform on which vendors support Linux
BSPs, but notice how page 8 of
https://www.microsemi.com/document-portal/doc_view/132181-linux-cortex-m-users-manual
points at a cross compiler toolchain from _2010_ and page 4 says they're booting
a 2.6.33 kernel?

I'm a bit weird in that I try to get CURRENT stuff to work on nommu, and a lot
of people have been happy to consume my work, but getting any of them to post
directly to linux-kernel is like pulling teeth.

> But as I said, if anybody from nommu decides to maintain it in LTP, I'll try to
> support him in my free time (review patches, give advices). And if nobody
> stands, this patchset which removes the support in the old API will be merged
> after next LTP release (in the end of January).

What does the API migration do? Is there a page on it ala OABI vs EABI in arm or
something?

Rob

Hi Rob, all,

> On 1/8/24 03:03, Petr Vorel wrote:
> > Hi Rob, all,

> > [ Added Niklas Cassel, who is maintainer of qemu_riscv64_nommu_virt_defconfig in
> > buildroot ]

> Hi Niklas!

> >> Buildroot also apparently has an LTP package selectable in menuconfig:

> >> https://github.com/buildroot/buildroot/tree/master/package/ltp-testsuite

> >> But I haven't tried it...

> > I'm the maintainer of the LTP package in buildroot in my private time.
> > BTW I spent quite a lot of time fixing LTP (and some other system packages,
> > e.g. nfs-utils) compilation on some old legacy architectures reported via
> > http://autobuild.buildroot.net/ I've never used in the reality.
> > But I certainly don't have time to drive nommu support in my private time.
> > I don't even have an interest, I don't use any nommu device.

> I do, but I've never done much with LTP, and I have my hands full with toybox
> and mkroot already.

Understand.

> > Therefore nobody who is not involved in nommu will not find a time to support it
> > in LTP (support does not mean just to add the functionality to the new C API,
> > but run tests on nommu and fix failing bugs). I suppose nobody is paid to work
> > on nommu platforms, it would have to be a hobby project, right?

> A bunch of people are paid to work on nommu platforms, and I've worked with them
> a bunch, but none of them talk to linux-kernel. They find the culture toxic,
> insular, and categorically dismissive of their interests.

> For example, cortex-m is a large nommu platform on which vendors support Linux
> BSPs, but notice how page 8 of
> https://www.microsemi.com/document-portal/doc_view/132181-linux-cortex-m-users-manual
> points at a cross compiler toolchain from _2010_ and page 4 says they're booting
> a 2.6.33 kernel?

> I'm a bit weird in that I try to get CURRENT stuff to work on nommu, and a lot
> of people have been happy to consume my work, but getting any of them to post
> directly to linux-kernel is like pulling teeth.

Interesting, thanks for sharing this. BTW I'm not saying anybody is using nommu,
but I wonder if anybody really test it with LTP. And if yes, I wonder why we
don't have reports about tests broken in new API.

> > But as I said, if anybody from nommu decides to maintain it in LTP, I'll try to
> > support him in my free time (review patches, give advices). And if nobody
> > stands, this patchset which removes the support in the old API will be merged
> > after next LTP release (in the end of January).

> What does the API migration do? Is there a page on it ala OABI vs EABI in arm or
> something?

New C API is documented at our wiki: the API for using in the tests [1]
and the library itself [2]. (We also have shell API, but we can ignore it for
nommu.)

All files in lib/ directory which include tst_test.h are part of new C API. Main
file is lib/tst_test.c. LTP tests, which has been rewritten to new API include
tst_test.h, they are in testcases/ directory. Library has it's own tests (for
testing regression in in lib/newlib_tests/*.c.

The reason why Cyril wrote in 2016 new C API was that the old API was buggy
(tests randomly fails). Tests which are still using the old API (there is
ongoing rewrite) include test.h. The old API is not much documented.

Feel free to ask any more question.

Kind regards,
Petr

[1] https://github.com/linux-test-project/ltp/wiki/C-Test-API
[2] https://github.com/linux-test-project/ltp/tree/master/lib

> Rob

On 1/10/24 07:33, Petr Vorel wrote:
>> I'm a bit weird in that I try to get CURRENT stuff to work on nommu, and a lot
>> of people have been happy to consume my work, but getting any of them to post
>> directly to linux-kernel is like pulling teeth.
> 
> Interesting, thanks for sharing this. BTW I'm not saying anybody is using nommu,
> but I wonder if anybody really test it with LTP. And if yes, I wonder why we
> don't have reports about tests broken in new API.

I don't expect a lot of nommu users are aware you ever _could_ run LTP on nommu.

But I'd like to get nommu more regularly supported. You _should_ be able to
build a musl-linux userspace with busybox or toybox and be able to build a
recognizable system (even an alpine-alike) which could then get the basic
plumbing regression tested on qemu even without access to nommu hardware.

>> > But as I said, if anybody from nommu decides to maintain it in LTP, I'll try to
>> > support him in my free time (review patches, give advices). And if nobody
>> > stands, this patchset which removes the support in the old API will be merged
>> > after next LTP release (in the end of January).
> 
>> What does the API migration do? Is there a page on it ala OABI vs EABI in arm or
>> something?
> 
> New C API is documented at our wiki: the API for using in the tests [1]
> and the library itself [2]. (We also have shell API, but we can ignore it for
> nommu.)

I'm writing a bash-compatible shell, which (thanks to Elliott forwarding
questions) has involved surprisingly long threads with the bash maintainer about
weird corner cases neither the man page nor my testing made clear:

http://lists.landley.net/pipermail/toybox-landley.net/2023-July/029631.html

(Alas I try NOT to involve him because when I bring stuff up he keeps FIXING
BASH which from my point of view just makes it a moving target...)

Anyway, running the shell API on nommu doesn't seem out of the question, but
probably not any time soon. (The fact the shell isn't finished yet is one of the
big REASONS I haven't got enough time to take on LTP. That and I haven't started
writing "awk" and "make" yet". And I need to cycle back to
https://landley.net/notes-2023.html#12-10-2023 . And after that debian, ala
https://peertube.debian.social/w/chzkKrMvEczG7qQyjbMKPr and
https://peertube.debian.social/w/45XroN9CnbYLNLKQH3GD9F . And follow up on
https://lists.gnu.org/archive/html/coreutils/2023-08/msg00009.html . And...)

> All files in lib/ directory which include tst_test.h are part of new C API. Main
> file is lib/tst_test.c.

safe_fork(), safe_clone(), fork_testrun()...

> LTP tests, which has been rewritten to new API include
> tst_test.h, they are in testcases/ directory. Library has it's own tests (for
> testing regression in in lib/newlib_tests/*.c.

Library meaning... libc? Or does LTP have a library?

> The reason why Cyril wrote in 2016 new C API was that the old API was buggy
> (tests randomly fails). Tests which are still using the old API (there is
> ongoing rewrite) include test.h. The old API is not much documented.
> 
> Feel free to ask any more question.

My standard questions are "what does success look like" and "how do I reproduce
the problem".

For the first: if there previously was nommu support in LTP, what's the last
version that's known to work? Is there an existing build/test setup that can be
reproduced?

For the second... If I try to run LTP on sh2eb (my current nommu test board)
with the current LTP... do I get a build break? Additional test failures at
runtime? You talk about "removing nommu support", but... what's the current
status? (A subset of tests still use the old api...?)

Yes I need to read https://github.com/linux-test-project/ltp/wiki/C-Test-API but
I also need to know how to build LTP from source. I'm looking at the README's
list of "autoconf, automake, m4, pkgconf / pkg-config" and wincing
significantly. (What does gnu/autoconf DO here? Disable tests? I never
understand why anybody uses that giant hairball of complexity. Half of cross
compiling is figuring out how to lie to autoconf, and my normal workaround for
that is to bootstrap a target system and build natively, but while I've gotten
gcc to run natively on nommu systems, I never _tried_ gnu/autoconf.
Bootstrapping some subset of LFS on a nommu system so it has the dependencies
LFS needs to natively build seems like the long way 'round...

(I am not the right guy for "make it work the easy way". I am the guy who will
step on every land mine between here and there. I code by debugging an empty
screen. If I don't start from "known working" setup... it would take a while.)

Rob

> On 1/10/24 07:33, Petr Vorel wrote:
> >> I'm a bit weird in that I try to get CURRENT stuff to work on nommu, and a lot
> >> of people have been happy to consume my work, but getting any of them to post
> >> directly to linux-kernel is like pulling teeth.

> > Interesting, thanks for sharing this. BTW I'm not saying anybody is using nommu,
> > but I wonder if anybody really test it with LTP. And if yes, I wonder why we
> > don't have reports about tests broken in new API.

> I don't expect a lot of nommu users are aware you ever _could_ run LTP on nommu.

> But I'd like to get nommu more regularly supported. You _should_ be able to
> build a musl-linux userspace with busybox or toybox and be able to build a
> recognizable system (even an alpine-alike) which could then get the basic
> plumbing regression tested on qemu even without access to nommu hardware.

> >> > But as I said, if anybody from nommu decides to maintain it in LTP, I'll try to
> >> > support him in my free time (review patches, give advices). And if nobody
> >> > stands, this patchset which removes the support in the old API will be merged
> >> > after next LTP release (in the end of January).

> >> What does the API migration do? Is there a page on it ala OABI vs EABI in arm or
> >> something?

> > New C API is documented at our wiki: the API for using in the tests [1]
> > and the library itself [2]. (We also have shell API, but we can ignore it for
> > nommu.)

> I'm writing a bash-compatible shell, which (thanks to Elliott forwarding
> questions) has involved surprisingly long threads with the bash maintainer about
> weird corner cases neither the man page nor my testing made clear:

> http://lists.landley.net/pipermail/toybox-landley.net/2023-July/029631.html

> (Alas I try NOT to involve him because when I bring stuff up he keeps FIXING
> BASH which from my point of view just makes it a moving target...)

> Anyway, running the shell API on nommu doesn't seem out of the question, but
> probably not any time soon. (The fact the shell isn't finished yet is one of the
> big REASONS I haven't got enough time to take on LTP. That and I haven't started
> writing "awk" and "make" yet". And I need to cycle back to
> https://landley.net/notes-2023.html#12-10-2023 . And after that debian, ala
> https://peertube.debian.social/w/chzkKrMvEczG7qQyjbMKPr and
> https://peertube.debian.social/w/45XroN9CnbYLNLKQH3GD9F . And follow up on
> https://lists.gnu.org/archive/html/coreutils/2023-08/msg00009.html . And...)

> > All files in lib/ directory which include tst_test.h are part of new C API. Main
> > file is lib/tst_test.c.

> safe_fork(), safe_clone(), fork_testrun()...

> > LTP tests, which has been rewritten to new API include
> > tst_test.h, they are in testcases/ directory. Library has it's own tests (for
> > testing regression in in lib/newlib_tests/*.c.

> Library meaning... libc? Or does LTP have a library?

Yes, LTP has a library (lib/libltp.a). That's what I meant here and in all my
text. So far I did not mention anything libc specific.

> > The reason why Cyril wrote in 2016 new C API was that the old API was buggy
> > (tests randomly fails). Tests which are still using the old API (there is
> > ongoing rewrite) include test.h. The old API is not much documented.

> > Feel free to ask any more question.

> My standard questions are "what does success look like" and "how do I reproduce
> the problem".

> For the first: if there previously was nommu support in LTP, what's the last
> version that's known to work? Is there an existing build/test setup that can be
> reproduced?

I have no idea whether it worked. Best would be to ask Mike Frysinger (the
author of m4/ltp-nommu-linux.m4). The code was added 14 years ago, even before
all of the current maintainers were involved.

> For the second... If I try to run LTP on sh2eb (my current nommu test board)
> with the current LTP... do I get a build break? Additional test failures at
> runtime? You talk about "removing nommu support", but... what's the current
> status? (A subset of tests still use the old api...?)

Yes, subset of the tests which use the old API (git grep UCLINUX).

> Yes I need to read https://github.com/linux-test-project/ltp/wiki/C-Test-API but
> I also need to know how to build LTP from source. I'm looking at the README's
> list of "autoconf, automake, m4, pkgconf / pkg-config" and wincing
> significantly. (What does gnu/autoconf DO here? Disable tests? I never
> understand why anybody uses that giant hairball of complexity. Half of cross
> compiling is figuring out how to lie to autoconf, and my normal workaround for
> that is to bootstrap a target system and build natively, but while I've gotten
> gcc to run natively on nommu systems, I never _tried_ gnu/autoconf.
> Bootstrapping some subset of LFS on a nommu system so it has the dependencies
> LFS needs to natively build seems like the long way 'round...

Well, one day we might migrate to use something else (meson?), but until then
autoconf + m4 + pkgconf is used (instead of automake there is LTP custom
system). This was written in 2009 and nobody plans to change it (well, Andrea
played with meson [1] [2]). But we got far away from the original topic :).

Kind regards,
Petr

[1] https://github.com/acerv/ltp-core
[2] https://github.com/acerv/ltp-testcases


> (I am not the right guy for "make it work the easy way". I am the guy who will
> step on every land mine between here and there. I code by debugging an empty
> screen. If I don't start from "known working" setup... it would take a while.)

> Rob

On 10/1/24 06:24, Rob Landley wrote:
> On 1/8/24 03:03, Petr Vorel wrote:
>> Hi Rob, all,
>>
>> [ Added Niklas Cassel, who is maintainer of qemu_riscv64_nommu_virt_defconfig in
>> buildroot ]
> 
> Hi Niklas!
> 
>>> Buildroot also apparently has an LTP package selectable in menuconfig:
>>
>>> https://github.com/buildroot/buildroot/tree/master/package/ltp-testsuite
>>
>>> But I haven't tried it...
>>
>> I'm the maintainer of the LTP package in buildroot in my private time.
>> BTW I spent quite a lot of time fixing LTP (and some other system packages,
>> e.g. nfs-utils) compilation on some old legacy architectures reported via
>> http://autobuild.buildroot.net/ I've never used in the reality.
>> But I certainly don't have time to drive nommu support in my private time.
>> I don't even have an interest, I don't use any nommu device.
> 
> I do, but I've never done much with LTP, and I have my hands full with toybox
> and mkroot already.
> 
>> Therefore nobody who is not involved in nommu will not find a time to support it
>> in LTP (support does not mean just to add the functionality to the new C API,
>> but run tests on nommu and fix failing bugs). I suppose nobody is paid to work
>> on nommu platforms, it would have to be a hobby project, right?
> 
> A bunch of people are paid to work on nommu platforms, and I've worked with them
> a bunch, but none of them talk to linux-kernel. They find the culture toxic,
> insular, and categorically dismissive of their interests.

I have been involved in the kernel nommu space for 20 years, and sure, there is
some of that. But mostly spending some time and effort to get involved pays off.
I have seen potential contributors show up with some arrogant attitudes too,
so it cuts both ways here.

The m68k community I have been part of has been nothing but welcoming. The mm
people have tried hard to keep nommu support up-to-date where almost none of them
actually have a vested interest in doing so.

What I have seen is that many companies working in this space just don't want
to spend the time and effort to go mainline. That is a business decision they
make, and that is fine. Heck my work in actual mainline has never really been
paid for by any company and I have sunk a _lot_ of time into it. (Full disclosure
I did get paid to work on early porting and support - just not geting it into
mainline and maintain it there).


> For example, cortex-m is a large nommu platform on which vendors support Linux
> BSPs, but notice how page 8 of
> https://www.microsemi.com/document-portal/doc_view/132181-linux-cortex-m-users-manual
> points at a cross compiler toolchain from _2010_ and page 4 says they're booting
> a 2.6.33 kernel?

Any company/person who follows the route of not working with the linux kernel
community to get their work included is going to inevitably get stuck on older
versions of everything.


> I'm a bit weird in that I try to get CURRENT stuff to work on nommu, and a lot
> of people have been happy to consume my work, but getting any of them to post
> directly to linux-kernel is like pulling teeth.

I regularly test nommu configurations (as in every kernel rc and release) on m68k
and at least every release on other architectures like arm(*) and recently on
riscv as well.

(*) somewhat annoyingly needing a minor patch to run the versatile qemu platform
     I like to test with. But hey, that is on me :-)

Regards
Greg



>> But as I said, if anybody from nommu decides to maintain it in LTP, I'll try to
>> support him in my free time (review patches, give advices). And if nobody
>> stands, this patchset which removes the support in the old API will be merged
>> after next LTP release (in the end of January).
> 
> What does the API migration do? Is there a page on it ala OABI vs EABI in arm or
> something?
> 
> Rob

On 1/9/24 17:17, Greg Ungerer wrote:
> 
> On 10/1/24 06:24, Rob Landley wrote:
>> On 1/8/24 03:03, Petr Vorel wrote:
>>> Hi Rob, all,
>>>
>>> [ Added Niklas Cassel, who is maintainer of qemu_riscv64_nommu_virt_defconfig in
>>> buildroot ]
>> 
>> Hi Niklas!
>> 
>>>> Buildroot also apparently has an LTP package selectable in menuconfig:
>>>
>>>> https://github.com/buildroot/buildroot/tree/master/package/ltp-testsuite
>>>
>>>> But I haven't tried it...
>>>
>>> I'm the maintainer of the LTP package in buildroot in my private time.
>>> BTW I spent quite a lot of time fixing LTP (and some other system packages,
>>> e.g. nfs-utils) compilation on some old legacy architectures reported via
>>> http://autobuild.buildroot.net/ I've never used in the reality.
>>> But I certainly don't have time to drive nommu support in my private time.
>>> I don't even have an interest, I don't use any nommu device.
>> 
>> I do, but I've never done much with LTP, and I have my hands full with toybox
>> and mkroot already.
>> 
>>> Therefore nobody who is not involved in nommu will not find a time to support it
>>> in LTP (support does not mean just to add the functionality to the new C API,
>>> but run tests on nommu and fix failing bugs). I suppose nobody is paid to work
>>> on nommu platforms, it would have to be a hobby project, right?
>> 
>> A bunch of people are paid to work on nommu platforms, and I've worked with them
>> a bunch, but none of them talk to linux-kernel. They find the culture toxic,
>> insular, and categorically dismissive of their interests.
> 
> I have been involved in the kernel nommu space for 20 years, and sure, there is
> some of that. But mostly spending some time and effort to get involved pays off.
> I have seen potential contributors show up with some arrogant attitudes too,
> so it cuts both ways here.
> 
> The m68k community I have been part of has been nothing but welcoming. The mm
> people have tried hard to keep nommu support up-to-date where almost none of them
> actually have a vested interest in doing so.
> 
> What I have seen is that many companies working in this space just don't want
> to spend the time and effort to go mainline.

Sometimes they don't bother. Sometimes there's a language barrier. Sometimes
they can't get anything newer than 2.6 working because that's the BSP they were
given so what's the point of trying to engage upstream? Sometimes they think
it's their upstream vendor's responsibility. Sometimes they poke their head up
and get it bit off ala http://landley.net/notes-2008.html#11-12-2008 and then
that serves as a warning to others for generations. Sometimes the company's
legal department thinks it's a terrible idea to attract attention from people
like the SFLC. And sometimes...


The SmartFusion 2 project I was doing on cortex-m was for a project that was to
be launched into space on a NASA rocket, and thus fell under ITAR export
regulations (as the entire US space program has since 1996 due to
https://en.wikipedia.org/wiki/International_Traffic_in_Arms_Regulations#:~:text=Intelsat
) and my manager explained it to me as:

"If I buy a screwdriver from Home Depot, it's just a screwdriver. If I use it to
turn a screw on a spacecraft it is now a munition and cannot be discussed with
non-US persons".

The stupid linked above was:

1) cryptography was categorized as a munition until Bill Clinton relaxed it via
executive order, because 56 bit https was preventing anybody from trusting the
web with their credit card data.

2) Before that, in 1996, china wanted to launch a satellite into space with
crypto stuff so they negotiated with the USA to get some cryptographic hardware
which was delivered/installed under armed guard and escorted to the launch pad.

3) The rocket blew up on launch, scattering debris over a chinese city (becuase
of COURSE china's rocket launches go over large population centers). The crypto
hardware was never recovered.

4) It became a scandal. Congress freaked. And somehow in the scuffle ITAR export
regulations were extended from cryptography to the entire US space program.

5) The US space program dried up and blew away, as engineers had to choose
between "I can work on space stuff" and "I can have any sort of professional
network online". (Because who online is a "non-US person"? That includes canada.
You can't discuss ITAR subjects with canadians. Or foreign nationals living in
the USA. You couldn't ask Alan Cox a question about an ITAR project.)

So that's a whole category that stays very quiet about what they do, and whose
legal analysis of the GPL is "we're making 3 of these and shooting them into
space, if you retrieve one from space and demand source code from us we will
forward you to the relevant federal agencies, and there's a nonzero chance
you'll be on a black site in Diego Garcia within 24 hours where they will figure
out how you did that. Or maybe you'll get the code. Who knows?"

Me, I try to avoid that kind of contract...

> That is a business decision they
> make, and that is fine. Heck my work in actual mainline has never really been
> paid for by any company and I have sunk a _lot_ of time into it. (Full disclosure
> I did get paid to work on early porting and support - just not geting it into
> mainline and maintain it there).

The thing is if you post something _once_ it gets ignored, and if you follow-up
long enough for it to go in (which often takes years), it will then get ripped
out again a few years later because "we never hear from anybody who uses this".

Engaging with the community is signing up for an ongoing commitment.

>> For example, cortex-m is a large nommu platform on which vendors support Linux
>> BSPs, but notice how page 8 of
>> https://www.microsemi.com/document-portal/doc_view/132181-linux-cortex-m-users-manual
>> points at a cross compiler toolchain from _2010_ and page 4 says they're booting
>> a 2.6.33 kernel?
> 
> Any company/person who follows the route of not working with the linux kernel
> community to get their work included is going to inevitably get stuck on older
> versions of everything.

I fight hard to get current versions of everything to work on all my supported
targets. This requires regular regression testing, and I maintain a pile of
patches that I post here periodically but I fully admit will probably never go in:

  https://lkml.iu.edu/hypermail/linux/kernel/2302.2/05594.html

(Sigh, now that 6.7 is out I should post the new round...)

People who want to use my kernels as a source are welcome to do so (and I've
seen my patches quietly show up in other projects), but getting upstream to
actually _fix_ anything? Every one of those patches had a link to the previous
time it was posted to the list and ignored.

I mean literally, the first of those patches teaches the makefile to autodetect
whether $PREFIX-cc is gcc or llvm and just do the right thing, and I was told
that they actively didn't want it to:

https://lkml.iu.edu/hypermail/linux/kernel/2302.2/07184.html

That is modern linux-kernel development.

>> I'm a bit weird in that I try to get CURRENT stuff to work on nommu, and a lot
>> of people have been happy to consume my work, but getting any of them to post
>> directly to linux-kernel is like pulling teeth.
> 
> I regularly test nommu configurations (as in every kernel rc and release) on m68k
> and at least every release on other architectures like arm(*) and recently on
> riscv as well.

Sigh, I should start caring about riscv. I added or1k support, I should do
riscv. (Except I did or1k because I found it in actual hardware, the Orange Pi
3b's power controller is an or1k asic so I needed an or1k toolchain to build
some of u-boot's firmware or else the board couldn't reboot, and there was a
qemu-system-or1k already, which turned into adding it to mkroot via a long
https://lore.kernel.org/openrisc/ZX1xbs_AGdgLgcx7@antec/ thread with its
developers. Alas I still can't get qemu to exit (I.E. virtually reboot or power
off), apparently I need to reinstall my laptop to have a new enough version of
python 3 to build a newer qemu with. It's on the todo list...)

I still have a hard time considering riscv anything other than open source's
version of Itanium. Promises of ubiquity, but even a 28 nanometer mask is still
6 figures before you run any wafers and your mask build process is sucking in
all the black box libraries the fab can sell you, so what does "open" really get
you here? Cortex-m got cheap when the superh patents expired so Arm didn't have
to pay royalties to hitachi (renesas?) for the thumb instruction set anymore,
and they belt those suckers en masse amortizing the up-front costs over ENORMOUS
volume.

And yes, j-core was trying to fix the closed source library and toolchain issues
back when I was still working with them. Among other things fishing
Google/skywater's openlane toolchain build out of their magic docker and
reproducing it under a vanilla debootstrap, ala
https://github.com/j-core/openlane-vhdl-build (As with most corporate
clusterfscks, once you dig far enough it turns out you can throw over 90% of it
out...)

But these days I'm trying to get toybox to 1.0...

> (*) somewhat annoyingly needing a minor patch to run the versatile qemu platform
>      I like to test with. But hey, that is on me :-)

I would very much like to add more nommu targets to mkroot, can I get your
build/config info offline? (I tried fishing configs out of buildroot a couple
years ago, but after the THIRD one where the secret was "use very old versions
of packages, the current stuff is broken"... And the problems were things like
"the conversion to device tree deleted a huge chunk of this infrastructure", not
simple fixes.)

> Regards
> Greg

Rob

On 10/1/24 15:47, Rob Landley wrote:
> On 1/9/24 17:17, Greg Ungerer wrote:
>> On 10/1/24 06:24, Rob Landley wrote:
>>> I'm a bit weird in that I try to get CURRENT stuff to work on nommu, and a lot
>>> of people have been happy to consume my work, but getting any of them to post
>>> directly to linux-kernel is like pulling teeth.
>>
>> I regularly test nommu configurations (as in every kernel rc and release) on m68k
>> and at least every release on other architectures like arm(*) and recently on
>> riscv as well.
> 
> Sigh, I should start caring about riscv. I added or1k support, I should do
> riscv. (Except I did or1k because I found it in actual hardware, the Orange Pi
> 3b's power controller is an or1k asic so I needed an or1k toolchain to build
> some of u-boot's firmware or else the board couldn't reboot, and there was a
> qemu-system-or1k already, which turned into adding it to mkroot via a long
> https://lore.kernel.org/openrisc/ZX1xbs_AGdgLgcx7@antec/ thread with its
> developers. Alas I still can't get qemu to exit (I.E. virtually reboot or power
> off), apparently I need to reinstall my laptop to have a new enough version of
> python 3 to build a newer qemu with. It's on the todo list...)
> 
> I still have a hard time considering riscv anything other than open source's
> version of Itanium. Promises of ubiquity, but even a 28 nanometer mask is still
> 6 figures before you run any wafers and your mask build process is sucking in
> all the black box libraries the fab can sell you, so what does "open" really get
> you here? Cortex-m got cheap when the superh patents expired so Arm didn't have
> to pay royalties to hitachi (renesas?) for the thumb instruction set anymore,
> and they belt those suckers en masse amortizing the up-front costs over ENORMOUS
> volume.
> 
> And yes, j-core was trying to fix the closed source library and toolchain issues
> back when I was still working with them. Among other things fishing
> Google/skywater's openlane toolchain build out of their magic docker and
> reproducing it under a vanilla debootstrap, ala
> https://github.com/j-core/openlane-vhdl-build (As with most corporate
> clusterfscks, once you dig far enough it turns out you can throw over 90% of it
> out...)
> 
> But these days I'm trying to get toybox to 1.0...
> 
>> (*) somewhat annoyingly needing a minor patch to run the versatile qemu platform
>>       I like to test with. But hey, that is on me :-)
> 
> I would very much like to add more nommu targets to mkroot, can I get your
> build/config info offline? (I tried fishing configs out of buildroot a couple
> years ago, but after the THIRD one where the secret was "use very old versions
> of packages, the current stuff is broken"... And the problems were things like
> "the conversion to device tree deleted a huge chunk of this infrastructure", not
> simple fixes.)

Maybe getting a little off-topic here, but I'll just send links here.
Who knows it might be useful to others.

Recently I have been experimenting with minimal builds, this is a bunch of
scripts, configs and a couple of patches I currently have:

     https://github.com/gregungerer/simple-linux

Mostly the kernel builds use the architecture defconfigs, but for armnommu
versatile it was easier to use a dedicated config and patch:

     https://github.com/gregungerer/simple-linux/blob/master/configs/linux-6.6-armnommu-versatile.config
     https://github.com/gregungerer/simple-linux/blob/master/patches/linux-6.6-armnommu-versatile.patch

Anyway the scripting uses the newest package versions of everything
(binutils, gcc, linux, uClibc, busybox).

Regards
Greg

Hi!
> But as I said, if anybody from nommu decides to maintain it in LTP, I'll try to
> support him in my free time (review patches, give advices). And if nobody
> stands, this patchset which removes the support in the old API will be merged
> after next LTP release (in the end of January).

Let me highlight this part, we are eager to help anybody who is willing
to pick the nommu work, but we do not have resources to drive it.

-- 
Cyril Hrubis
chrubis@suse.cz

Hi Geert, Cyril, all,

Geert, first, thank you for Cc all the other lists.
For anybody from those lists, we talk about:
https://lore.kernel.org/ltp/20240103015240.1065284-1-pvorel@suse.cz/

> Hi!
> > I am not sure I agree with this series.
> > Removing support for UCLINUX from LTP is almost a guarantee for
> > not noticing when more breakage is introduced.

> > How exactly is UCLINUX broken in LTP?

> As far as we know noone is using it and nobody is maintaing it for a
> decade, so it's bitrotting and we do not have manpower to fix it, or
> rather we do not want to invest the scarcely limited resources we have
> into something that is niche at best. We asked repeatedly if anyone want
> to invest time into keeping it alive, but nobody answered the call so
> far and I doubt that it will happen at this point.

Also, UCLINUX was used in tests which used the legacy LTP API, which was buggy.
We slowly rewrite tests into new API [1], which is more reliable and do cleanup
and bug fixes during test rewrites. But because nobody stand to maintain UCLINUX
support, it's not in the new API. Thus we have actively deleted it's support
during the rewrite in past years.

I wonder myself if anybody is even using LTP on UCLINUX platforms. Nearly 25% of
the syscalls tests use fork(), thus will not work on UCLINUX. First tests were
rewritten in 2016 (first release in 20160510) and nobody complained.

All tests C based tests (both new and legacy API):
$ git grep -l  -e 'include .tst_test.h' -e 'include .test.h' testcases/ |wc -l
1494

Tests, which use fork(), i.e. not working in UCLINUX:
$ git grep -l  '\.forks_child.*1' testcases/ |wc -l
334

Kind regards,
Petr

[1] https://github.com/linux-test-project/ltp/wiki/C-Test-API

Hi!
> UCLINUX is broken in LTP and nobody really cares. Actually I dare to
> say UCLINUX is dead. Therefore I prepared patchset to remove UCLINUX
> from LTP. We have been actively removing UCLINUX from LTP during rewrite
> tests to new LTP API. This removes the rest from the old tests (which
> will be sooner or later rewritten to new API).
> 
> Because the patchset is quite big, I did not want to send it to mailing
> lists (but I can do it if you want).

I agree that this should be done, but I'm not sure if we want to get
this in before the January release. I guess that such change would be
safer to merge just after the release so that we have a few months to
actually catch possible problems.

-- 
Cyril Hrubis
chrubis@suse.cz

Hi!
> > UCLINUX is broken in LTP and nobody really cares. Actually I dare to
> > say UCLINUX is dead. Therefore I prepared patchset to remove UCLINUX
> > from LTP. We have been actively removing UCLINUX from LTP during rewrite
> > tests to new LTP API. This removes the rest from the old tests (which
> > will be sooner or later rewritten to new API).
> > 
> > Because the patchset is quite big, I did not want to send it to mailing
> > lists (but I can do it if you want).
> 
> I agree that this should be done, but I'm not sure if we want to get
> this in before the January release. I guess that such change would be
> safer to merge just after the release so that we have a few months to
> actually catch possible problems.

Looking at the actuall changes it does not look awfuly complex, so maybe
we can try to merge it before the pre-release testing and hopefully
things will not break badly.

-- 
Cyril Hrubis
chrubis@suse.cz

Hi Cyril,

> Hi!
> > > UCLINUX is broken in LTP and nobody really cares. Actually I dare to
> > > say UCLINUX is dead. Therefore I prepared patchset to remove UCLINUX
> > > from LTP. We have been actively removing UCLINUX from LTP during rewrite
> > > tests to new LTP API. This removes the rest from the old tests (which
> > > will be sooner or later rewritten to new API).

> > > Because the patchset is quite big, I did not want to send it to mailing
> > > lists (but I can do it if you want).

> > I agree that this should be done, but I'm not sure if we want to get
> > this in before the January release. I guess that such change would be
> > safer to merge just after the release so that we have a few months to
> > actually catch possible problems.

> Looking at the actuall changes it does not look awfuly complex, so maybe
> we can try to merge it before the pre-release testing and hopefully
> things will not break badly.

Thanks for a quick look. Both ways would work for me, depends on you and others.
Obviously fewer rebasing is better :).

Kind regards,
Petr