Simplifying the LFS Bootscripts

Archaic archaic at
Sun Jan 9 11:32:25 PST 2005

On Sun, Jan 09, 2005 at 06:37:44PM +0000, Ian Molton wrote:
> How is that different from alexanders suggestion? all you did was make 
> the changeable parts environment variables. I dont see how that helps.

Which is exactly what you did, except you strung them together.

> We're talking about configuration files here, not boot scripts.

That's what I'm talking about. Apparently that isn't what you read,
though. I'll be more pedantic. The network script has the up/down
functions. It then proceeds to parse the configuration files in numeric
order. For each file it processes, it looks at ONBOOT to see if it
should be brought up or not. If not, skip it. If yes call up() with the
variables contained in the configuration file. On shutdown, reverse the
order in which the files are read (reverse-numeric).

> 1) The files are clearly named and its obvious what they are for.

Fine. Prefix them with numbers like sysvinit symlinks links are prefixed
(though with out the S or K). Then you get a useful name and an ordered
method of bringing up interfaces. Again, there needn't be code to parse
the filename for what could easily be a declared variable in the file

> 2) The content is clearly layed out and as such makes setting up an 
> interface easy without needing to know what all the underlying tools are 
> up to.

It is good to know what ip is up to. That is a very good way of

> 3) They are all parsed by a common script and as such share a certain 
> level of error rejection.

My proposal also parsed the conf files with a single script, but
apparently I wasn't pedantic enough the first time around. :)

> At present there is no need to order interface startup, so all that 
> would do would be to obfuscate the filenames.

You may not have the need, but some people do, and I don't see how
00-eth0 01-eth1 obfuscates things. In fact, it makes it more clear
because you can also see order with an ls of the conf dir.

> why specify the information twice, once in the name and once in the
> file itself?

You were worried about obfuscating the filenames, but I'm more
interested in de-obfuscating the code. We aren't trying to teach super
advanded scripting. It should be as simple as possible for someone who
isn't an advanced scripter to follow, yet powerful enough to do what we
need it to. Also, with the up/down functions the curious person also
learns commandline parameter for ip. It's a win-win. :)

> also, if each file tests its own copy of ONBOOT, why not do away with 
> ONBOOT and just hard code it?

One file tests ONBOOT. It just tests it each time for each interface
since some may not be appropriate to bring up at boot.

> in fact, why not go all the way and hardcode the whole lot into a single 
> script?

yeehaaaa! :) Cat all bootscripts into one and call it init. :)

> Yes but its also a teaching tool, and a tool that makes it hard to 
> pinpoint an error (eg. 'why does my eth2 vanish when I switch runlevel 
> or something) due to cut-n-paste isnt going to teach much other than 
> frustration.

I vehemently disagree here. If someone does that, they will definately
learn from it.

> its much better to have common up/downing code parse some well defined 
> data than to clone the up/downing code along with the data in every 
> config file.

That is what I was saying. :)


"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."

- Benjamin Franklin, Historical Review of Pennsylvania, 1759.

More information about the lfs-dev mailing list