Date: Wed, 18 Feb 2004 06:36:16 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: freebsd-current@webteckies.org Cc: julian@elischer.org Subject: Re: Review/Test: Pseudo-device unit number management patch Message-ID: <20040218.063616.36828248.imp@bsdimp.com> In-Reply-To: <200402170846.17399.freebsd-current@webteckies.org> References: <12525.1076342049@critter.freebsd.dk> <200402170846.17399.freebsd-current@webteckies.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200402170846.17399.freebsd-current@webteckies.org>
Melvyn Sopacua <freebsd-current@webteckies.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040218.063616.36828248.imp>