pardon my ignorance here, but it would seem you're asking for two different
things:
(1) a way to call a 'fsck'-type program, at filesystem-mount-time, and
(2) a generic way for your device to pass 'action' messages back to
user-space
(1) can already be handled in user-space. initrd is its name.
you can keep a fsck-type program in user-land, yet have it called early in
the boot sequence if required.
(by definition, if the kernel can load, then the initrd image has loaded
too..).
(2) i'll leave open to the masses. however, given (1) can probably give
you a /dev too, i think its probably already resolved via /dev
interaction. yes, you'd still need an /etc/rc.d script to fix it up later
on in the boot sequence, but that isn't exactly rocket science either.
cheers,
lincoln.
At 19:14 10/11/99 -0700, Jeff V. Merkey wrote:
>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/