From owner-freebsd-current@FreeBSD.ORG Tue Jan 25 15:30:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 648E616A4CE for ; Tue, 25 Jan 2005 15:30:31 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCD2E43D53 for ; Tue, 25 Jan 2005 15:30:30 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id j0PFU3rA004376; Tue, 25 Jan 2005 10:30:04 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)j0PFU3cQ004373; Tue, 25 Jan 2005 15:30:03 GMT (envelope-from robert@fledge.watson.org) Date: Tue, 25 Jan 2005 15:30:03 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <86137.1106666028@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: pete@altadena.net cc: current@freebsd.org cc: "M. Warner Losh" Subject: Re: Devd event from GEOM? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 15:30:31 -0000 On Tue, 25 Jan 2005, Poul-Henning Kamp wrote: > In message , Robert Watson writes: > > >We're really not interested > >in the newbus announcement, since there are lots of network interfaces > >that have no physical representation and so aren't visible to newbus. > > I think this is the crux of the matter. > > newbus events will mostly be able tell us that we need to load a driver > kld. > > devfs events on the other hand tells us that something can be accessed > from userland. ... Except for the synthetic objects that don't have device nodes. :-) > Since we added /dev/net/* we have sort of collapsed the split we > previously had where some devices did not appear in /dev. The net device nodes were added for one purpose: to allow Kqueue to attach to a network interface, as kqueue requires a file descriptor. And most of the network developers I've talked to think this was probably a design error. Note that the network stack has a fairly complex event system already -- routing sockets, which express a spectrum of network-related events including, but not limited to, interfaces appearing and disappearing. Adding /dev/net entries added multiple paths to the same ioctl() mechanism, complicated the network interface allocation path substantially (introducing more races), etc. I'd much prefer we got rid of them, if we can. > There are still virtualized cases though, adding more hardware under > opencrypto comes to mind. I can't really turn that into an example > where we need to do more than respond to newbus by loading the driver. > > But as I said in the other email, we should probably have devfs > communicate the type of device to devd to save some rather complex code > in userland. (The regexp matching all our ethernet drivers in devd.conf > have always irritated me). We have all the information in the kernel ("I found a device", "it was a SCSI disk", "and we can store bytes on it!", "and it has partitions!") -- that we're not exposing it to user space means that we're doing far too good a job of hiding quite accessible information. If the information is bundled up neatly for delivery so that the layer relationships are clear -- fine, although I don't think that will be possible in every case (i.e., da0 arriving in newbus and GEOM may be simultaenous, but we might not have finished probing da0s1a.foobar for quite a bit later). Robert N M Watson