On Tue, 2009-09-08 at 01:10 -0700, Vivek Subbarao wrote:
[...]
> The ip address assigned through ifconfig is not persistent. Why is the
> behaviour so? Instead of editing files to add persistent addresses why
> not make ifconfig add persistent addresses? Is there a drawback to
> this?
- It's not the kernels job to persistently store this or that data item.
Period.
IP addresses may be configured by hand (if you install a machine the
first time), statically but also come through BOOTP, DHCP (or whatever
protocol or system in the future).
The above is decided by the admin and it's the most simple way to do
it there (and have in the kernel just some sys-calls to configure
that).
- Even if: consider the implications (or at least the first few that
come to my mind):
a)
* Kernel boots
* Kernel wants to load data from the persistent storage.
That implies that the persistent storage (e.g. file in local
filesystem on whatever hardware, file in remote filesystem, raw in
NVRAM or similar, over ethernet/USB/SATA/IDE/SCSI/SAS/...).
See the contents of /etc/rc.d on CentOS-5.3 for all of the script
logic which is used now to bring up your host. A good part of it (if
not all) should be copied into the kernel?
Basically you get a *lot* of code and complexity into the kernel which
is already present (and must be also dealt with) in user-space anyways
(usually by the SysV-Init and around provided by $distribution).
What to do in case of an error/problem (let alone development and
testing)?
- Boot without that data: That may work for IP addresses but not for
many other "persistent kernel data".
And where are we then? Just like today.
b) How do you backup and recover(!) that data seriously (and for lots
of machines)?
Add some special filesystem to export it as file(s)?
If yes: Where is the real difference to today?
c) And you actually want the possibility to try stuff without any
immediate persistent storage (e.g. configuring a firewall on the
other side of the planet over ssh. You schedule a reboot in 5-10
minutes and load the new rule set. If the new rule set works, you
cancel the reboot and copy the new rule set over the really used
one. If it doesn't work - and you just cut the ssh connection -,
you just wait for the reboot to happen and fix it up).
So you need at least one additional flag everywhere for "persistent
or not".
Bernd
PS: In case you didn't realize it: The "registry" in the Windows-NT-and
newer world was a nice try but doesn't solve more problems than it adds.
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to [email protected]
Please read the FAQ at http://kernelnewbies.org/FAQ
