In message <200402170846.17399.freebsd-current_at_webteckies.org>, Melvyn Sopacua writes: >> 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. That is the 64000 dollar question. Current our handing is that if it disappears, it's gone, if it comes back it's probably a new one anyway. This is far from optimal, and as much as one can ridicule the infamours "Abort, Retry or Ignore ?" from MS-DOS, I bet we have all had our bacon saved by that one at least once. I think it is desirable for an "anonymous" device like a keyboard to "just work" when you plug it in, and this should happen in some sort of generic "local keyboard" handling which will grab hold of any keyboard, AT, PS/2, USB, Firewire or Bluetooth. We have something similar for pointing devices, "/dev/sysmouse" and moused(8), but I must confess that I have no idea how it is implemented. In both cases his is/should be done in userland, and likely under the direction of devd(8). It gets far more interesting once we talk about disk-media which is mounted by filesystems or similar. Ideally we should "lock the media in place" when it is open, but only some technologies (partly) support this, so it is not a feasible solution. And while it seems silly to not offer some sort of "oops" function for people who prematurely yank their disk, implementing it is tricky. Part of the trouble is that the filesystem needs to handle the situation with some sort of "now _is_ this really the same media ?" function before resuming and none of our filesystems have that today. And to make things interesting, the device might not have the same name when it comes back. GEOM offers some potential for solving this. We could either encapsulate that behaviour in a geom-class so the filesystems would not have to learn about it, or once we move the filesystems to go directly to GEOM, they could have a taste method and recapture the device when it comes past. [1]. Second issue is about the user interface: How do we know which user to annoy ? Where we pop up the A/R/I message ? How do they reply to us ? How long time should we wait before we give up ? Should we whistle the River Kwai March on the internal speaker while we wait ? These are surprisingly very hard questions to answer (well, maybe not the last...) and it is even harder to implement code for the answer which is generally usable. So all things considered, in particular calendars, I don't think it is going to happen anytime soon for disk devices. Poul-Henning [1] This is letting the cat out of the bag somewhat prematurely: the fact that filesystems become GEOM classes means that with a ->taste() method, they could automount any filesystem of their type which comes past, provided they know where to mount it to. For non-fsck'able filesystems like cd9660 I can see this being done safely, for fsck'able filesystems like UFS I can see a ton of problems. Like all other sorts of AI, I'm not sure I would want this in the first place, so it would certainly be optional if we ever did it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk_at_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.Received on Tue Feb 17 2004 - 01:23:47 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:43 UTC