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/