Re: devd limitations / automounting removable storage

From: Robert Watson (rwatson_at_freebsd.org)
Date: 09/17/03

  • Next message: John-Mark Gurney: "Re: devd limitations / automounting removable storage" 
    Date: Wed, 17 Sep 2003 16:19:57 -0400 (EDT)
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

    On Wed, 17 Sep 2003, Poul-Henning Kamp wrote:

    > In message <XFMail.20030917143601.jhb@FreeBSD.org>, John Baldwin writes:
    >
    > >Maybe have GEOM send events when mountable entities show up?
    >
    > There is only one question to figure out: Should it happen at the
    > bottom or the top of GEOM ?
    >
    > At the bottom, your CF card would result in a single event on /dev/ad4,
    > at the top you'd likely get two events, one for /dev/ad4 and one for
    > /dev/ad4s1 (or whatever other gadgets geom autodiscovers).
    >
    > 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).

    Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
    robert@fledge.watson.org Network Associates Laboratories

    _______________________________________________
    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"

  • Next message: John-Mark Gurney: "Re: devd limitations / automounting removable storage"

    Relevant Pages

    • Re: devd limitations / automounting removable storage
      ... > distinguishing network interfaces at the newbus and network service ... rather than once newbus has attached an xl0. ... > devd to handle the introduction of synthetic interfaces such as vlan, tun, ... has multiple subsystems, like interface, routing, connections. ...
      (freebsd-arch)
    • Re: Devd event from GEOM?
      ... >> to a network interface, as kqueue requires a file descriptor. ... > I's suspect that da0 would arrive in GEOM before newbus. ... Part of the attachment is to add it to GEOM. ...
      (freebsd-current)
    • Re: devd limitations / automounting removable storage
      ... We might skip the devfs layer since it's probably implicit in the ... The thing about implicit stuff is that it move knowledge about what is ... rather than once newbus has attached an xl0. ... network interfaces are available for all drivers in the tree after ...
      (freebsd-arch)
    • Re: Devd event from GEOM?
      ... > The net device nodes were added for one purpose: to allow Kqueue to attach ... > to a network interface, as kqueue requires a file descriptor. ... I's suspect that da0 would arrive in GEOM before newbus. ...
      (freebsd-current)