Messages in this thread | | | Date | Wed, 10 Nov 1999 16:59:00 -0700 | From | "Jeff V. Merkey" <> | Subject | Re: [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/
| |