[Toybox] FreeBSD Toybox check-in
enh
enh at google.com
Fri Nov 10 16:28:41 PST 2023
On Fri, Nov 10, 2023, 15:37 Rob Landley <rob at landley.net> wrote:
> 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?)
>
you don't even need --gc-sections. that's just how weak symbols work.
maskray (the person i mean any time i say "the linker guy") agrees:
https://maskray.me/blog/2021-04-25-weak-symbol
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
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20231110/63ed8981/attachment.htm>
More information about the Toybox
mailing list