Re: names for net interfaces and for disks (was Re: Specifying names for tap interfaces)

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Wed, Jun 20, 2012 at 10:18:30AM -0500, David Young wrote:
> On Thu, Jun 21, 2012 at 12:24:48AM +1000, Darren Reed wrote:
> > On 19/06/2012 7:56 PM, Roger Pau Monne wrote:
> > > I would like to add this functionality to the kernel, but can someone
> > > provide a little bit more of technical information/steps about how to do 
> > > it?
> > 
> > The first issue that you face that for all intents and purposes, you
> > cannot change "struct ifnet" because it is in too many places and
> > change will likely have a huge waterfall effect. So that can't be
> > changed.
> > 
> > What can be changed is where "struct ifnet" gets its name from.
> > 
> > For network interfaces, what's required here is another data
> > structure that connects a "struct ifnet" with the device itself.
> > This structure needs to remain an internal implementation detail
> > and any interfacing to it via ioctls should be done via proplists.
> > A new CLI tool is required to manage this interface, maybe call
> > it nicctl. For now, all that it would do is display what NICs are
> > present in the system, their device name, instance number and the
> > name to be used in "struct ifnet".
> > 
> > This CLI tool also needs to be able to add and remove device name
> > mappings. So, for example, it needs to let me assign the name
> > "fxp0" to "fxp,3" or some such. This naming information also needs
> > to be stored in a file somewhere so that when the system boots,
> > it can use that information to instruct the kernel. Obviously this
> > needs to be invoked early in rc, i.e. before ifconfig is used to
> > set the interface IP addresses. What format that file takes is up
> > to the person doing the implementation. It could be straight text,
> > maybe it is XML. Whatever.
> 
> I think that basically I agree with Darren.  You need a driver
> entity (some softc-having thing) and a logical network entity (an
> ifnet-having thing) and some correspondence between them that is
> set by properties of the driver such as MAC, serial number, its PCI
> bus/device/function number.  The driver entity has a name written
> in NetBSDese (e.g., wmhw0), the logical entity takes either a
> default name (e.g., wm0) or the name supplied by the operator (e.g.,
> lan19 or wan0 or customer7).
> 
> I believe that NetBSD should use autoconf(9) to create the
> correspondence.  Extend drvctl (or *something*) to let us load/unload
> new device->driver correspondences.  I've written more about this at
> <http://mail-index.netbsd.org/tech-net/2011/05/11/msg002614.html>.
> 
> Provide a convenience utility, nicctl, to set up the correspondences for
> network interfaces specifically.
> 
> I believe that NetBSD should treat disks the same way: split them into
> hardware entity and logical disk, set up correspondences between them
> using properties of the disk (model, capacity, serial number, whatever)
> and/or properties of its partitions (GUID, offset, size, human-readable
> name).  If we look at them a bit askew, wedges are a step in that
> direction.  Let the logical disks take a default name (dk0) or else the
> operator's name if there is one (backup0).
> 
> I think that if you rearrange things in this way, a number of problems
> in the kernel shake out.  For example, power-management for NICs gets
> less hairy.  Interesting opportunities come up if you let a logical
> driver's device_t (and probably its softc, too) hang around even if
> its underlying hardware has disappeared: in that way, the logical
> name for a hardware device will persist for at least as long as the
> system is up, and the kernel has in the logical driver a place to hang
> network configuration or unwritten disk buffers in the event of an
> accidental/emergency device detachment.

I like the idea, but I think we don't want to restrict this to
disk and network device. I can't see why you'd want it for low-level
devices (like e.g. ahcisata or atabus or uhci), but I definitively want it
for anything that is exposted (as a device) to userland (disk, network if,
serial ports, kbd/mouse and other hid, video, printers, ...).

This is a big project ...

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--