[Toybox] runcon requires CONFIG_TOYBOX_NORECURSE=y

[enh]

On Tue, Jan 19, 2016 at 10:27 PM, Rob Landley <rob at landley.net> wrote:
> On 01/19/2016 04:07 PM, enh wrote:
>>> A number of commands don't even have _attempts_
>>> at TOYBOX_FREE exit cleanup code yet.
>>
>> personally i care a lot less about leaks than i do about reading
>> uninitialized memory (like the recent ls case).
>>
>> (interestingly, although Android's debug malloc's leak detection has a
>> special "give up on mksh, it's hopeless" special case, there isn't one
>> for toybox. no one's brought that up yet.)
>
> Over in my Aboriginal Linux project I've had my nose recently rubbed in
> the need to start work on toysh (hush is crap, ash doesn't support
> nommu, and bash 2.05b from the dawn of time is coming to the end of its
> usefulness), and one of the things the recent utf8 fontmetrics stuff
> applies to is command line history, so that can of worms is likely to
> get opened this year. (I should do test.c first...)

i should probably clarify: mksh is fine as a shell. it just doesn't
care about cleaning up on exit.

> I rely on exit() to free certain kinds of allocations, but things like
> patch and sed can't leak memory from their main loop because they may
> apply to an arbitrarily large file (or arbitrarily large number of
> files, etc).
>
> Programs that run arbitrarily long like servers and shells, also have
> the same constraints. I expect toysh to have the full CFG_TOYBOX_FREE
> stuff and have its allocations be auditable because I myself may
> (eventually) want to audit them.
>
>>> For example I'm implementing top
>>> right now and noticing that iotop (which I'm mergeing with it) doesn't
>>> free its process arrays on exit. If you run run iotop from within a
>>> bootloader, it would have to. Right now, that's a blue sky todo item,
>>> but is it important to somebody...? I got a "please prioritize xz
>>> decompress" email last week, but haven't had anybody ping me about
>>> bootloaders.
>>
>> ps/top are the two remaining big-ticket items as far as i'm concerned.
>> i haven't been saying anything (or sending any patches recently)
>> because it seems too much "under construction" at the moment.
>
> I'm trying to cut a release at the end of the month, and I want all the
> pending ps.c work to be in that release, so I'm doing it now...
>
>> i'm
>> assuming you'll finish after i can make changes in N but before N
>> ships, so i'll fix up anything still broken at that time and then
>> switch us over for O (but still probably before N ships).
>
> There's a lot of shared infrastructure between ps, top, iotop, pgrep,
> pkill, and possibly another command or two. There are too MANY commands
> in here (more than I'm confortable with in one toys/*/*.c file), but I'm
> not sure how to break out a chunk to go in lib/ here. They all share
> struct typography typos[], and the magic ordering in the slot[] array
> (mostly but not entirely derived from /proc/$$/stat)...
>
> I should probably make another TAGGED_ARRAY with SLOT_pid and SLOT_ppid
> and so on to index the slot[] array (possibly invent a
> NAMELESS_TAGGED_ARRAY so the actual struct doesn't need a char *name at
> the start since we only want the macros, not the char * strings).
>
> But shared_match_process() is referencing TT fields, those need to
> become a struct or something I could break out and embed in the various
> commands' GLOBALS() blocks. And that struct would also need to include
> TT.bits used by get_ps(), and then there's string_field() and parse_ko()
> that are shared between these commands...
>
> At some point after I finish top, I need to I need to do a pass making a
> lib/procpid.c, then I can break the hairball up into ps.c, top.c, and
> pgrep.c with no more than a couple commands in each...
>
> And that should be the stopping point to cut a release. :)
>
>>> Then again I didn't even know the cyanogenmod guys had
>>> switched to toybox until I stumbled accross it in an unrelated google
>>> search, and they've got a whole tree of changes for building on macosx.
>>> Why? I dunno. Not sure how to ask them...)
>>
>> they track AOSP, so us switching to toybox switches them.
>
> Yes and no, they were layering busybox on top and have apparently stopped:
>
> http://review.cyanogenmod.org/#/c/119819/1
>
> Except toybox isn't a 100% replacement for busybox yet. (I'm working on
> it!) So losing the bits of busybox toybox doesn't do yet is painful for
> them:
>
> https://plus.google.com/+OpengappsOrg/posts/FJ2v1kNxzHV
>
> I did:
>
>   git clone https://github.com/CyanogenMod/android_external_toybox
>   cd android_external_toybox
>   git fetch https://android.googlesource.com/platform/external/toybox \
>     master:android
>   git log android..cm-13.0 --no-merges
>
> And there's a number of commits (like "fix remount") that seem of
> general interest. Haven't heard a thing about them here, of course, but
> I might take a look and see what portion of this is real. (I note that
> the later installs following a symlink to overwrite the toybox binary is
> why I made toybox install itself read-only.
>
> As for toybox stomping other package's binaries, I'd like it to use
> --remove-destination but I'm not _quite_ sure that's supported on all
> the systems it would be installing on? (It's a nonstandard extension. I
> suppose I could do rm then cp...)

i think they did that to themselves. looking at their Android.mk,
they've removed my hard-coded list of symlinks with a call to toybox
on the host to list all the compiled-in toys. (which is all they
actually need to build on the Mac.) i don't do this (and don't have
any intention of doing it) because it's useful to have things in
toybox without making them directly available. another layer of
"pending", if you like :-)

>> i've no idea
>> what they're doing with Mac OS though. the AOSP makefile doesn't try
>> to build toybox for the host.
>
> They're #ifdeffing out the LSB headers, for one thing. I posted about
> that here a week or so back.
>
>> long-term i'd like to stop checking in
>> the generated files, and that would require me to build at least those
>> tools on the host, but trying to fit what you do into our build system
>> seems sufficiently painful that i'll probably never get around to it
>> unless someone volunteers.
>
> I might volunteer, but I need to take apart the android build system
> first. :)
>
> I probably need to write a section in code.html enumerating what make.sh
> does. (I might need to break code.html up a code/make.html and
> code/lib.html and code/main.html so on. I know I need to add sections on
> lib/interestingtimes.c and lib/linestack.c, and probably move the comma
> stuff out of lib/getmountlist.c into its own file...)
>
> But for right now, I need to finish top. :)
>
> Rob



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