Peter Memishian wrote:
> > > In any event, not this project. ;-}
> >
> > I know, but it's an interesting and related discussion nevertheless.
>
> I thought I already commented on this, but now I can't find the response,
> so just for the record: message-level DLPI privilege checks are unworkable
> unless the DR model is redesigned. As it stands, having an open DLPI
> stream to a PPA will hold the associated hardware hostage and prevent DR.
>
>
In another follow up, it occurs to me that the DR problem could be
solved different for GLDv3 NICs. GLDv3 drivers don't process DLPI
messages directly, but rely on GLDv3 to do it for them.
The GLDv3 could emulate an "offline NIC" (or possibly a "suspended" NIC)
for NICs that are detached... the model would not be unlike what some
frameworks do (e.g. scsa2usb) for device hotplug (again, thinking about
USB).
Basically, you wind up treating the device as offline, and either
caching settings in soft state (to be replayed if the device ever comes
back on line) or returning back an error (or in the case of a NIC,
possibly dropping packets on the floor). (I'm thinking that some
things, such as multicast address and binding, could be done simply by
updating soft state, and that DL_UNITDATA_REQ could just drop the frames.)
The device instance would ultimately get freed when the last reference
to it was removed (unless the device "returned" back to the framework.)
There could be coordination with RCM to help decide if certain consumers
need to actually "hold" the device hostage (e.g. IP).
Just some possible ideas to think about for the future.
-- Garrett
