Re: devd limitations / automounting removable storage
From: Jeff Roberson (jroberson_at_chesapeake.net)
Date: 09/18/03
- Previous message: John-Mark Gurney: "Re: devd limitations / automounting removable storage"
- In reply to: John-Mark Gurney: "Re: devd limitations / automounting removable storage"
- Next in thread: Bruce M Simpson: "Re: devd limitations / automounting removable storage"
- Reply: Bruce M Simpson: "Re: devd limitations / automounting removable storage"
- Reply: Suleiman Souhlal: "Re: devd limitations / automounting removable storage"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 17 Sep 2003 20:18:49 -0400 (EDT) To: John-Mark Gurney <gurney_j@efn.org>
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"
>
_______________________________________________
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"
- Previous message: John-Mark Gurney: "Re: devd limitations / automounting removable storage"
- In reply to: John-Mark Gurney: "Re: devd limitations / automounting removable storage"
- Next in thread: Bruce M Simpson: "Re: devd limitations / automounting removable storage"
- Reply: Bruce M Simpson: "Re: devd limitations / automounting removable storage"
- Reply: Suleiman Souhlal: "Re: devd limitations / automounting removable storage"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|