[Toybox] [PATCH] Another Android roadmap update.

[enh]

On Mon, Aug 17, 2015 at 11:57 AM, Rob Landley <rob at landley.net> wrote:
> 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.

Android's lsof only supported -p (though it didn't use that syntax).
host-based scripts in the Android tree use -t.

> 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. :)

i think first we should just fix uptime.c to build on Android (patch
sent earlier today) and see if anyone actually cares about the
traditional Android output. if not (and i suspect they won't), job
done. if they do, we can worry about it then.

>>> 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?

it's even worse than that already sounds. the spec says that ' ' isn't
allowed. BSD switched to using '_', which i think was how we know that
there are some very fussy implementations out there.

>> [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



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.

 1439844632.0