Chip Salzenberg wrote:
> According to Alan Cox:
> > Given a file handle 'X' how do I find out what ioctl groups I should
> > apply to it.
>
> Wouldn't it be better just to *try* ioctls and see which ones work and
> which ones don't?
As ioctl's is just numbers that can be valid but mean totally different thing depending on device I don't see how this is going to work. It took me close to a month to figure out why my new 10000rpm scsi disk constantly ended up with a read only filesystem. What I did not know at that time was that the /dev/sg[x] numbering was changed by adding something to the scsi chain and my backup software now sent the eject command to the disk instead of to the tape. This ioctl means spinn down when it is sent to the disk and that in turn produces a fatal error and a remount to ro for the mounted filesystem.
This problem had not existed for me if things had been mapped more static this i why I'am not overly happy hearing that things is going to be even more volatile. But I guess that it's possible to solve most of this issues in userspace.
One way of looking on the problem is to take it to it's logical extrem. This would be a kernel with no persistent storage for devices no major,minor and no name policy. The kernel would simply put any device it finds in /dev/devno/[x] where x is just a number that should be seen as something that changed for every reboot.
Any userspace solution that can create device links that are stable out of this is one that would get my vote. This obviously needs some type if standard why to query the devices or else it's no way it can work.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 15 2001 - 21:00:46 EST