[PATCH] - allow specification of alternate inittab files

[B Thomas]

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


On 11/1/06, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20061101/fda81400/attachment.htm