Re: removable media revalidation - udev vs. devfs or static /dev

["\"Andrey Borzenkov\" " <arvidjaar@mail.ru>]

> 
> > NOTE! We do have an alternative: if we were to just make block device 
> > nodes support "readdir" and "lookup", you could just do
> > 
> > 	open("/dev/sda/1" ...)
> > 
> > and it magically works right. I've wanted to do this for a long time, but 
> > every time I suggest allowing it, people scream.
> 
> Hm, that would be nice.  I don't remember seeing it being proposed
> before, what are the main complaints people have with this?
>

this has been in Linux long enough and was called "devfs". Apparently
somebody decided this was evil and removed it. I too am interested
what exatcly was wrong with this design (not implementation)?

Unfortunately the problem is worse than just that.

The main reason to use udev is to have persistent names for devices.
Currently my USB may be sda1 and next time I stick it in may be sdb1;
so I'd like to call it /dev/usb0 and use it.

But in this case we do not have even this possibility of revalidating
media on access to /dev/sda/1 because not only do not we have
/dev/usb0 as yet - we do not even know what it possibly points at.

Assuming - oh, horror - that we do use devfs, we have LOOKUP event,
so we can call naming agent for /dev/usb0 - and we can tell it that
usb0 refers to SCSI device on first port of my USB hub (you usually
plug it in the same slot do not you?) It can find out that there
is already block device for it and simply initiate rescan of
partition. Magically making sda/1 appear and linking usb0 to it.

Without some kind of LOOKUP event apparently the only possibility
is polling :(

regards

-andrey