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

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

On Wed, Jun 20, 2012 at 06:15:48PM +0200, Manuel Bouyer wrote:
> 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, ...).

Yeah, I don't think that we would want it for low-level devices, either.
Mainly just for those device-tree "leaves" that, as you say, exposed to
userland.

> This is a big project ...

It is.  There can be no doubt about that.  And it is blocked up, I
think, because nobody has finished the work on autoconf(9) that makes
it more dynamic and that provides richer locators.  We must acknowledge
that there have been some smart starts on this work, they're stalled,
but maybe they can be unstuck.  I would sure like to see the Foundation
make this a priority for funding.

Dave

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