Re: [Fwd: Getting IOCTL's into VFS File System Drivers]

H. Peter Anvin (hpa@transmeta.com)
10 Nov 1999 22:53:23 GMT


Followup to: <3829F0C7.59C568A7@timpanogas.com>
By author: "Jeff V. Merkey" <jmerkey@timpanogas.com>
In newsgroup: linux.dev.kernel
>
> Alan/Ingo/Pavel,
>
> Do you one you guys know a good way to get IOCTL calls into the FS
> drivers? I noticed there is an IOCTL path for FILE objects, but there
> does not appear to be a general purpose IOCTL call to the File System
> Drivers themselves (but there is to symbolic devices files created by
> these FS's). I basically need this for the utilities that create and
> config volumes and mirroring so I can query as to whether a file system
> is mounted from the tools, and prohibit users from blowing away volume
> segments, namespaces, etc. while a volume is mounted. There are also
> some question/answer stuff during boot from a Netware file system if
> NWFSCK (Netware volume repair utility) gets invoked due to mounting
> problems. I need to be able to pass back and forth, such as asking
> whether an imcomplete mirror group should be activated and failing
> mirrors dropped during system boot if FS errors are detected.
>
> I am calling open() from the utilities with symbolic handles for device
> objects (i.e. /dev/hda, /dev/hdb, etc.) and this is how I am creating
> partitions, volumes, etc. Is there a symbolic handle that will map to
> the FS driver so I can pass IOCTL commands between the utilities and the
> file system driver, like /proc/filesystems/nwfs or something to that
> effect? I religously poured over the code in Linux until 4 a.m. this
> morning, and it doesn't look like this is supported.
>

No, there isn't. You basically have two options: open the root
directory of the filesystem and ioctl() to that (that is what autofs
does); that is appropriate for per-mountpoint ioctl()s. The other
solution is to have a conventional /dev node and have your filesystem
driver also be a character device driver (this is quite trivial.)
This is appropriate for non-per-mountpoint operations; ARLA for
example uses this method.

-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."

- 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/