Sebastien Roy wrote:
> Folks,
> 
> To go along with our high-level proposal on
> indiana-discuss at opensolaris.org, I'd like to get a discussion started
> regarding the technical details of how we're going to get this done.
> Here's a general idea of how I think this might work:
> 
> The algorithm for assigning datalink names could be a service property
> of the datalink-management service.  The dlmgmtd daemon could load this
> property at startup.
> 
> The dlmgmt_create_common() function currently requires a link name, and
> dlmgmt_upcall_create() always calls this function with the devname to
> ensure that the linkname matches the underlying device name.  We could
> change those semantics such that dlmgmtd_create_common() could take a
> NULL link name.  If passed in a NULL link name, it could come up with a
> link name based on the algorithm specified in the service property
> loaded above.
> 
We still need the devname, as the daemon needs to know the devname associated 
to a link, so that it maps to the same link name when the device instance 
detaches and reattaches.

> The naming algorithm property could be set differently by default on
> Nevada and Indiana, to maintain the device name defaults on Nevada, but
> the use the net# defaults on Indiana.  I'm guessing that the installer
> could set this property explicitly.
> 
> One hole in this approach exists when dlmgmtd isn't running and network
> devices attach (does this happen during reconfigure boot?).  What do we
> do for that case?  Perhaps we need to re-think whether links are created
> at all if devices attach and dlmgmtd isn't running...
> 
dlmgmtd is usually running before network attaches, except during the 
netinstall or netboot, that a primary device is usually plumbed by the kernel 
at very early phase before any daemon can be run. Note that a link cannot be 
renamed when it is plumbed. How to rename this primary device to a vanity name 
is another problem that we need to resolve.

Thanks
- Cathy

> What do you think about this?
> 
> -Seb
> 
> 
> 
> _________________________________
> clearview-discuss mailing list
> clearview-discuss at opensolaris.org


Reply via email to