[lkml]   [1999]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Fwd: Getting IOCTL's into VFS File System Drivers]


    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.


    "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
    > Please read the FAQ at

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:54    [W:0.025 / U:14.388 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site