dev.* analogue for interfaces

[Dag-Erling Smørgrav]

John-Mark Gurney <jmg at funkthat.com> writes:
> Dag-Erling Smrgrav <des at des.no> writes:
> > John-Mark Gurney <jmg at funkthat.com> writes:
> > > My concern is that slowly adding them for each interface type could
> > > create some conflicts in both naming and location...
> > each interface type?  this would be done in if_attach() / if_detach(),
> > everything is taken care of centrally for all interfaces.
> I'm talking about any type of psuedo device.  Virtual web cams from
> the network, tty, disks, etc.  Any kernel interface that has a logical
> view to the user that is not backed by hardware....

Every disk has a device_t; ttys have some sort of driver attachment
since they have device nodes; I have no idea what you mean about a
"virtual web cam".

> And now new hardware devices could start using one or the other causing
> confusion in the future..  we should not allow that...  I know this isn't
> python, but python has some good guiding principals and one of them is:
> There should be one-- and preferably only one --obvious way to do it.

This is why Python is unusable for any real work.

> this adds two obvious ways to handle network interface backed by
> hardware sysctl data..

No, it simply allows the driver writer to make a mistake which can be
caught during code review.

> > Not all interfaces are devices.  That is the whole point...
> I'm confused about this, since below you say they are.

No, they're not.  Some are (if_fxp), some aren't (if_loop).  That is the
entire point.  If they were, we wouldn't be having this conversation.

> > Devices that aren't backed by hardware are still devices, they still
> > have a device_t, and they still have dev.* nodes; nexus is not backed by
> Oh, they do?  I don't see a dev.lo0 tree, or are we now talking about
> other devices?

lo0 is not a device.  It is a network interface.

> exactly, and I want a device_t for all devices (including psuedo
> interfaces, etc.) in the system...

That is your cross to bear, not mine...

DES
-- 
Dag-Erling Smørgrav - des at des.no