Simplifying the LFS Bootscripts

Ian Molton spyro at
Sun Jan 9 10:37:44 PST 2005

Archaic wrote:
> On Sun, Jan 09, 2005 at 05:41:48PM +0000, Ian Molton wrote:
>>I recon the /etc/sysconfig/network-devices/eth1 file should contain:
>>ADDR= broadcast
>>ADDR= broadcast
>>Or something similar.
> With that, you may as well be typing in the commandline, which IMO is
> more educational. How about up() and down() doing something like:
> ip link set $DEV up
> ip addr add $IP/$PREFIX broadcast $BCAST dev $DEV
> etc..

How is that different from alexanders suggestion? all you did was make 
the changeable parts environment variables. I dont see how that helps.

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

configuration files *describe* things (in this case the interface 

configuration scripts [can] read in configuration files and process them 
in order to work out what to do.

the current method (or something similar) has many advantages

1) The files are clearly named and its obvious what they are for.
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.
3) They are all parsed by a common script and as such share a certain 
level of error rejection.

Alexanders proposal potentially throws away all three of those benefits 
(the name of the file no longer [necessarily] reflects the interface, 
the content is a mishmash of commands with differing parameters, and the 
y have NO immunity to common types of error (cutnpaste being a common 
error wether you like it or not, and everyone does it)

> Name the config files numerically so that all you have to do is call all
> the files in that dir in numeric order.

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

 > If ONBOOT=yes, run the up() or
> down () function on it. I say forget naming the files based on their
> device. Why introduce code to parse the filename when a simple
> declaration of the device can be made in the file?

What do you suggest we name the file then? why take away a meaningful 
name? Assuming the file remains named after the device, why specify the 
information twice, once in the name and once in the file itself?

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

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

>>and the up and downing process shouldnt be part of the configuration 
>>file, it should be part of the script that interprets the file.
> Agreed.

In which case, whats left? you cant agree with that and leave a valid 
case open for add/del-ing the addresses in the config file.

>>Also your proposal leaves open a wide margin for sut-n-paste errors in 
>>that people will copy the 'add' lines and use them for the 'del' lines 
>>too, just changing the add to a del (or more likely, forgetting to).
> Not to sound harse, but that is their problem. The whole book implies
> the ability of the user to correctly transfer the text in the book to a
> commandline somehow.

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 

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.

make it -2 actally ;-)

More information about the lfs-dev mailing list