Re: Review/Test: Pseudo-device unit number management patch

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.