Date: Wed, 17 Sep 2003 20:18:49 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: John-Mark Gurney <gurney_j@efn.org> Cc: freebsd-arch@freebsd.org Subject: Re: devd limitations / automounting removable storage Message-ID: <20030917201822.M55626-100000@mail.chesapeake.net> In-Reply-To: <20030917210236.GB75714@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Sep 2003, John-Mark Gurney wrote: > Robert Watson wrote this message on Wed, Sep 17, 2003 at 16:19 -0400: > > > Apart from that, it's just a matter of telling me how to send the > > > event... > > > > This is a very similar concern to the question I raised at BSDCon about > > distinguishing network interfaces at the newbus and network service > > levels. My temptation would be to assign a "layer" as well as a device > > name to devices when they are announced. I.e., > > > > Layer Device Meaning > > newbus xl0 A device named xl0 is now available > > devfs net/xl0 A device node named net/xl0 is now available > > ifnet xl0 A network interface named xl0 is now available > > newbus ad0 A device named ad0 is now available > > devfs ad0 A device node named ad0 is now available > > geom ad0 A storage device named ad0 is now available > > > > We might skip the devfs layer since it's probably implicit in the > > completion of ifnet_attach() and disk_create(), but it's worth thinking > > about. This would allow ifconfig commands to be issued once the network > > device is available, rather than once newbus has attached an xl0. Or for > > geom to announce ad0s1e even though newbus doesn't know about it. Or for > > devd to handle the introduction of synthetic interfaces such as vlan, tun, > > etc, which aren't visible to newbus. Or for the device driver names and > > interface names to differ (or for a non-one-one mapping, interface > > renames, etc). > > I was thinking about a more generic event posting mechanism, where > modules can register to receive notifications when events came in. > Please use kqueue. We should have 1 eventing mechanism in the kernel. > We should have each event contain: > system (enum/int) > subsystem? (enum/int) > event (enum/int) > device (char[64?]) > additionaldata (void *, size_t combo) > > This means we can make it more extensible, and have a set of well > defined system/subsystem/event triplets, while at the same time, letting > future interfaces expand. > > The subsystem would be used for something like the network stack, which > has multiple subsystems, like interface, routing, connections. > > The advantage is then we can reduce the number of /dev entries that > convey the same information, but have different calling conventions. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030917201822.M55626-100000>