From owner-freebsd-arch@FreeBSD.ORG Thu Sep 18 14:22:51 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC6A616A4B3; Thu, 18 Sep 2003 14:22:51 -0700 (PDT) Received: from herring.nlsystems.com (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F91443F75; Thu, 18 Sep 2003 14:22:50 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [10.0.0.2] (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.12.9/8.12.8) with ESMTP id h8ILM8W2025271; Thu, 18 Sep 2003 22:22:09 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Poul-Henning Kamp In-Reply-To: <2559.1063885425@critter.freebsd.dk> References: <2559.1063885425@critter.freebsd.dk> Content-Type: text/plain Message-Id: <1063920128.18459.8.camel@herring.nlsystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 18 Sep 2003 21:22:08 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: bms@spc.org cc: Robert Watson cc: "M. Warner Losh" cc: freebsd-arch@FreeBSD.org Subject: Re: devd limitations / automounting removable storage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2003 21:22:52 -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.