On 01/01/2015 02:44 PM, enh wrote: > On Wed, Dec 31, 2014 at 12:35 PM, Rob Landley <[email protected]> wrote: >> On 12/30/2014 02:14 PM, enh wrote: >>> On Tue, Dec 30, 2014 at 11:22 AM, Rob Landley <[email protected]> wrote: >>>> On 12/30/14 00:24, enh wrote: >>>>> i can save you some time there: there isn't one. bionic's getpwnam and >>>>> friends will do the right thing, though, so toybox's id works fine. >>>>> (the patch i sent you fixes bugs that affect id on the desktop too, >>>>> nothing Android-specific.) >>>> >>>> Ok. I note that lib/login.c was an external contribution, and I was >>>> uncomfortable with it precisely _because_ I think we've got to delegate >>>> this to libc and punt in the case of android. >>> >>> at the moment, pw_passwd is always NULL on Android. if it makes your >>> life easier for it to point to "*" or whatever, let me know, but one >>> problem we have in places like this -- and one reason i haven't even >>> bothered with <shadow.h> or <utmpx.h> -- is that in some ways code >>> that tries to use this stuff is better off if it just doesn't build, >>> because at least then the author/builder knows they need to sit down >>> and think about what they're trying to do and what, if anything, that >>> means on Android. >> >> I am not as up to speed on Android development as I should be. (Todo >> list runneth over, etc.) I sat through about half a tutorial on it at >> CELF a year ago but it was mostly on the java/windowing stuff and how to >> make apk files, and I'm mostly interested in the lower levels of the >> system at the moment. >> >> I don't know how multiple users in android work. I'm under the vague >> impression that each running app gets its own uid/gid through a process >> I don't understand, and it runs in something a bit like an lxc >> container, only not really. > > uids were used from the beginning to separate apps, so multi-user > support made things complicated. > http://www.cis.syr.edu/~wedu/Research/paper/multi_user_most2014.pdf > seems from skimming be a reasonable introduction. (section II A talks > about this.)
Downloaded and reading, thanks. (I have half-responses composed in various text files for a bunch of the patches I started reviewing and then got blocked/distracted about, and one of 'em was the chown patch where you were doing sed on /etc/passwd and I'm going "but... android hasn't got one?" Now that I've got the darn flag generation untangled and I'm making progress on getting sed properly debugged, I hope to drain that queue soonish...) >> I'm more up to speed on the guts of lxc than you'd think because I did a >> contract at Parallels a couple years ago, and I ran a table for them at >> SCALE 2011 where I gave a "why containers are awesome" pitch to >> passers-by. The old docs I wrote are at: >> >> http://landley.net/lxc >> >> That said, I don't think android is actually using containers? I when I >> poked at an android device it seemed to be using selinux and chroots or >> something? Except you would probably have to use CLONE_NEWNS and >> pivot_root because chroot is broken in Linux: >> >> http://landley.net/notes-2011.html#02-06-2011 >> >> (I've done a lot of reading on android, but the pieces don't connect up...) > > SELinux and the sdcard FUSE daemon. Can of worms. I should come back to this when I get my patch/pending backlog dealt with... >>>> So yeah, heads up. You probably care about this one. >> >> And the really _fun_ bit is that once I've got OPTSTRPAD_ versions of >> the command names in flags.h with the ctrl-A substitution of disabled >> options, that means completely disabled commands went to a string of ^A >> when they need to be a constant 0 so the option parsing logic can drop >> out (or just not be called) when appropriate. >> >> I tried doing a: >> >> #define FILTOPTS(str, name) (str ? OPTSTRPAD_##name : str) >> >> That main.c could use but for the cases where it is a 0, OPTSTRPAD >> doesn't get generated for that name, so there's no #define for it, so >> the build breaks because even though the symbol isn't used (0 ? BLAH : >> 0) still needs BLAH to exist so it can be eliminated. >> >> So I think I need to reingineer the regex to feed more data _into_ >> mkflags.c so it can produce _empty_ entries, except it's only doing that >> for OLDTOY() macros..? >> >> Grrr. Wrestling with infrastructure. And after all that I figured out a less crappy way to implement it, by replacing the old generated/oldtoys.h that defined OPTSTR_blah macros so OLDTOY() calls could refer to the base thing's flags without repeating them. Now that header's gone, and the OPTSTR macros are instead in flags.h and _those_ are the ones with the edited currently enabled subset with the CTRL-A spacers, so toy_list[] (and thus lib/args.c) is also actually using the OPTSTR macros (instead of directly using the ones passed in to NEWTOY()), and I also removed the flags argument from OLDTOY() entirely because there was only one instance where it actually differed from the NEWTOY() the OLDTOY() was derived from (ftpget supported -c but ftpput didn't, but they shared common help text so this was nonobvious and it's in pending anyway so I need to clean it up already). The the above is how I _didn't_ implement it. I need to update code.html... >> Before I can get back to _that_, I'm fighting the fact libgen.h in >> glibc's includes is #defining basename to __xpg_basename. So >> NEWTOY(basename) breaks if NEWTOY has more than one layer of macro >> expansion. That's just craptacular. I could #undef basename right before >> creating the command_list but that sort of special case bug workaround >> I've tried pretty hard to _avoid_. >> >> Is there just one or two commands using this so I can #include the >> problematic header in just those commands? >> >> $ egrep -l 'basename *[(]' lib/*.c toys/*/*.c >> lib/lib.c >> toys/other/lspci.c >> toys/other/pmap.c >> toys/other/rmmod.c >> toys/pending/last.c >> toys/pending/modprobe.c >> toys/pending/netstat.c >> toys/posix/basename.c >> toys/posix/cp.c >> toys/posix/ln.c >> >> Not so much. >> >> Let's see, they did the #define because they wanted to implement a >> second basename with different semantics from posix (not overwrite its >> source string, return a copy) and they didn't want to give the new >> implementation a different name because gnu. >> >> Wow the basename man page is crappy in Ubuntu 12.04. "Returns a copy of >> the string..." but they didn't mean new allocation??? > > no, the GNU one always returns a pointer into the original string. > Android has both, though the opposite way round: basename is the POSIX > version and there's a __gnu_basename that gets in the way if you > #include <string.h> with _GNU_SOURCE defined. > > the man page would be more helpful if it admitted earlier on that > there are multiple implementations and could include them in the > table. > > another way in which their basename is better is that it has const and > non-const overloads for C++. but, yes, it's insane that they reused > the name. at least with strerror_r their version came first and POSIX > standardized something incompatible. > >> I'm all for creating a second implementation that allocates a copy and >> returns it without modifying its argument. Maybe not the most efficient >> behavior but consistent and usable. Andince it mallocs (and malloc can >> fail), it would be xbasename(), and it can live in lib/xwrap.c, and I >> can include the darn header _there_ so it's not in toys.h polluting the >> global namespace with #defines for common unprefixed symbol names. >> >> (Meanwhile, dirname() only used in dirname.c, and that can include the >> header itself.) >> >> Sorry for the yak trace: >> >> https://twitter.com/jorendorff/status/537290791576936449 >> >> Just trying to explain why I'm not done yet. :) And I didn't do _that_ either, instead I made a wrapper in lib/portability.[hc] that provides posix semantics without the define and only triggers for glibc (which I consider broken). (Ok, it triggers for uClibc as well because they #define __GLIBC__ which is their own darn fault for lying to me, and I didn't filter them out because the workaround works for them too.) Amusingly, the workaround broke toys/pending/nsenter.c because they #define GNU_DAMMIT before #including <toys.h> and thus get the gnu version of basename which is a separate function and the linker complains about the redefinition. But that's basically the workaround catching a bug; I'm ok with that and am fixing it in the copy where I'm merging it into unshare.c. So once again, "looks like I didn't do anything because I went down several blind alleys before finding the properly trivial fix". I just usually don't bother other people with my false starts, although the whole "importance of publishing negative results" thing means I should occasionally describe my average day... http://curt-rice.com/2011/07/21/negative-results-are-important-research-europe/ http://xkcd.com/882/ >> Unfortunately, lsof doesn't have a spec. (There seems to just be one >> magic implemetnation, from purdue.) Does busybox have a second >> implementation? >> >> Ooh, yes, just recently added (April 2012, have they been reading the >> toybox roadmap? :), so I could check what options they implemented and >> use that as a weighting... Let's see, build defconfig busybox from >> current git and: >> >> $ ./busybox --help lsof >> BusyBox v1.24.0.git (2014-12-31 13:31:27 CST) multi-call binary. >> >> Usage: lsof >> >> Show all open files >> >> That's... not helpful. Right, throw that on the todo list and move on... > > there's an lsof in toolbox we wrote ourselves in 2010. it doesn't > support any of the myriad options, but it does take a pid argument > (which is incompatible with the purdue lsof where you have to say > "lsof -p pid"). You know, if you guys are ok with submitting that under the toybox license I'll happily take it, toyboxify it, and expand it to do more stuff. (A todo list would be nice, the existing lsof man page has no excuse being 2714 lines long...) Hmmm, looking at it "-p" does make sense because "lsof blah" treats blah as a filename. (I could check that blah is a number and doesn't exist, but that's brittle. A filename that _is_ a number in the current directory would suddenly change its behavior... Meanwhile busybox's new lsof ignores its arguments, so "lsof" and "lsof walrus" do the same thing: show all open files. So that's not much help...) You'll have to tell me what you consider "least surprise" here. :) >>> i actually meant we'd get feedback from OEMs/developers about which >>> toybox commands they would like to see and/or bugs that cause them >>> pain. but i have been holding off committing changes in Android until >>> i get feedback here. i can send out another status mail if that would >>> be helpful. >> >> I have your previous status mail open in a reply window that I mean to >> reply to as soon as I get your patch stack merged. :) >> >> (Although Ashwini Sharma's requests are ahead of yours if there's a >> queue. They've been waiting since October...) >> >> But yay more status. > > i'll send out an update to the original thread then. Yay! Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
