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

[David Young <dyoung%pobox.com@localhost>]

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.

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981