Re: (Semi-random) thoughts on device tree structure and devfs

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Sat, Mar 13, 2010 at 6:04 AM, David Young <dyoung%pobox.com@localhost> wrote:
> On Thu, Mar 11, 2010 at 10:16:56AM +0900, Masao Uebayashi wrote:
>> On Thu, Mar 11, 2010 at 12:13 AM, David Young <dyoung%pobox.com@localhost> 
>> wrote:
>> OK, you want to match device by ID.  Like:
>>
>>         fxp* macaddr xx:xx:xx:xx:xx:xx
>>
>> That might make sense.
>>
>> What doesn't make sense there is to *fix* device unit number.  Device
>> unit number will be no longer used after devfs, because we lookup
>> struct device by either topologically or ID.
>
> No device unit number?  You've lost me.  Please fill in the blank,
>
> ifconfig ______ inet 192.168.1.1/24
>
> :-)

In devfs world, traditional device names (/dev/xxxN or ifconfig xxxN)
are provided as a short alias.  Basically devfs internally walks the
whole tree, count the base device name you requested ("fxp", "sd",
...), then return N-th instance.

>> Device probes, configures, and extracts properties from the real
>> device.  Just before leaving attach(), it *puts* its ID in a
>> well-known place so that device(9) can lookup these IDs later.
>
> Actually, that sounds great to me.  Then we can, as you suggested at
> the top of this thread, create the ether(4) pseudo-device that is
> analogous to audio(4).  Let us attach a particular ether(4) instance to
> an ethernet h/w instance according to the h/w's properties.
>
> Take fxp(4) for an example.  Rename it fxphw(4).  Let it attach an
> ether(4) instance at its ether attribute, using an optional 'basename'
> attach argument of 'fxp', so that the ether(4) instance knows that it
> should take its customary name, fxp0 (or whatever).
>
> I think that an added benefit of breaking things down this way is that
> we can attach >1 ether(4) to a single h/w instance, which makes a sense
> with those NICs that support >1 unicast address.  Maybe we can attach
> vlan(4) to the h/w backend's ether attribute, too.
>
> Another added benefit of breaking things down this way is that we may be
> able to get rid of the problematic "network" class in PMF.
>
> You seemed to have in mind attaching at fxp0 an ether0, and attaching at
> ether0 a net0.  What is net0's role?

Actually, I don't know.  I'm not familar with network.  Basic idea is
if those devices share some ioctl()'s, they should have a superclass.

Masao