[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: (Semi-random) thoughts on device tree structure and devfs
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>
>> 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.
Main Index |
Thread Index |