lkml.org 
[lkml]   [1999]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Fwd: Getting IOCTL's into VFS File System Drivers]

Peter,

The problem with this is there's a chicken and egg situation. I cannot
call any IOCTL's until a volume is first mounted (which is not very
helpful). NetWare and Windows 2000 both support IOCTL's into the file
system driver. I need to be able to talk to the file system without any
volumes mounted. It sounds like that this is not possible with Linux
unless I do some "hack" and create a dummy device driver (which means
that Linux will always be dependent on EXT2 being present or it won't
work). I am trying to set it up so Linux can use NWFS as a boot file
system, and it appears you folks are going to oppose this hapenning by
restricting needed capabilities in Linux?

I looked at the ". root" idea as an IOCTL method, and already came to
the conclusion this would not work because you need a mounted volume
present or you cannot talk to the driver. The Caldera Netware NDS
Client does something very similiar an uses a dummy device driver to
pass IOCTL's back and forth from the kernel, but they have an ugly
script in rc.d that checks if the dummy device is present, deletes it,
re-creates it, then opens it. If this is all there is to call IOCTL's
in the FS driver, then the Linux version of NWFS will be inferior to the
versions on NT/2000. This also means I have to write an RPM file that
will do this and hack up the users scripts. Having a simple binary
driver (like Windows 2000 let's me have) is preferable becuase it makes
it easy to support (my call center I contract through the Service and
Support Group I deal with charges me 0.89/minute for service calls --
it's cheaper if I don't have to pay someone and educate them to use unix
scripting language).

You guys need to understand I come at this from a commercial software
perspective, and that customers aren't interested in unix "hackery"
methods to get stuff working -- they just want it to be easy and work
the first time. Telling a user they have to "hack" up a bunch of
scripts and stand on their heads to get stuff working ISNT ACCEPTABLE.
Most computer customers are pretty lazy , and if it takes them longer
that 10 minutes to figure something out, they give up, and go down the
street and buy something else (which means I have less $$$ to fund Linux
development projects).

Jeff


"H. Peter Anvin" wrote:
>
> 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/

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

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.074 / U:0.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site