Re: [dev] [sbase] New branch for sbase+ubase

From: Elie Le Vaillant <eolien55_AT_disroot.org>
Date: Wed, 13 Mar 2024 23:51:46 +0100

On 2024-03-13 11:27, Roberto E. Vargas Caballero wrote:
> I am thinking about the new layout, and for now I was considering
> something like:
>
> - posix (tools defined by POSIX)
> - misc (helpful tools not defined by POSIX).
> - linux (tools that only make sense in linux)
> - curses-terminfo (tools with dependency of terminfo, like clean and
> reset).
> - curses-dummy (curses tools implementation without using terminfo).
> - libutil (library with utility functions)
> - libsys (library with system dependant functions).
>

I think this layout has a few problems:

   - we lose the meaningful separation that the sbase/ubase layout
allowed, i.e the distinction
     between what is portable and what isn't. This _could_ be included as
part of the Makefile
     (PORTABLE set vs NONPORTABLE), but I think it is better to
explicitly separate in different
     directories portable from non-portable tools. If we don't, we are
making sbase a Linux-only
     project (the only implementation for ps becomes a Linux-only one,
and we would need to fork
     sbase to make it available to other platforms; same for all the
other tools from ubase), which
     I find a bit sad considering the goals of portability of sbase

   - I think Mattias Andrée scheme is better than this one. With a
directory-base separation
     (between categories of utilities, based on somewhat arbitrary
factors (standards, rather than
     say, minimalness, or use-case, or platform or implementation,
etc.)), we cannot have overlapping
     categories, which is quite problematic. For example, if we wished to
have a category for
     "shell-only usage" (such as clear, or cols), we couldn't implement
it in an easy way, because
     this category overlaps with misc/, curses-dummy/, and maybe others
too.

What I suggest to fix both problems:
   - separate on the grounds of portability/nonportability. In other
words, something along the lines
     of:
        libutil/
        portable/
          ls.c
          cols.c
        unportable/
          linux/
            lsmod.c
            ps.c
            libsys/
          maybe-other-os-in-the-future/
     This more or less reproduces the sbase/ubase separation, but
allowing future OSes to come in
     the future rather than just Linux (so, for example, *maybe* OpenBSD
could have some tools in
     the future. This is a suggestion).

   - Allow for categories _inside the Makefile_. We could have something
like:
        POSIXTOOLS = portable/ls unportable/$(OS)/ps.c ...
        MISCTOOLS = portable/sponge.c portable/cols.c portable/rev.c ...
        INTERACTIVETOOLS = portable/cols.c portable/clear.c ...
        ...
        BIN = $(POSIXTOOLS) $(MISCTOOLS) $(LINUXTOOLS)
     This allows for such grouping, while also allowing overlapping
categories. This also doesn't
     hinder the useful semantic sbase/ubase separation (which is
especially handy when working on
     non-Linux OSes). I think overall that sbase/ubase is the most useful
distinction, so it should
     be treated specially, and not as part of the build-system (but more
as part of the directory
     organization).

Possible drawbacks which I've thought about could be:
   - This requires to occasionally write and update different,
overlapping lists of tools. I believe
     this is not too much of an issue. Adding new items should be quite
easy, and you've already done
     a form a grouping which we could use for this proposed alternative
layout. This task could also
     be aided by the way busybox groups its different utilities, and the
different standards and
     packages listed on the toybox website.

   - The Makefile would be a bit more complex. If we truly add support
for multiple platforms (which
     is a mere suggestion), it could become a bit complex (as in:
platform-specific bits of Makefile
     to properly compile libsys, or platform-specific utilities (lsmod,
sysctl...)). If we don't,
     and just keep a portable/linux separation at the directory-level, we
still need a bit more
     complexity (defining tool categories, properly distinguishing
between libutil and libsys at
     compile-time, and only for platform-specific tools, etc.) than what
we currently have, but this
     complexity would be very similar to the one we would have with your
proposed layout.

Overall, I think that the benefits of the proposed alternative layout
(sbase/ubase primary distinction,
reflected at the directory level; and Makefile-specific lists as
secondary distinction, only reflected
at the build-system level, which allows very great flexibility) outweigh
the inconveniences. Moreover,
I think that your layout has issues, such as the fact that sbase becomes
a de-facto Linux-only project,
considering that tools whose implementation are Linux-specific (ps,
mknod, etc.) are not treated
differently from tools which are inherently portable (sponge, sed...),
or the fact that the categories
you've made so far forbid any kind of overlapping; in particular, it
makes somewhat arbitrary
categories such as posix/misc/curses... mandatory, and disallows us to
have multiple types of
categories defined along different axis (standards, use-case, platform
where it makes sense (like
linux for example)...).

Thank you for your time and your efforts,
Regards,
Elie Le Vaillant
Received on Wed Mar 13 2024 - 23:51:46 CET