On Fri, Nov 10, 2023, 15:37 Rob Landley <r...@landley.net> wrote: > On 11/10/23 15:02, Ed Maste wrote: > > On Fri, 10 Nov 2023 at 12:09, Rob Landley <r...@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@lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net