Re: usb flash drive removal (Re: Desktop NetBSD needs your help)

[Antti Kantee <pooka%NetBSD.org@localhost>]

> >> On Tue, Feb 10, 2009 at 5:23 AM, David Holland
> >> <dholland-current%netbsd.org@localhost> wrote:
> >>>
> >>> None of them, however, are Unix-derived. It is a disgrace that
> >>> removable media handling in Unix has remained broken all this time.

Yes, rewriting our entire OS is not easy.  Plus I don't think it
would the way to go anyway.

> >> I can't wait to use the patch you'll provide!
> >
> > Maybe we should add it to the Google Summer of Code project list.
> >
> > Jared
> >
> 
> It is already there:
> http://www.netbsd.org/contrib/soc-projects.html#disk-removal

I think suggesting this to a student is an even worse idea than
just doing it.  The student needs very extensive knowledge about
kernel locking and the implications of blocking block device
operations for an arbitrary time and will most likely be frustrated
after the initial code is written and the system should actually
do something useful.  One problem I pointed out yesterday offline
is that you need to block while holding locks (e.g. a vnode/inode
lock) in the pseudo-block driver and this will most likely hang
the system.  So you need to back out to a level high enough and
retry or allow access meanwhile otherwise.

If you say it's acceptable to block before the device is reconnected,
how do you deal with e.g. the UI notification component which was
supposed to alert about accidental device unblock hanging on the
unplugged file system.

Better at least mark difficulty somewhere between ridiculous and
ludicrous.

If you really want to move forward with this, you might consider
looking at fstrans, which likely solves a semi-similar problem with
locks.  That way you can put your file system/whatever object into
a state where readonly access for the previous known good state is
ok but the pending transaction can still block.

If the SoC project is only about implementing the block device
driver, then I agree it is of reasonable difficulty.  However, for
reasons listed above, I don't see any real-world benefit.