I think the right answer is to use fcntl and have one file:
#include <fcntl.h>
that includes all fcntls. We don't need to specify which file system.
Some file systems might not support all the fcntls.
We should change/add ext2's ioctls to fcntls and have a call from
sys_fcntl to a file system specific fcntl if the generic fcntl doesn't
know about the cmd given.
The collision between driver ioctls and fcntls worries me.
These are really separate functions.
If Linux/Linus doesn't want to do this, we should have one file with all
ioctls. I see that there is /usr/include/bits/ioctls.h and
/usr/include/asm/ioctls.h. But, ext2's ioctls are in an ext2 specific file:
linux/include/linux/ext2_fs.h for 2.3.*.
These are defined as:
/*
* ioctl commands
*/
#define EXT2_IOC_GETFLAGS _IOR('f', 1, long)
#define EXT2_IOC_SETFLAGS _IOW('f', 2, long)
#define EXT2_IOC_GETVERSION _IOR('v', 1, long)
#define EXT2_IOC_SETVERSION _IOW('v', 2, long)
What should XFS or any other file system do with these? I guess they
should return EINVAL. What if we accidentally or purposely get called
with this? Applications don't normally check which file system they are
running on. I don't suspect that all file systems should be including
linux/include/linux/ext2_fs.h.
I think the above should be moved into one of the ioctls.h or changed
to be fcntls.
I guess the way to fix all this is to make a patch and see if it gets
accepted. Suggestions?
Thanks,
Jim
>
>I had a look at the Solaris manual page for fcntl, and I saw that at least one
>of those supported by XFS is also supported by Solaris (F_FREESP). I also
>looked at the Solaris manual page for ioctl, and they seem to think that the
>fcntl call should be used for manipulating the object viewed as a filesystem
>file, and ioctl manipulating it as an I/O stream.
>
>Since fcntl can take multiple arguments, would something like the following be
>a reasonable idea?:
>
> fcntl(fd,F_FSCTL,"xfs",...);
>
>Thus F_FSCTL would be a "file-system specific control function", the third
>argument would be the name of the filesystem it's intended for, and the extra
>arguments say what the control function actually is.
>
>Or, if passing extra parameters like this is too much trouble for the kernel
>syscall interface, then the following may be a reasonable alternative:
>
> struct fsctl {
> const char *f_fsname;
> int f_operation;
> void *f_data;
> };
>
> struct fsctl f = { "xfs", XFS_DO_SOMETHING, &data };
>
> fcntl(fs,F_FSCTL,&f);
>
>What do you think?
>David Howells
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:18 EST