[Toybox] [PATCH] make partprobe use more toybox functions

[Rob Landley]

On 05/31/14 18:08, Isaac Dunham wrote:
> partprobe duplicates a couple of toybox functions; this patch uses the
> standard toybox functionality more thoroughly.
> 
> Additionally, this brings the help into line with standard toybox 
> help messages.
> --
> On Sat, May 31, 2014 at 05:33:50PM -0500, Rob Landley wrote:
>> Where's the patch?
>>
> Argh.
> Here, I hope.

I cleaned it up myself earlier today. Let me know if I missed anything...

>>> As far as the return value, the older versions of partprobe always
>>> return success; the newest versions return failure if reloading the
>>> partition table fails.  I'm _guessing_ the new version returns 
>>> failure if *any* devices cannot be reloaded, but I don't know.
>>>
>>> If that behavior is desired instead, update_device becomes:
>>>
>>> void update_device(int sd_fd, char *path)
>>> {
>>>   if (ioctl(sd_fd, BLKRRPART, NULL)) return;
>>>   perror_msg("ioctl (BLKRRPART) failed, old layout still used");
>>>   toys.exitval = 1;
>>> }
>>
>> perror_msg sets exitval if it's 0.
>>
> Thanks for clarifying that.

I thought it was in the documentation.html stuff, but that's kinda large
at this point.

I need some sort of "intro to programming for toybox", but the best I've
come up with so far is the toys/examples/* stuff.

>> The hard part of this sort of thing is coming up with decent tests for
>> everything. I keep meaning to properly attack the test suite, but it's
>> about as big a timesink as doing writeups for cleanups (and updating the
>> cleanup.html page with full series and stats and such)...
>>
>> Rob
> 
> I don't see any way to have a test suite for this, unfortunately.

My plans are centered around aboriginal linux and qemu. (Once upon a
time I would have used user mode linux, but it's not hugely maintained
these days. Mostly because it was never ported to arm and such.)

> And there are quite a few other programs that will be difficult
> because they're machine-specific, or time-based rather than completely
> deterministic, or don't rely on textual output, or have under-specified
> output...

I'm trying to test the toybox commands. If I can't figure out what the
behavior _should_ be, I can't implement it...

> That covers at least cal, sleep, nice/renice, kill*, pkill et al, uname,
> hostname, id, df, env, and time.
> There are numerous conformant ways to display the output of cal, and at
> least two have already been used (see BSD ncal).

I can hit 'em with grep. Also, I don't care about BSD passing. I'm
mostly interested in regression testing the commands I got working, and
testing corner cases of actually specified behavior in the fiddly bits
of the spec.

But ideally I want the host version (on my development machine,
currently ubuntu) to pass too.

My most thorough test is actually plugging stuff into a development
environment and making it build liux from scratch with this stuff in the
$PATH... but that doesnt provide full coverage (or any for stuff like
'top').

> I've sent a test for cpio, and could try covering (at least) df and link
> shortly.

The posix spec for df has horrible corner cases having to do with read
and write granularity. This is why I've paused in my rewrite: the idea
that they care about this is sort of horrifying. (People say on irc that
bell labs guys have said df's command line options were created to mock
IBM somehow. Dunno if they're joking or not...)

> HTH,
> Isaac Dunham

Rob

 1401598323.0