[Toybox] FreeBSD Toybox check-in

[Rob Landley]

On 11/10/23 15:02, Ed Maste wrote:
> On Fri, 10 Nov 2023 at 12:09, Rob Landley <rob at landley.net> wrote:
>>
>> Which means that lib/portability.c hasn't got an implementation for BSD:
>> ...
>> Shouldn't be hard to add?
> 
> Yes, it should be quite straightforward. I'll find a few minutes to
> put a patch together.
> 
>> > Similar issue, xattr_lget and xattr_get. And error: use of undeclared
>> > identifier 'ENODATA'
>> ...
>>       if (errno==ENODATA || errno==ENOTSUP) len = 0;
>>
>> It's trying to gracefully fail if we fetched xattr info on a system that hasn't
>> got xattr support. You can probably #define it to ENOTSUP. Linux uses it quite a
>> bit:
> 
> I think I've encountered a compiler error or warning from this sort of
> error, although that might have involved a switch statement (and
> duplicate cases from the #define). Can take a look after dealing with
> xattr.
> 
>> The hard one is ps and friends. Last I checked there was a magic shared library
>> to query proc info, and when I dug under the covers it was several different
>> syscall/fcntl/ioctl variants actually querying the data.
> 
> Yes, top will also be in that group. These ones may be good candidates
> for GSoC or intern projects.

A trick I've been pondering using is declaring __attribute__((__weak__)) on some
functions in toys/*/*.c or lib/*.c that lib/portability.c can have optional
alternate implementations of, assuming the --gc-sections trick can make the weak
one drop out if a non-weak one gets linked in. (It _should_ do?)

That way I don't have to move the default Linux implementation into
portability.c but can just have overrides there. For ps.c I'd have to move the
struct procpid {} definition into lib/lib.h... and maybe the big enum with all
the SLOT_blah definitions. (Which is _already_ ugly but I have yet to think of a
better organization...) And maybe I should break down and make some #defines for
the string offsets too...

But the rest of it should _probably_ "just work"?

The other TODO item I have here (apart from the possibly stale list at the top
of ps.c) is that top's performance is terrible and I'd like to figure out why.
(It east WAY too much CPU when monitoring a slow system. Need to profile where
that gets eaten...)

Well, and of course the "bsd style" options, ala "ps ax" which behaves slightly
differently than "ps -ax". But I've got the plumbing for it (lib/args.c sets
FLAGS_NODASH when you do tar xvzf instead of tar -xvzf so you ps can give them
different behavior), just a question of doing it. Which is mostly a question of
going through the dashless ps options and seeing what they DO. (I learned ps ax
on sunos and kept using it via muscle memory. It looks like current versions of
ps treat -ax like ax, which they didn't used to...)

Rob