From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 05:36:34 2004 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 5651316A4CE; Wed, 18 Feb 2004 05:36:34 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C775F43D1F; Wed, 18 Feb 2004 05:36:33 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1IDaVnJ047301; Wed, 18 Feb 2004 06:36:31 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 18 Feb 2004 06:36:16 -0700 (MST) Message-Id: <20040218.063616.36828248.imp@bsdimp.com> To: freebsd-current@webteckies.org From: "M. Warner Losh" In-Reply-To: <200402170846.17399.freebsd-current@webteckies.org> References: <12525.1076342049@critter.freebsd.dk> <200402170846.17399.freebsd-current@webteckies.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: drosih@rpi.edu cc: phk@phk.freebsd.dk cc: pjd@FreeBSD.ORG cc: current@FreeBSD.ORG cc: julian@elischer.org Subject: Re: Review/Test: Pseudo-device unit number management patch 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: Wed, 18 Feb 2004 13:36:34 -0000 In message: <200402170846.17399.freebsd-current@webteckies.org> Melvyn Sopacua writes: : On Monday 09 February 2004 16:54, Poul-Henning Kamp wrote: : > In message <20040209150039.GS2803@pcwin002.win.tue.nl>, Stijn Hoop writes: : > >On Mon, Feb 09, 2004 at 03:32:16PM +0100, Poul-Henning Kamp wrote: : > >> Please also remember: /dev is _not_ an inventory of available devices. : > > : > >Just curious: what is it then? An inventory of available drivers? An : > >inventory of open devices? : > : > "A naming-space gateway from filenames to device drivers : > whose exact mapping is only stable in the timeinterval : > between a successful open(2) and the corresponding close : > (be it an explict close or not)." [2] : > : > Fortunately it is a good deal more deterministic than what my feeble : > attempt at a definition above could make it sound :-) : > : > The practical effects are hard to explain, but one example is that : > the stat/open race is much more fundamental in /dev than anywhere : > else in the filesystem. : > : > In the normal filesystem, a few odd things may happen between calls : > to stat(2) and open(2), in /proc you may get a different process : > than you intended, but in /dev _any_ odd thing may happen. : > : > You thought you opened a serial port called /dev/foo connected to : > your printer ? Well, I got news for you: it disappeared! : : How does this work, when there's no mechanism in place to signal "the return : of the thingy". Mostly thinking about the keyboard here, because even if : there was a recheck_keyboard_existence utility, one couldn't really type it : in. So far I haven't been able to plug-in the keyboard and get it back again. The return of the thingy is handled at the driver/bus level. When a device is unplugged, it is removed, including and /dev entries. When it is plugged in, it is added, including any /dev entries. The current keyboard/mouse controller devices, however, don't seem to have these brains in them (they are also horrible to deal with). The good news is that the keyboard won't go away in 5.x right now if you unplug it. The bad news is that it can not be there at boot and no keyboard device will be installed. Warner