On Sat, Mar 13, 2010 at 6:04 AM, David Young <dyo...@pobox.com> 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 <dyo...@pobox.com> 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