[Toybox] [PATCH] Another Android roadmap update.

[Rob Landley]

On 08/16/2015 06:31 PM, Isaac Dunham wrote:
> On Sat, Aug 15, 2015 at 09:41:03AM -0500, Rob Landley wrote:
>> On 08/14/2015 07:51 PM, enh wrote:
>>> iftop
>>> ioctl
>>> lsof
>>> prlimit
>>> -- will rewrite these at some point. turns out there's an existing
>>> prlimit with a much friendlier command-line than ours
>>> (http://man7.org/linux/man-pages/man1/prlimit.1.html).
>>
>> I have part of an lsof here I could take a stab at finishing. The
>> problem is the lsof man page is 2700 lines long and I dunno what a sane
>> subset of this would be. (Suggestions and/or test cases welcome...)
> 
> lsof has 37 options, so it's not even possible to set that many optflags.

If absolutely necessary I can change optflags to 64 bit. I just had it
forced 32 bit instead of "long" so nobody would accidentally use more
and not noticed because they only tested on 64 bit.

For a while I was trying to avoid 64 bit ints on 32 bit platforms
because gcc/libgcc code for doing that is so awful. But I think we're
finally a single digit number of years away from 64 bit becoming the
baseline even for embedded, and 32 bit going the way of 16 bit. (That
single digit is most likely a 9, but still...)

(Ok, x32 and friends may be involved. Defaulting to 32 bit on 64 bit
targets to save space is what sparc and powerpc did for years, using a
32 bit address space within a 64 bit OS to keep stack size and function
argument passing down to a dull roar. But the availability of 64 bit
registers in these contexts means you don't need the horrible libgcc
glue code.)

Predictions are hard, especially about the future.

> (Of those, 10 also have a variant that starts with "+" rather than "-".)

I've dealt with that before (it's why the numberic - type went in), and
the non-numeric version comes up in a few other places like stty. I'll
need to do a design extension of lib/args.c to handle that, not sure
what it should look like yet...

So yeah, a thing, needs to be done, requires new infrastructure. Oh well.

> Busybox implements only the minimum (lsof with no arguments or options).
> I'd find the following useful:
> * the optional [NAMES...] argument, which restricts the open files displayed
> to a list of filenames.
> * the following options:
> -l      turns off username/group lookup for display
> -u FOO  restricts processes examined to a specified user or list of users
> -p PIDS only examine processes in the comma-separated list of PIDs
>         (also accepts a "^" operator to exclude a specific PID)

Good to know.

I've used lsof to find ipv4 ports. (What's the server running on port 80
on this box, what are all open ports on this box...)

>> The ioctl command hasn't got a man page in ubuntu, and when I type it at
>> the command line it doesn't even suggest a package to install.
>> Unfortunately, my macbuntu image hasn't got aosp installed on it, and
>> when I tried to follow the instructions apt-get prompted me to uninstall
>> various 64 bit packages so it could install the 32 bit versions. When I
>> tried to install it in a fresh VM last weekend it ran out of space (30
>> gigs is not enough for Ubuntu+AOSP, apparently) so I need to install
>> another fresh VM image with more space and try again...
> 
> It's an android-specific command, and there's a port to standard Linux
> here:
> www.ccs.neu.edu/home/bchafy/androidioctl/androidioctl.html

I'll take a look, thanks.

>>> log
>>> nandread
>>> newfs_msdos
>>> uptime
>>> -- ???
>>
>> I think uptime's good? (Matches ubuntu, anyway.)
> 
> But not android.

Ah, I have a note about that in the todo list. (Down in the compost heap
part of it...)

Right, the design issue was implementing -a and -l command line options
for the different output formats, and checking CFG_TOYBOX_ON_ANDROID to
determine which one to default to in a given build environment, and
whether that was just too disgusting for words or what. :)

>> mkfs.vfat isn't that big of a todo item, I should just do it. (It's got
>> some strange corner cases but I think I have them all listed now. I'm
>> _tempted_ to do mtools, and a mke2fs/mksquashfs/mkisofs equivalent for
>> vfat, which is where it all turns into a Big Thing and gets shelved
>> again, but I can do that later.)
> 
> Note that newfs_msdos, which Android and the BSDs use, is functionally
> equivalent but uses a completely different syntax:
> mkfs.vfat	newfs_msdos
> -n		-L		LABEL
> -F		-a		FAT size (12/16/32)
> 		-B		Bootloader (file to use)
> 		-O		OEM string
> 		-h		number of hidden sectors
> -f		-n		Number of FATs
> -k		-b		Backup FAT sector (FAT32)
> ...

Yup, but having two aliases with different command lines for the same
basic plumbing is fairly straightforward. :)

> The OEM should be 3+ uppercase, padded to 5 chars with spaces, then 
> [0-9].[0-9]
> This is not required for correctness, but MSDOS and some versions of
> Windows are picky about it (can result in complete data loss upon
> disk insertion).

*blink* *blink*

What?

I...

What?

> [snip]
>> Meanwhile the set of things I'm attacking right now are mostly in the
>> status page's "development" target:
>>
>> http://landley.net/toybox/status.html#development
>>
>> That's so I can replace the rest of busybox in aboriginal linux. (It's
>> what I've got a real world data regression test harness for.)
>>
>> Once I've got that building linux from scratch without busybox, my
>> _next_ target is to try to get it building AOSP. Which is likely to be
>> _so_ much fun. (On the bright side, a panel I attended at Linuxcon Japan
>> may have given me enough info to write a git tool capable of satisfying
>> repo's needs, although it's still a big command to write and the first
>> pass would be download-only. Still, one more chunk of a self-hosting
>> build environment...)
>>
>> Actually before I do _that_ I need to tackle the libc can of worms
>> (migrate aboriginal off of uClibc to musl for the supported targets,
>> which is currently blocked by my Linux From Scratch 6.8 regression test
>> having more than one package with an if/else staircase of libcs it
>> recognizes with an #error at the end), and then extract bionic from the
>> AOSP build (nontrivial) and see if I can build aboriginal with that and
>> how the native build environment behaves under it (probably not pretty)...
> 
> Here, I think that a later version of LFS should help:
> several packages have been fixed to work properly with musl since then.
> LFS 6.8 is basically a snapshot of Linux as it was before musl became
> useful, back when Android support was frequently missing...you get
> the picture.

Yup. I've been meaning to upgrade it to at least 7.4 (which had a
corresponding BLFS 7.4 release, the first in _ages_) for quite a while
now. It's just a largeish redo and adding a second BLFS image consuming
the LFS output puts it into can of worms territory. (I don't _need_ to
do that, but it's a momentum thing...)

The other can-of-worms thing is I'd like to use the LFS build to
bootstrap a native toolchain using the LFS toolchain packages, which now
require a c++ host build enviornment (I've got one but it predates the
C++ 2013 standard and uClibc++ is a bit creaky and modern gcc is
generally crotchety and evil...)

Sigh. I should just do that. (Todo list status: runneth over.)

Did I mention I get on a plane to the west coast tomorrow, to speak at
Linux Plumber's? (A toybox talk in a microconf, and j-core panel for...
either Linuxcon or Plumber's, I can't tell the difference anymore. Thing
the Linux Foundation is doing.)

> HTH,
> Isaac Dunham

Rob

 1439837830.0