[Toybox] toybox debian patch for PATH_MAX.

enh enh at google.com
Wed Sep 14 17:42:56 PDT 2022


On Wed, Sep 14, 2022 at 1:47 PM Rob Landley <rob at landley.net> wrote:

> On 9/14/22 06:10, Antoni Villalonga wrote:
> > Path 'set-pathmax-default.patch' was a quick dirty fix trying to build
> Toybox
> > for Debian/Hurd.
> >
> > Hurd build log before the patch:
> >
> https://buildd.debian.org/status/fetch.php?pkg=toybox&arch=hurd-i386&ver=0.8.8%2Bdfsg-1&stamp=1660914245&raw=0
> >   ( scripts/kconfig/lex.zconf.c:2263:22: error: ‘PATH_MAX’ undeclared
> (first use in this function) )
>
> Hopefully I addressed that one.
>
> > Hurd buildlog after the patch:
> >
> https://buildd.debian.org/status/fetch.php?pkg=toybox&arch=hurd-i386&ver=0.8.8%2Bdfsg-2&stamp=1663073011&raw=0
> >   ( ./lib/portability.h:183:10: fatal error: sys/mount.h: No such file
> or directory )
> >   Still needs more work :-/
>
> lib/portability.h and lib/portability.c are the place to stick all the
> horrible
> #ifdefs for target whack-a-mole, so if you want to stick an #ifndef
> __HURD__ or
> similar around that #include it's the right place for it. :)
>
> >   I'll try to look at it but probably there are too much work to be done.
>
> No rush, you saw how long it took me to catch up to your initial pokes
> about
> this. :)
>
> > Some coments PATH_MAX:
> >   https://www.gnu.org/software/hurd/hurd/porting/guidelines.html
> >   https://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html
> >    | {PATH_MAX}
> >    |  Maximum number of bytes in a pathname, including the terminating
> null character.
> >    |  Minimum Acceptable Value: {_POSIX_PATH_MAX}
> >    |  [XSI] Minimum Acceptable Value: {_XOPEN_PATH_MAX}
> >
> > At this point I'll probably drop my PATH_MAX patch from Debian package.
>
> The kconfig build should work without it, and as far as I know nothing in
> toybox
> proper uses it.
>
> I didn't avoid it because I thought headers might not have it, but because
> the
> value in the headers is meaningless. Linux removed its page size
> limitation a
> while ago, and you could always violate it with:
>
>   while true; do mkdir -p a b; mv a b; mv b a; done
>
> And then rm -rf had better be able to _cope_. (And posix makes a note about
> implementing rm -r with chdir instead of path-from-root. I used openat()
> instead, and still need to fix up the rest of dirtree to work right
> here...)
>
> > May be toybox upstream can rely on _POSIX_PATH_MAX/_XOPEN_PATH_MAX
> mentioned on
> > opengroup docs in case PATH_MAX is not defined.
>
> Those are even more meaningless: they don't describe anything about the
> current
> environment you're running in. You can ask for the _POSIX_ and _SC_ ones
> with
> getconf.
>
> > I didn't mentioned it as an 'issue' on github because it's only a
> Hurd-related
> > problem.
> >
> > Thanks for your time!
> >
> > PS: I've seen your other email. I need to look deeper on it before
> replying.
>
> I went through the rest of the patches in your git repo, and I think I've
> applied everything relevant that doesn't require more info?
>
> We went over pathmax-default, and I applied a kconfig fix.
>
> For silent-blhc I suggested trying HOSTCC="$HOSTCC --flags" in the build
> invocation instead (because cross and host compilers can need different
> $CFLAGS,
> which is _why_ I didn't add it to both).
>
> timeout.patch is already a backport.
>
> I don't now why you're removing use of binary files from the test suite?
>
> I applied the spelling changes (I can't reliably spell separate, I know).
>
> I applied the path changes too, although there's been a couple variants of
> that
> from other people over the years: Khem Raj had one for OpenEmbedded...
> commit
> b8070a742549 in 2019, and commit 1dd3704c5ffe was about matching this up
> with
> busybox in 2015. If you start playing tug-of-war please work it out among
> yourselves. Android doesn't care (it does an install_flat into something
> like
> /system/bin), and I've been symlinking /bin to /usr/bin and /sbin to
> /usr/sbin
> since forever (something other people have apparently copied from me since
> an
> old busybox rant about it went semi-viral circa
>
> https://www.linux.com/news/ever-changing-linux-filesystems-merging-directoris-usr/
> ).
> tl;dr: when I tried to research WHY some things are in /bin and some in
> /usr/bin
> ages ago I actually managed to prove a negative (there IS no good answer,
> and I
> know WHY, although my writeup got the disk sizes wrong: the fast system
> disk was
> 0.5 megs, each RK05 is 2.5 megs. It's more or less "boot from a
> comparatively
> tiny ssd and plug in two giant external USB disks", except 50 years ago.),
> and
> having a binary live in /bin vs /sbin is a "primiarly used by root or by
> regular
> users" aesthetic judgement call where it's blurry because "normal users can
> mount stuff that fstab lets them" and "normal users type ifconfig to see
> what
> this machine's IP address is all the time" really doesn't leave you with a
> very
> good answer. (Systems that don't have /sbin in the path for normal users
> rank up
> there with trying to make dash your login shell. The command will TELL me
> if I
> don't have permissions to do what I tried to do, don't make me type in the
> path
> to run it.)
>
> That's all six patches you had checked in. (I also applied the s390 fix
> you sent
> this morning.)
>

s/390 _and_ hurd in the same day? not often that happens :-)


> 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/20220914/9e532dc7/attachment.htm>


More information about the Toybox mailing list