On Sun, Jan 05, 2014 at 11:49:31AM -0600, Rob Landley wrote: > On 01/01/14 03:26, [email protected] wrote: > >I was looking over init, and noticed some things that seemed possibly > >less than optimal, as well as one detail that seemed illogical. > > I haven't done any cleanup on this one yet. It could be doing anything... > > >First, the oddity: > > p = getenv("TERM"); > >#ifdef VT_OPENQRY > > int terminal_no; > > if (ioctl(0, VT_OPENQRY, &terminal_no)) { > > if (!p || !strcmp(p,"linux")) putenv((char*)"TERM=vt102"); > > } else > >#endif > > if (!p) putenv((char*)"TERM=linux"); > > > >As I read it, this code will set TERM to vt102 if > >(1) the VT_OPENQRY ioctl is supported, AND > >(2) TERM is not set or is set to "linux". > > Now I'm curious: typecasting a string constant to char * in your > above quoted snippet is _crazy_, but it's idiosyncratic crazy of a > kind that's easy to track. I.E. it looks like an easter egg: > > $ grep vt102 busybox/init/init.c > putenv((char*)"TERM=vt102"); > > And busybox is doing it too. Presumably copied from the same BSD > source. Neither ever asked "is there a reason to do this?" Sigh.
It's not in any BSD init. (I've checked for "(char*)" and "vt102" in NetBSD, MirOS, BSDI, BSD-lite2, and FreeBSD init.c--neither is there.) OK...vt102 is supposed to be "if it's a serial line", and busybox had it from the beginning. (char*)"string" dates to 06c0a71d23/Jan 27, 2007, and is as preparation for -Wwrite-strings. Which is to say, the result of some gcc/GNU insanity. Judging by the number of times it pops up in pending/, I guess that Ashwini's team is used to turning that warning on. > There's more than one reason I isolate new submissions in pending > until I get a chance to go over it with a magnifying glass... > > By the way, one thing I worry about with submissions is people > assuming every BSD license version is exactly the same as every > other BSD license version, especialy since toybox's version is > unique in not having the "copy this license text into other things" > viral clause. > > And yes, BSD is viral. People tend to assume that BSD and GPL are > compatible in the absence of the advertising clause, but BSD's "copy > this text verbatim into anything that uses even a snippet of it" > could be viewed as an 'additional restriction' in GPL terms, and > trying to hide the conflict by copying the BSD license to the _end_ > of the file with the GPL boilerplate up front just makes the problem > less obvious, it doesn't diminish it. Yes, people do that: > > http://git.busybox.net/busybox/tree/networking/ping.c > Mentioned before. I suspect the rationale is "The GPL requires you to keep the GPL/copyright notice, so BSD requiring the BSD/copyright notice is fine." I have doubts about relicensing, though. > You can't say nobody's been sued for violating a BSD license because > AT&T vs BSDI was the first big Unix lawsuit. I have no idea _what_ > crazy trolls will try. (Then again the BSDi suit sort of established > that if you rewrite something enough, eventually none of the > original code remains. I'd rather not lean too heavily on that, > though.) > > I'll clean it all out when I get around to rewriting init. Possibly > from scratch. I try not to do that because it discourages > contributors, but when it comes to licensing I sleep way better at > night knowing where the code came from. > > >This ioctl returns 1 to MAX_NR_CONSOLES or -1, so > > if (ioctl(0, VT_OPENQRY, ...)) > >will ALWAYS be true since (-1) is still nonzero. > >But I don't see why "is another tty available" should change the > >environment of the one tty. > > Do android phones have vga ttys? Do modern systems care much about > them? Aren't they specified in inittab anyay? > > >I see no point to this oddity, especially given the common use of > >"TERM=linux". > >Deleting this would lose the one #ifdef. > > I'm pretty happy just hardwiring in TERM=linux if it's not already > set. (Although possibly this is the shell's job and not init's? Sad > there's no spec for init...) The shell doesn't set TERM; it reads it. It's the job of "whatever provides a tty", which in this case means init is on the hook. > >Second, I note that init.c uses a number of x* functions and calls > >error_exit() in some cases... > >These could panic the system on failure. > > Indeed. Although if malloc fails for PID 1 your system's pretty > hosed to begin with. (Remember, it means you ran out of _virtual_ > address space, or somebody thought it was a good idea to enable > strict overcommit in which case they get to keep the pieces.) Which is this case: > >-x*alloc/xstrdup/xmsprintf (lines 119-121, 153-155, 169) in the inittab > >parsing is justifable; if malloc fails before init starts anything, > >there's no way we're running anything. > > > >-final_run will panic if fork()/vfork() fails (line 236). > > Yeah, it shouldn't. That can happen because of a forkbomb. The > traditional init behavior is to just wait it out. > > It's possible init should be able to do something more proactive in > that case (killall -1 and relaunch daemons if it persists for more > than 15 seconds maybe), but that's beyond the domain of sysvinit and > into containers... > > >-Do we need to exit on failure to write informational messages? > >I'm thinking of lines 55 (failure to open console) and 439 ("started > >init" message). > > Nope. We inherited a console from somewhere (in the form of pid > 0-2), if we can't open the new one keep using the old one. So those two need changing. Thanks, Isaac Dunham _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
