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

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