Hi, Well, here I think we have to agree to disagree.  I like it; I use it; I added some more flexibility to it in a very few lines of code. The wonderful thing about busybox is that you can choose to have this support or not.  For inittab, I chose to.  I understand why you may not wish to.  Likewise, there are a number of things that I wouldn't chose to include in busybox.  So, I don't. Anyhow, I'm not on a mission to convince anyone of anything.  I was simply trying to contribute a change back to a package that I've found useful.  That's all. Best wishes, -b <div>On 11/1/06, Denis Vlasenko <<a href="mailto:vda.linux@googlemail.com">vda.linux@googlemail.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Wednesday 01 November 2006 17:35, B Thomas wrote: > Well, you might think so, and perhaps there is some avenue that I haven't > explored.  I ended up in situations in which a given inittab just wouldn't > do the trick and only a different inittab would. For example, what serial > lines are started and how.  In the end, no amount of scripting seemed to > help. Only a separate inittab. > > My vague memories of the issue (I solved this some time ago and am only now > getting around to submitting the change), is that serial lines were a > prominent pain.  Some systems would start them, others would just error over > and over and over (the serial line didn't exist, for instance). A lot of > experimenting with all of the different knobs (boot command options, > inittab, scripts, etc) ended up with no real answer and only frustration. > Each system and configuration had its own unique combination of > requirements. A simple, to the point, change was to simply allow the > specification of the inittab that you wish to be using. > > A second scenario is, say, for an environment in which you want no serial > input, but want a debug option. A simple approach is a default inittab with > no serial lines, and a debug version with serial lines and shells. > > Overall, inittab is a very simple, sane, usable solution. What is so simple about inittab? Don't forget that you have dedicated C code in init which needs to handle it, with all that nasty little quirks about signal handling, controlling ttys, respawning etc... and I did not even started to mention sysV runlevel insanity, or that idiotic "reboot by signalling init". All this can be handled without inittab *at all*. My init parameter is: init=/init. cat /init: #!/bin/sh # Set up env unset HOSTNAME unset devfs unset MACHTYPE unset SHLVL unset SHELL unset HOSTTYPE unset OSTYPE unset HOME unset TERM export PATH=/bin:/usr/bin # Open console exec >/dev/console 2>&1 </dev/null # Run startup script /etc/rc.d/start 3 # Close all descriptors exec >&- 2>&- <&- # Sleep forever while true; do env - sleep 32000; done There you have it. Make /etc/rc.d/start start gettys, network daemons, serial line daemons, databases etc etc etc. Use whatever "daemon controller" tool which suits you (there are several popular ones on the Net). Kernel's parameters are propagated into /etc/rc.d/start too (in the environment). Why bother init task with this mess? It is critical and harder to debug than "normal" programs, so keep it simple. Of course I do not plan to throw init out of busybox, there are too many users of it, but I am sort of reluctant to _add_ even_ more_ code_ to it. For one, why other init's out there do not have such thing as alternate inittab? > This patch very > simply allows you a choice to provide some flexibility and builds upon the > existing mechanism.  As you point out, there are many other choices. This > was one, low-cost, incredibly simple to implement one that I happened to put > together. -- vda </blockquote></div>