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. 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...) >> 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. 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??? 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. :) >> (When I do these things right nobody notices I've done _anything_. Which >> is how it should be, but it's still hard.) > > while you're there, the one other thing i don't think you can > currently support is the +/- style used by things like lsof. though -- > although my usual personal goal is "you shouldn't be able to tell the > difference" -- the world might be a better place if that kind of > nonsense were allowed to die. I note that "tail" and "find" have similar +/- weirdness. There's a couple options: 1) If it's a numeric value with + there's a "x-" option (instead of "x#") that defaults to negative but can be made positive with "-x +7". 2) You can pass through unknown options with ^ or ? prefixes, and can skip option parsing entirely and do it yourself in the command (pass in a null optstring and it won't run, in either case toys.argv[] always has the original unpermuted arguments). I agree that any time you can tell the difference between the toybox command and the one in ubuntu or similar is a cost to the end user, and any time there's a cost it should _buy_ you something (simple/fast/small/secure/etc). But if we weight that one too heavily we just wind up reimplementing GNU, which is a bad idea on many evels. When there's a standard (like posix) you can say "this extra is not in posix, that's a deviation _from_ posix, that's also a cost" and then weigh that. And complexity itself is a cost that needs to buy you something, "can we get away with not doing that" is its own weighting. 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... >>>> So much easier when there's a standards document to blame. (Of course I >>>> vetoed like 1/3 of the posix command list anyway. Nobody needs sccs in >>>> 2014.) >>> >>> (i initially included uuencode/uudecode until one of the other guys on >>> the team asked what they were. turned out only me and the second >>> oldest guy had even heard of them...) >> >> Fun piece of trivia: the guy who submitted them to toybox is the lead >> architect for the Qualcomm Hexagon processor. (As in the main hardware >> guy who designs the actual chip.) > > huh. do you remember why? Because I worked a 6 month contract at Qualcomm circa 2010 and we kept in touch afterwards? As to whether his employer's interested, I plead the... (spins the wheel of amendments... twelfth. (Huh, so that's why the president and vice president can't be from the same state. Good to know.) > i don't see anything on the list except for > the fact that two people arrived with uuencode at the same time. It's a posix command, and people were looking for low hanging fruit nobody was working on yet. It's useful enough (mime encoding does it so if you manually dismantle an mbox file...) that I didn't shoot it down out of the posix command list. And Busybox had it (although they've got mkfs.minix too, so again that's just a weighting.) > (probably the majority of Android devices right now have the Hexagon > DSP, so if this is something that's actually useful to those guys i > might want to put it back!) My contract at Qualcomm involved getting Linux running _on_ the hexagon, so you didn't also need an arm chip in a theoretical snapdragon successor. (As part of a team of a dozen or so people. I did userspace bringup, getting a native compiler running and X11 and everything, although it was xclients talking to a remote xserver through the network because the comet boards didn't have graphics hardware.) It was an awesome chip design, which I later blogged about at: http://landley.net/notes-2012.html#24-02-2012 (Skip down to "six stage pipeline" if you just want the chip design bit.) Alas, victim of corporate poltitics. Their arm "scorpion" guys in Raleigh felt threatened after my boss hired Thomas Gleixner's Linutronix to fish the various snapdragon drivers out of the arch/arm directory and genericize them so Hexagon Linux could use 'em. I still occasionally poke Richard Kuo and go "get hexagon support into qemu and I'll make it work on Aboriginal Linux", but even 4 years later they can't get the resources assigned. Still, they pushed what we had done upstream and "linux for hexagon" is in vanilla since like 3.2 or so. (Which would even be useful if you had a comet board to run it on, but that was a debugging prototype they only made a few of which never left the company. See the blog entry bits about bootloaders for why I could never run this on my phone. See also the bits at the end about the laywers being in the driver's seat at Qualcomm so what engineering wants to do and what engineering gets to do are far apart even when engineering divisions aren't fighting.) >>>>> it's a pity the debian popularity contest only has per-package data >>>>> (https://qa.debian.org/popcon.php?package=coreutils). if you ask >>>>> people they always tell you they use everything "all the time". even >>>>> if you broke it two releases ago and removed it one release ago. >>>> >>>> Have you read toybox's roadmap.html page? It may not meet your needs but >>>> at least I have _reason_ for listing the commands I did. :) >>> >>> one thing i was curious about was what busybox configurations tend to >>> get used in the wild. your roadmap implies that you looked at that, >>> but i didn't see where. >> >> After the FSF zealots flamed Tim Bird and Sony to a crisp: >> >> https://lwn.net/Articles/478308/ >> >> The various corporations interested in toybox have been VERY quiet about >> it. They email me off-list and read me the Mission Impossible speech >> about the secretary denying all knowledge if we're caught and their >> involvment self destructing in 5 seconds if so. > > i've had positive private feedback from an external entity already, > expressed in the form of disappointment that it wasn't in L :-) they > weren't very helpful either when i asked them which toys they > want/need. maybe they're assuming that as long as the system is > expecting toybox, they can just edit the .config themselves? I'm pedaling as fast as I can. (I've put off this darn flag generation rewrite for a couple months already because it's big and nasty, but it's now blocking at least three patch submissions I tried to review over the weekend...) Sorry it's taking so long. >> Yesterday got eaten by kernel issues (they put PERL back in the 3.18 >> kernel build and I had to rip it out again). I have high hopes for today. :) Speaking of which: http://landley.net/hg/aboriginal/rev/086e1ff5dd19 Yes I replaced 39 lines of perl with 4 lines of shell script _AGAIN_. I should really post it to linux-kernel but I have to make enough noise for _magazines_ to start covering the scuffle to get any traction there: http://www.linuxjournaldigital.com/linuxjournal/june_2013?pg=18#pg18 It's like pulling teeth, last time it took _FIVE_YEARS_ to get the patches upstream (with lots of "lurkers support me in email" nonsense and nobody stepping up to admit it, as usual): http://landey.net/notes-20103.html#28-02-2013 And there are some people who seem to _actively_oppose_ the idea of simplifying build systems: http://landley.net/notes-2013.html#28-03-2013 Sorry. Bit of a sore spot... > 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. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
