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

[Darren Reed <darrenr%netbsd.org@localhost>]

On 21/06/2012 2:15 AM, 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, ...).

I hadn't thought about using it for disk, but if you do .. hmmm ..

This should probably be listed under the "Virtualisation Projects"
for NetBSD as device renaming would go a long way to enabling various
devices to be renamed upon export into a chroot/jails-like environment.

> This is a big project ...

Yes... and it might be a project where you start in one small area,
such as networking, and try to get that right before trying to fix
everything.

Darren