Re: devd limitations / automounting removable storage

From: Doug Rabson (dfr_at_nlsystems.com)
Date: 09/18/03

  • Next message: Poul-Henning Kamp: "Re: devd limitations / automounting removable storage" 
    To: Robert Watson <rwatson@freebsd.org>
Date: 18 Sep 2003 11:31:36 +0100

    On Wed, 2003-09-17 at 21:19, Robert Watson wrote:
    > 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).

    I've thought for a long time now that the right way to do this is to
    extend the newbus device tree much further down the hierarchy than it
    currently does. Currently the tree stops at the CAM/ATA controller. Both
    of those systems then use their own custom hand-crafted wheels to probe
    for and attach their attached drives. After finding the drives, we hand
    them over to yet another custom hand-crafted wheel (geom) to find the
    partitions.

    Surely the right thing would be to use the same wheel (newbus) for all
    the probing, driver auction, device attachment jobs in the kernel. That
    would seemlessly allow devd to receive device notification events for
    geom's leaf partitions in exactly the same way that it receives all
    other notification events.

    _______________________________________________
    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: Poul-Henning Kamp: "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
      ... the probing, driver auction, device attachment jobs in the kernel. ... : other notification events. ... before newbus was well integrated into the tree. ... that fdc has an fd newbus child but ata doesn't have an ad child. ...
      (freebsd-arch)
    • Quantcast