From owner-freebsd-current@FreeBSD.ORG Mon Feb 9 07:54:31 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 B0B6916A4CE; Mon, 9 Feb 2004 07:54:31 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E11743D1F; Mon, 9 Feb 2004 07:54:31 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i19Fs9GX012526; Mon, 9 Feb 2004 16:54:23 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Stijn Hoop From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 09 Feb 2004 16:00:39 +0100." <20040209150039.GS2803@pcwin002.win.tue.nl> Date: Mon, 09 Feb 2004 16:54:09 +0100 Message-ID: <12525.1076342049@critter.freebsd.dk> cc: drosih@rpi.edu cc: Pawel Jakub Dawidek cc: julian@elischer.org cc: current@freebsd.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: Mon, 09 Feb 2004 15:54:31 -0000 In message <20040209150039.GS2803@pcwin002.win.tue.nl>, Stijn Hoop writes: > >--qo7zVO9a9OQ5oQtr >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >Content-Transfer-Encoding: quoted-printable > >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! Ohh and by the way: a new device appeared calling itself /dev/foo, looks like some sort of ICMB launch thingie or something... Furthermore, if you open(2) a normal filesystem node, you hold a reference on it, so that even if people remove the file, you can still work on it until you are finished. If for instance you open a file and write a megabyte from the beginning, and call fsync on it and all your return codes were good, you can be assured that no reads nor writes inside that one megabyte will fail subsequently (provided the hardware doesn't croak) [1]. In /dev, if somebody removes your hardware, it's gone and there's not a damn thing you can do about it, and no stake or state you can claim to have reservation on. /dev is strange I tell ya! :-) Poul-Henning [1] It's still a good idea to check, hardware _does_ croak. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.