Re: [dev] [sbase] New branch for sbase+ubase
On 2024-03-14 11:49, Roberto E. Vargas Caballero wrote:
> 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.
Ok, that is evidently better. Having in libsys/ all the nonportable bits
is feasible and better than re-implementing each tool for each new
platform.
I think some tools such as sysctl are going to be way more complex than
that
though. Linux kindly provides /proc/sys, and the current sysctl merely
replaces '.' by '/' and writes to the corresponding file. Such an
implementation is impossible on OpenBSD. It does not provide any
systematic
way of mapping a "key" (such as "vm.drop_caches", or "vm.loadavg")
to the underlying bit-array that uniquely identifies it for sysctl(2).
We would need to write thousands of lines of OS-dependant code just to
_parse_ the command-line.
But sysctl _is_ fundamental for a working userland. Should we thus put
it in linux/, or find a way to make it portable nonetheless?
> I don't get why we should have categories like "shell-only", or why
> we should have so high level of customization.
Well, this is just a suggestion. I can see why it would be a bad idea
to have such high level of customization.
But I sill believe that those categories should be defined in the
Makefile
rather than in directories. It is _very_ easy to pick-and-choose which
utilities to build with the master branch. It just requires to modify
the
BIN list, ie. remove tools that don't fit. With a directory-based
separation,
such a process would be more complex, and would require to modify each
Makefile individually; which, arguably, is cumbersome.
This is basically just overlapping lists of utilities, defined by
standards,
type of utility, etc.
> What is the reasoning for categories like "shell-only"?
The categories you've outlined are very clear and make sense; but they
aren't the only way of grouping tools. "shell-only" was just an example,
but some tools only make sense when used in a terminal, for displaying
data to the user. Sometimes, this is not needed (such as routers for
example,
where there is very little need for tools like cal, cols or clear).
Maybe this
it way too specific (and way too arbitrary), but it was just an example.
But if we ever implement tools such as gzip or xz, ping or nc, etc.
it _could_ be useful to have sets such as "compression", "net", that
may overlap with other categories.
This proposed scheme is quite inspired by the way busybox separates
its utilities, but maybe it is wrong for this precise reason. I find
the directory separation both in toybox and busybox quite useful
and elegant, so that's why I'm suggesting a system that would allow
for such separation in a simple way (Makefile lists).
> 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.
As commented before, I think this is problematic for users who want
more control on which tools they want to build. Also, I'm really not
sure how you could get rid of the monolithic approach while still
being able to build sbase-box.
The current script-based method is quite good I think, except that it
builds all the C files in the current directory. The Makefile recipe
would need to provide the script with which files to build, ie. with
lists of C files. The root Makefile has to have knowledge of the
C files in each subdirectory, and pass it to mkbox (along with which
libsys version to use). We would have a non-monolithic build for
individual tools, but a monolithic one for sbase-box, which means
duplicating lists of utilities.
If we get rid of the monolithic approach, then what I propose
(overlapping categories as lists of utilities in a Makefile)
would be inapplicable.
> 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.
Of course! I think some tools could be hard to implement in a portable
way though... sysctl and mount being the worse offenders I can think of.
> 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.
Well, I think you can have that with Makefile variables. So:
POSIX = basename\
cal\
cat\
chgrp\
chmod\
...
xargs\
yes
UNIX = cron\
dmesg\
getty\
...
which\
whoami
MISC = ...
CURSES = ...
LINUX = ...
BIN = $(POSIX) # by default.
# Can be changed to:
# BIN = $(POSIX) $(LINUX) $(UNIX)
# or something along these lines
I believe this also makes the Makefile very simple (at least, not much
more than what it is already), and moreover easily allows a sbase-box
recipe. Without some mechanism like that, I'm not sure how you could
implement it. Maybe by having each Makefile have a PHONY recipe like
"list-utils" and use it in mkbox? I'm really not sure if this is better
than just a single, simple root Makefile.
The issue is different for libutil/, libutf/, and libsys/ as sbase-box
only needs the .a file, and as it cannot be "configured", and a
library-level Makefile would probably be better than a root-level one.
> Of course, the complex part would be in libsys, that has to
> autodetect the system to compile the specific code for the host system.
Couldn't we use a SYSTEM or OS variable instead?
Kind regards,
Elie Le Vaillant
Received on Thu Mar 14 2024 - 17:40:45 CET
This archive was generated by hypermail 2.3.0
: Thu Mar 14 2024 - 17:48:08 CET