Messages in this thread | | | Date | Wed, 10 Nov 1999 16:18:25 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [Fwd: Getting IOCTL's into VFS File System Drivers] |
| |
"Jeff V. Merkey" wrote: > > 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
YOU need to understand that we're not going to make Linux shock-full of ad hoc kluges just because you're not interested in following the accepted APIs. One thing you have to realize is that user-space scripts, or /dev nodes, are just as much as part of a device driver as is a kernel module. The whole thing is a *package*. There is nothing klugy about this, even if it is perhaps different from the model you are used to; in fact, it sounds almost as though you're expecting Linux to fit neatly into the Win2K model, which it certainly won't -- thank heavens!
This is why we have packaging systems (RPM et al.)
If this thing is to be a "boot" file system (I presume you mean *root* filesystem here?), you need to be able to mount it onto / without any user-space intervention, so you can't have any need for user-space interaction under those circumstances. Once / is mounted, you should have /dev available, so using a device node is perfectly reasonable for non-volume-specific operations, which seems to be what you're referring to.
In general, use a /dev node for the non-volume-specific operations (if any); you can (but don't need to) use ioctl()s on the mount point for things where you want the filesystem to point you to *a specific mounted volume* in a natural way.
I have no clue about the Caldera NDS client or what the issue is you're talking about is.
-hpa
- 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/
| |