[EMAIL PROTECTED] wrote:
On (06/20/07 11:21), Erik Nordmark wrote:
[EMAIL PROTECTED] wrote:
Brussels properties will be available when the driver attaches: early on
in the xxx_attach routine, each converted driver will invoke dladmd with a
door_upcall and persistent properties will be loaded up in the kernel
for the driver as part of the door_upcall. So this should work equivalent
to the driver.conf behavior for diskless client.
For diskless boot the driver attached long before init runs, hence there is
no daemon to talk to.
Erik
I think the Clearview project needs to solve a similar/closely related
problem, so let me consult with them and get back. While we want to
minimally do better than ndd in the first Phase of Brussels, the long
term objective is to provide a better way than driver.conf.
Are you able to use driver.conf as a backup or secondary store
of persistant configuration information?
One problem would be if the information being stored elsewhere
was not also "backed up" into driver.conf.
Maybe said daemon could, as part of its early tasks, write out
new driver.conf files if the current ones are "older" than the
information in its database elsewhere.
The main hiccup I can see with that is if the system panics
while the daemon is "doing its thing", driver.conf files could
be left in a strange state and impede booting normally in the
same way that a panic during add_drv/rem_drv can mess around
with /etc and potentially require booting from another device
or partition in order to fix.
While we want to have the official administrative interface to
not be driver.conf, this shouldn't mean that brussels and other
projects are not free to use it "behind the scenes" to achieve
their objectives.
Side note: this shouldn't be read as a reason for keeping the
current architecture involving driver.conf to be the same as
it is today.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
