On Thu, Nov 23, 2017 at 4:37 AM, Rob Landley <[email protected]> wrote: > Sorry for the delay, the downside of traveling for work is you wind up > doing rather a lot of work. > > (We've made it through the investor meetings and back to GPS. The > milisecond slips were due to codephase wrap but the fix that fits with > the design is to adjust the length of the nominal second independently > for each satellite rather than to try to adjust the time consumed by > each bit even THOUGH we already have bits that don't take 20 nominal > miliseconds due to clock skew between the antenna sampling clock and the > satellite's transmission rate eventually resulting in a period > adjustment. And no, it's not just doppler shift from the orbit, all > these clocks vary with temperature _even_when_thermally_stabilized_ to > make this stuff a giant pile of exceptions and wraparounds...) > > On 11/16/2017 04:20 PM, enh wrote: >> correspondingly, i've made bionic's _SC_ARG_MAX return a constant >> 128KiB again. > > Which is cool, and what Linus said to do, but having environment space > subtract from that 128k means you can easily get into a situation where > you haven't even got space for one argument. (Although we seem to always > do one and only care we went "tilt" afterwards, so it shouldn't get into > a starvation situation I think.) > > I suspect we should give the environment space its own 128k, and only > trim the argument space if environment eats more than that? But this is > back into "heuristics not matching what kernel is actually doing" land > again. (I really dowanna bother Linus for a second opinion...) > >> we might want to actually just hard-code 128KiB for both >> find and xargs, but making find and xargs the same first seemed like a >> good idea regardless. > > We have Word From On High that 128k for _SC_ARG_MAX is ok. (Although > will portability to the Fuchsia kernel ever matter?) The problem is > _SC_ARG_MAX isn't _SC_ENV_MAX, and if the relationship between argument > space and environment space is mentioned by posix I've missed where. > >> let me know if you want me to send a "make find/xargs use a constant" >> patch too (glibc removed ARG_MAX, so i think we'd want a #ifndef in >> portability.h). > > Meh, glibc is insane. > > I might want to have a lib/*.c function to say "how big can I exec" and > have them both use it, but we need to answer that question properly first...
yeah, this is what led me to suggest this patch: it fixes the one problem we've actually seen in practice, and hopefully we'll have a clearer idea of what a better fix looks like when (if) we get a bug report against this implementation. because none of the choices really seems particularly appealing... > Rob -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
