Re: devd limitations / automounting removable storage

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

  • Next message: Sam Leffler: "interrupt latency and driver locking" 
    To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: 18 Sep 2003 21:22:08 +0000

    On Thu, 2003-09-18 at 11:43, Poul-Henning Kamp wrote:
    > In message <1063881095.12179.5.camel@builder02.qubesoft.com>, Doug Rabson write
    > s:
    >
    > >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.
    >
    > I'm sorry Doug, I don't belive in "one size fits all" because it
    > invariably means that it fits nobody at all.

    Well in this case, its a size which seems to fit virtually everything
    else in the system pretty well. I remember what it was like before when
    every different kind of driver (pci, eisa, isa, whatever) was written in
    a completely different incompatible undocumented style and I happen to
    think that the new way works pretty well. I really doubt that the
    partition to driver matching system of geom or the device to driver
    matching system in ATA does anything very different from any other part
    of the device tree.

    _______________________________________________
    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: Sam Leffler: "interrupt latency and driver locking"

    Relevant Pages

    • Re: [RFC] [PATCH] Device Tree on ARM platform
      ... when we started the mainline work on MX27 and MX31. ... The handling of platform data is my main concern as someone working ... node on a per driver basis is a common approach. ... cases for handling within the device tree. ...
      (Linux-Kernel)
    • Re: [RFC] [PATCH] Device Tree on ARM platform
      ... The patches that were proposed in u-boot did exactly this -- except supposedly they would only set the MAC address if the interface were actually used prior to booting the kernel. ... They don't seem to be NACKing drivers that get it from the device tree instead. ... It is this distinction that led to the platfom/of_platform split -- we can't turn key/value into C structs without glue code that knows the specific device binding, and it's easier for the driver to access that data directly. ...
      (Linux-Kernel)
    • Re: [RFC] [PATCH] Device Tree on ARM platform
      ... a platform_device carries a pdata structure with it ... add hooks for translating the device tree data into a pdata structure ... compatibility with older ones so that existing device drivers will ... a driver can still get information about the exact ...
      (Linux-Kernel)
    • Re: [patch 0/8] Nesting class_device patches that actually work
      ... >> are reached by symlinks instead of real directories. ... The changes to driver model internals may be substantial. ... global device tree, giving each driver instance its own unique namespace. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch 0/8] Nesting class_device patches that actually work
      ... The changes to driver model internals may be substantial. ... > global device tree, giving each driver instance its own unique namespace. ... > hang them off the root of the tree. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)