devd limitations / automounting removable storage

[Jeff Roberson]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>