On Tue, Jan 19, 2016 at 10:27 PM, Rob Landley <[email protected]> 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. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
