Messages in this thread | | | Date | Wed, 10 Nov 1999 19:14:41 -0700 | From | "Jeff V. Merkey" <> | Subject | Re: [Fwd: Getting IOCTL's into VFS File System Drivers] |
| |
Peter,
Pardon me, but what APIs? The problem here is that NT supplies the needed APIs and Linux doesn't. It's not a hack to allow folks to write USER/KERNEL drivers through a general IOCTL interface. Linux doesn't have one for FS drivers, but everyone else does. I can't use NWFS as a boot FS if I cannot open symbolic handles to talk to the FS driver.
Jeff
"H. Peter Anvin" wrote: > > "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/
- 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/
| |