<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 14, 2022 at 6:13 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/13/22 19:16, enh wrote:<br>
> Sigh, this is another reason I use miniconfigs. These symbols would drop out in<br>
> a miniconfig because they're constant within a toolchain. :P<br>
><br>
><br>
> is this also why i need the "is not set" comment lines? i've never understood<br>
> why i can't just miss out the irrelevant stuff...<br>
<br>
Sadly, the "is not set" lines AREN'T comments. They LOOK like<br>
comments, and anything ELSE starting with # is a comment, but the<br>
menuconfig plumbing parses them because there are no "SYMBOL=n" lines<br>
written out into the file, so when something needs to be explicitly<br>
switched _off_, that line does it.<br>
<br>
But that's not the bad part:<br>
<br>
<a href="https://landley.net/notes-2014.html#13-08-2014" rel="noreferrer" target="_blank">https://landley.net/notes-2014.html#13-08-2014</a><br>
<br>
That stupidity SEEMS to have gone away recently, but trying to track<br>
down what happened to it (and what they replaced it with) has hit the<br>
weird github issue where "git bisect" has been sitting there for 20<br>
minutes with one CPU pegged not producing a result yet. (Not the first<br>
time I've triggered this behavior from git. Did I mention I break<br>
everything? It usually resolves within 4 hours and then takes half as<br>
long to do the next "bisect" step, and becomes tolerable a couple<br>
cycles after that...<br>
<br>
> The Config.probed symbols mostly control what _can_ be selected, hiding<br>
> commands/options that aren't available in this build environment.<br>
><br>
> But only mostly: TOYBOX_SHADOW specifically controls whether #include <shadow.h><br>
> happens in portability.h, that's a build break in _either_ direction if you get<br>
> it wrong.<br>
><br>
> That said, gcc 5 introduced __has_include so in theory I could use that if clang<br>
> also supports it these days. (gcc 5.1 was April 2015, 7 year time horizon...)<br>
><br>
> yes, clang's supported __has_include() for as long as we've been using clang.<br>
> (annoyingly, their documentation really sucks -- far worse than gcc -- so i<br>
> couldn't find a reference to what version it was introduced in.)<br>
<br>
I bisect the source repository to answer this sort of question. (I am<br>
fond of hammer/knife/fire style tools you can apply to a wide range of<br>
issues. May not be RIGHT, but it WORKS...)<br>
<br>
> Any compile time probes I can turn into build-time probes, I'm all for it.<br>
><br>
> certainly __has_include(), yes, though see later for why syscalls are hairy...<br>
><br>
> Figuring out how that impacts the dependency resolution is a design issue<br>
> though. What's the right thing to do when this command depends on a feature<br>
> that's not available in this build environment? Before menuconfig hid them, but<br>
> now it wouldn't test it until compile time. I can probably figure out how to<br>
> make commands drop out of the list (define HAS_BLAH() macros inside the<br>
> __has_include stanzas maybe) and get --gc-sections to dead-code-eliminate<br>
> them... but is that the right thing to do? Avoids a build break, at the cost of<br>
> "I built this command and it's not in the resulting toybox binary". Is a build<br>
> break better? A #warning output?<br>
><br>
> (+1 to build break. your practice of "you don't have this constant from the<br>
> future? here you go then..." [and then a possible runtime failure because you<br>
> really are on too old a kernel] is also fine. but see later for my problem...)<br>
<br>
> pointers. In uclibc fork() wasn't there on nommu targets, but musl provides a<br>
> broken fork() that always returns -ENOSYS,<br>
><br>
> this doesn't apply to fork(), but the trouble with ENOSYS on Android is that you<br>
> have to ask yourself "was there a hole punched in the seccomp() filter for this<br>
> syscall?". this is my concern with copy_file_range(), for example. although<br>
> that's in really old kernels at this point, you can't call it on Android without<br>
> getting SIGSYS courtesy of seccomp until <checks notes> next year in Android U.<br>
> which is "fine" in a sense --- AOSP is "U" at this point, so this version of<br>
> toybox is being built with a version of the OS that has a seccomp filter that<br>
> will allow you to probe for copy_file_range(). but it's "bad" in that it means<br>
> that you can't run even a static toybox binary from U on pre-U (at least not for<br>
> a codepath that actually uses copy_file_range()).<br>
><br>
> my initial plan (and the reason i don't think i even mentioned this when the<br>
> recent copy_file_range() changes went in)<br>
<br>
Which was an external contribution that I then fixed up, not something<br>
I volunteered for. :P<br>
<br>
> was to just keep it disabled for the<br>
> next 7 years... but that's trickier if it's `#ifdef __NR_foo`ed like<br>
> copy_file_range() now is, rather than a regular "config" item. obviously we can<br>
> just add ` && !defined(__ANDROID__)` and a comment explaining why, but i'm<br>
> tempted to wait until someone actually notices and complains?<br>
<br>
It needs error handling falling back to the "didn't work, do the<br>
read/write loop". And in THEORY it has that (try_cfr). In practice<br>
it's awkward to test that this _works_...<br></blockquote><div><br></div><div>well, the `&& !defined(__ANDROID__)` should solve that for you --- we'll always be testing the fallback path :-)</div><div><br></div><div>(and by the time we don't need that any more, you can probably remove the fallback for everyone else too!)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> i'm _trying_ to<br>
> persuade people to use a static toybox for hermetic testing on old android<br>
> releases, but i'm not sure i've actually succeeded yet... ugh, no, i don't want<br>
> to leave a known roadblock for those folks (_especially_ because i keep telling<br>
> people to drive down that road!), so i'll send you a patch.<br>
<br>
I agree with your use case and want it to work. I should figure out<br>
how to have test coverage for this under mkroot...<br></blockquote><div><br></div><div>funnily enough (since, to my eternal annoyance, you can't configure-out syscalls from a kernel) that's probably easiest done by going the other route, catching SIGSYS, and installing a seccomp filter around a test.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> (before you complain, no, i wasn't a huge fan of the whole seccomp thing either,<br>
> but if nothing else it's prevented kernels from shipping with "random" syscalls<br>
> occupying the next few syscall numbers. which was a thing that happened: given a<br>
> sufficiently large ecosystem, for anything you can imagine, someone's done it.)<br>
<br>
The first implementation of the container stuff in OpenVZ was done<br>
with new syscalls (multiple) instead of synthetic filesystems. Linus<br>
did not choose to merge it...<br>
<br>
> anyway, looking at the full list:<br>
><br>
> * TOYBOX_CONTAINER seems years out of date, at least as a "does this compile?"<br>
> probe? everyone should have setns()/unshare() by now?<br>
><br>
> * TOYBOX_FIFREEZE seems years out of date? everyone should have that constant by<br>
> now, and your usual way of doing that today would be to manually #define it anyway.<br>
><br>
> * TOYBOX_UTMPX can be __has_include(<utmpx.h>)?<br>
><br>
> * TOYBOX_SHADOW can be __has_include(<shadow.h>)?<br>
<br>
I might have to reorder the #includes to implement that, I should look<br>
at it when I'm not about to fall over...<br>
<br>
> * TOYBOX_ANDROID_SCHEDPOLICY isn't used?<br>
<br>
You removed its only user it commit b33d37d6f735 but left the symbol<br>
in the probes.<br></blockquote><div><br></div><div>patch sent, since this one seems unobjectionable given that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> * TOYBOX_PRLIMIT is uclibc only? does uclibc have a __UCLIBC__ or something?<br>
<br>
I've largely removed support for uClibc because it died. Musl replaced<br>
it for all but a couple old nommu architectures. Buildroot beats a<br>
uClibc-deadhorse fork in which I have zero interest. I'm following<br>
glibc, musl, bionic, freebsd, netbsd, whatever macos is using, and<br>
anything else should presumably adhere to posix.<br>
<br>
> * TOYBOX_GETRANDOM can be __has_include(<sys/random.h>)?<br>
><br>
> * TOYBOX_HASTIMERS is actually a workaround for a gcc issue, and should probably<br>
> test the gcc version macros instead?<br>
<br>
You mean the gcc version macros that clang _also_ defines, pretending<br>
to be glibc? (And Intel's icc did that, and open64...) Sigh, if that<br>
becomes the only remaining probed symbol I'll try to work something<br>
out, but I don't trust them...<br></blockquote><div><br></div><div>yeah, that's annoying but you can always `!defined(__clang__) && `.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> i won't send a patch/patches in case you're already doing stuff in there, but<br>
> let me know if you'd like any/all of those...<br>
<br>
I've wandered onto a night schedule again and am about to fall over,<br>
but I just got to a good checkpoint on the shell work and checked it<br>
in, and will try to spend a few days on pending other stuff before<br>
diving back in...<br>
<br>
Rob<br>
<br>
P.S. git managed to find the first revision, I tested it, did the "git<br>
bisect good", and it's off eating CPU again...<br>
<br>
P.P.S. Oh hey, I can't send this because thunderbird "upgraded" itself<br>
and now instead of prompting me for the outgoing smtp server password<br>
after a reboot it pops up an HTML window interacting with gmail in a<br>
way that wants me to type in my email (um, how can it NOT already<br>
know...? I was SURE this was phishing but it repeats?) and then when I<br>
do it goes "there are two accounts for this email, an organization one<br>
and a personal one, which would you like to use?" and selecting EITHER<br>
of them goes back to the the "enter your email address" page in an<br>
endless dysfunctional loop. I can still download mail, but not send.<br>
Looks like I'm going to have to migrate my domain's mailserver to<br>
dreamhost earlier than I expected. I'll probably have to log into the<br>
web interface and cut and paste this message there...<br>
</blockquote></div></div>