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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
