On (08/25/07 17:32), Artem Kachitchkine wrote: > > What's the current plan for this RFE? There isn't an active project that > depends on it, which probably allows it to be on backburner. But as > usual, it might be a bit of a chicken/egg situation. > > Project Brussels is migrating network drivers from driver.conf and ndd > tunables to dladm-based link properties. The properties are applied when > a network link is plumbed, and can also be changed on the fly via > dladm(1M). It is basically what all Solaris driver configuration should > be like, but network drivers need it the most and cannot wait for > next-gen driver.conf to come along. > > Although link properties are currently stored in a file, Clearview is > planning to move them to SMF. Our current prototype uses an SMF service > whose only job is to receive door upcalls from the kernel and push the
Note that it is not just Brussels, but also the Clearview project that uses door upcalls from kernel to user-space. > requested properties into the kernel - it has some boot-related issues, > scales poorly and is, by and large, an architectural wart. It would be could you be specific? I'm not sure I understand the boot-related issues, and the scalability concerns. How would the latter be resolved via 6545020? How are these issues avoided for other kernel->user door upcalls elsewhere in the kernel? > nice if we could use standard SMF interfaces from the kernel, at least > in the foreseeable future. Agreed. --Sowmini
