On Tue, 29 Feb 2000, Marc SCHAEFER wrote:
...
>Having a kernel driver modifying files is possible, but certainly not very
>good from a software engineering/decoupling point of view.
While certainly possible, it doesn't work here. If the disk ordering is
important to the boot process prior to the rootfs being mounted, then there
is where from which to read the configuration unless it's been stuck in
the kernel image (ala rdev.) Additionally, by the time the driver is aware
of a pending system shutdown, it may no longer have anywhere to store it's
configuration -- rootfs mounted RO, or the partition/mount point for the
file no longer valid (unmounted, RO, stopped, or off-line [nfs])
In the cases where the driver is not part of the booting process, this is best
done from userspace. The driver can be coupled to userspace via kmod. In
such a setup, the user land side of kmod (conf.modules) would run a process
to update the mapping on request instead of loading a kernel module. This
method negates the need for a daemon waiting for someone to rearange the
drives.
--Ricky
PS: Now that I think about it, the driver can directly initiate a userspace
process on it's own -- screw modprobe.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
