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

From: Roberto E. Vargas Caballero <k0ga_AT_shike2.com>
Date: Thu, 14 Mar 2024 11:49:10 +0100

Hi,

On Wed, Mar 13, 2024 at 11:51:46PM +0100, Elie Le Vaillant wrote:
> 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

The idea is that everything is portable. Let's take the example of
ps. We can extract the non portable bits of ps into the libsys
library (or whatever name we like), so the code in posix/ is portable.
In some cases it would mean to remove some functionalities or worst
performance, but it is not a problem because we can keep in ubase
the optimized versions. For example, sbase has a portable dd and
ubase has a customized linux dd version.

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

I don't get why we should have categories like "shell-only", or why
we should have so high level of customization. Having some categories
makes sense, but going to the level of user custom lists is too
much in my opinion. The separation between posix/ and misc/ is there
because may people raised the concern that they didn't use tools
like sponge, tac or shuf ever, so it is questionable to include
them, but as there are other people that use them we add the option
to include them. The curses tools have the problem that include a
strong dependency with a complex library, and it is desirable to
skip them, because it can be very problematic to build them in some
cases. Having the unix/ category is there for all the tools that
were part of POSIX previously and/or were part of UNIX historically
but for different reasons are not part of POSIX today. Having a
POSIX only set of tools has the advantage of being a tool to check
if your shell script is portable or not.

What is the reasoning for categories like "shell-only"?

> 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

As commented before, all the tools must be portable, except of
course linux specific tools. After talking with quinq he liked the
idea because then tools for Openbsd can be easily added just adding
a new openbsd directory.

> 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

I put only linux because at this moment we only have linux specific tools,
if we add OpenBSD tools then we can have the openbsd directory. Of course
that it would mean that if you add linux and openbsd at the same time
your build will fail, just don't do stupid things.

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

At this stage and with the configuration that we want to have I
think we have to get rid of the monolithic approach and just define
the directories that we want to include in our build:

all: posix misc curses

and every directory with simple Makefiles.

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

As commented, the idea is to have all the tools written with portable
code. Tools in POSIX are implemented in all the systems, so they
have a way to be implemented. At this moment I just began to
classify the tools, that is not easy, and I didn't care about fixing
the portability problems, but after deciding the categories then it
should be the next step.

> 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 main reason I think we should have only one grouping is because
it makes very simple the Makefile. The default configuration should
include only posix/, and if you want to add more things then you can
select the correct categories to be included. If you want linux tools,
then add them. This removes any autoconfiguration. Of course, The
complex part would be in libsys, that has to autodetect the system
to compile the specific code for the host system.

Regards,
Received on Thu Mar 14 2024 - 11:49:10 CET