[Toybox] [PATCH] Fix Mac build.

[Rob Landley]

On 3/12/20 11:12 AM, enh wrote:
> On Wed, Mar 11, 2020 at 8:00 PM Rob Landley <rob at landley.net> wrote:
>>
>> On 3/11/20 9:15 PM, enh wrote:
>>> okay, so that was an investigation well worth doing...
>>>
>>> i tested all the block devices on my mac and linux laptops, and found
>>> (a) i was incorrectly letting the linux <<9 apply to darwin's
>>> already-in-bytes result ... and then realized that the linux result is
>>> already in bytes too (BLKGETSIZE is blocks, but BLKGETSIZE64 is
>>> bytes). patch sent.
>>
>> 64 bits covers a multitude of sins. Sorry I hadn't tested that yet. :(
> 
> oh, it gets worse ... when i wrote my test program to compare the
> ioctl and lseek, i copy & pasted this code out and corrected the bug
> where we were passing the ioctl a pointer to a pointer rather than
> just a pointer ... but then i forgot to actually send you that fix.

Sigh, I should have tested it on a 32 bit system. My bad.

> meanwhile, as i slept others had to diagnose that crash. i've
> forwarded you their fix (because i don't know how to get git to keep
> them as the author; their original is
> https://android-review.googlesource.com/c/platform/external/toybox/+/1255538
> if that helps).

I swapped the From: and stared-at-by: lines in the email. ("git am" is a text
format that started life parsing mbox output, I've authored them by hand before.
It's actually quite forgiving, and doesn't create gratuitous merge commits.)

>> I'm trying to get "make root" set up here so I can actually run the test suite
>> in a virtual system under qemu, which would allow me to regression test things
>> like "block device size".
> 
> yeah, given that you need to be root to even get the size of a block
> device (at least on the systems available to me) i don't see how we
> can do better with what we currently have. (though obviously getting a
> 32-bit device into presubmit would help.)

I have a design for regression testing, with root and known "hardware", on a
half-dozen wildly different architectures (big endian, little endian, 32 bit, 64
bit, things that care about unaligned access, nommu...) all from the comfort of
my laptop. It's just been a lot of grinding to get from here there there, and
hobby time is scarce. (I had jury duty yesterday, had google fiver installed
this morning, and still need to file my taxes before flying back to the $DAYJOB
side of the planet before the "something must be done, this is something,
therefore we must do it" crowd decide outlawing all human contact will make them
look less befuddled.)

>> (The really _fun_ part is you can "truncate -s $(((1<<27)+(1<<18))) blah.img"
>> and then feed it into qemu -hdc blah.img and _it_ won't care. The toybox
>> infrastructure will still care because a 32 bit build of truncate can't take
>> numeric arguments larger than 4G (because it's parsed into a long)...)
>>
>> Way back when I was thinking "if I do the minimal smb 2.0 posix mod only server,
>> I can run it on the host on a high loopback port to export a directory to qemu,
>> and then it can loopback mount files out of _that_" which sent me down a "should
>> I implement at least the gzip variant of squashfs after doing zip?" and it all
>> got pushed into post-1.0 todo. :P
> 
> (why smb? wouldn't nfs2 or 9p be orders of magnitude less work?)

As it turns out, no. Not if I'm only implementing the newest variant of the
protocol and sending a capabilities mask that ONLY offers case sensitive posix
semantics and disables all the legacy fallback stuff.

I've been looking at 9p for _years_ and was a huge fan for a long time
(https://landley.livejournal.com/48698.html) but engaging with the mailing list
(from back in the https://marc.info/?l=v9fs-developer&m=130341664403514 days)
eventually put me off it.

I've occasionally tried to make the kernel's NFS support suck less
(http://lists.landley.net/pipermail/toybox-landley.net/2016-March/004790.html)
but the NFS developers were...
https://groups.google.com/forum/#!msg/linux.kernel/fltNN8gG7YU/NX_R1sVFNAAJ

And after looking at the only userspace nfs server I got to work (unfs3), I
decided a NFS server was NOT in scope for toybox. (I still need to add smbmount
and nfsmount support to do the password prompting though. You _can_ do it all on
the command line, but then the password is (briefly) visible in ps.)

>> And even if it's still the case for CD/DVD (which don't really come up much
>> anymore), the only thing _conceivably_ inconvenienced by that is ftpget. (Unless
>> you're going to call vi or hexedit on /dev/cdrom. Or unless your loadpolicy file
>> is a raw CD image.)
> 
> amusingly i do have a machine with a CD/DVD drive, but i don't have a
> CD or DVD to put in it. (although i'll check later whether a console
> game will mount...)

I've got a USB DVD burner and a shelf full of DVDs (which we usually stick in
the praystation when we want to watch something netflix streaming hasn't got,
although I'm still mad for amazon for the boxed set of Due South we bought
having two copies of disk 3 and no copies of disk 4).

I have some really old CDs in boxes but haven't bothered to dig them up.

>> Possibly this should be xgetfdlength(), where if the ioctl fails it exits
>> noisily? (If this is truly now a "this should never happen" situation. It can
>> still happen if you haven't got permission to read the file, and in that case
>> exiting with the error message is probably the right call for vi and hexedit and
>> modinfo and so on...)
> 
> if you haven't got permission to read the file, your open() failed and
> you either exited then, or passed us -1 :-)

And looking at the current users, "exit with error message" seems to be the
desired semantic. (xopen() and friends has a WARN_ONLY flag that I might try to
genericize more at some point, but there's only been a couple cases where it was
a problem so far...)

>> Rob

Still Rob