Joerg Schilling schrieb am 2006-02-13:
> Well it is obvious that this is a requirement.
>
> If Linux does device name mapping at high level but leaves the low level part
> unstable, then the following coul happen:
>
> Just think about a program that checks a file that is on a removable media.
>
> This media is mounted via a vold service and someone removes the USB cable
> and reinserts it a second later. The filesystem on the device will be mounted
> on the same mount point but the device ID inside the system did change.
>
> As a result, the file unique identification st_ino/st_dev is not retained
> and the program is confused.
How does $OS know the storage device wasn't plugged into another system
during that second and changed in that time? This doesn't even seem
far-fetched, just think of USB-capable KVM switches.
Changing st_dev and returning I/O error or stale FS error or whatever is
adequate makes perfect sense. Once the device is unplugged, the mount is
dead. st_dev stability (that is not demanded by POSIX) doesn't help a
iota in making it usable again.
You're barking up the wrong tree anyways. You're holding on to a
non-workable b,t,l approach because it's convenient on BSD and some
other systems, but it cannot be stable. The only stable identifiers I
conceive are brand,model,serial - and this is the way to get rid of the
ugly race between cdrecord -scanbus and cdrecord dev=b,t,l.
Yes, it requires you to change the interface. It doesn't even matter you
need to do that, because hotplug was probably not an issue when libscg
saw the first light on SunOS. Changes in the environment require some
lifeforms to adjust to the new conditions. If they don't change, they'll
die out. This is just natural.
And to make the brand,model,serial approach bullet-proof, the kernel
should detect if this triple is duplicated at some time and refuse to
talk to ANY of these until all but one have been unplugged, just in case
no serial number is provided by a particular device of which two
specimen are plugged.
--
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
