[ale] "Back-End" Filesystems

[Joseph A. Knapka]

Jeff Hubbs wrote:
> 
> > I'm with you so far, and timball's suggestion ("use a fifo") is
> > adequate to this point.
> 
> OK, this at least tells me that something I might want has a name and I
> can R the appropriate FM or whatever.
> 
> > Now you've lost me. You want to send input to some process via
> > a file-like interface, fine. But you also want something more,
> > and that something is... to have the receiving process catalog
> > the input in a filesystem-like manner? I don't think I really
> > understand what you're getting at here.
> 
> To the extent I'm able to understand all this so far (and this is also
> in response to your very illumating {to me, at least} description of
> what "ls" does), I don't so much want the receiving process to "catalog
> the input in a filesystem-like manner" as I want it to actually respond
> as a real filesystem would.  The way I'm seeing it, a filesystem, real
> or not, would have to respond to calls from libc in a documented and
> reproduceable way.

That's true. But I'm wondering what kind of filesystem-like operations
you want to do, besides reading and writing files to the server
process. If that's -all- you need, then "man mkfifo" and away you
go. Can you give us an example of another kind of filesystem-like
behavior you want to achieve?

I suppose it would be possible to do some interesting stuff with
a module that just plugged into the kernel VFS code and forwarded
the VFS requests to some user-mode program. I wonder if something
like that has already been done? You could implement filesystems
entirely in user mode, which might be nice for development and
testing.

> > (4) The kernel does "whatever is necessary" to fetch the desired
> > info. Normally that will involve calls into the kernel's Virtual
> > Filesystem code, which provides a uniform interface to all the
> > filesystems Linux supports. The "ls" program, however, doesn't care
> > about that at all. All it cares about is that it can make a system
> > call, and the kernel will magically provide the requested data.
> 
> I think you're basically with me.  It sounds as though what I'm after is
> some kind of implementation that plugs into that "Virtual Filesystem"
> code in much the same way that the, duuuh, module (??) for ext2 or
> msdosfs would.
> 
> Wow.  Can MS people, as end users/implementors, really even HAVE
> conversations like these???

No :-)  I just recently finished burning my NT laptop's hard disk
to the ground and re-installing *everything* for about the fifth
time in the past year. The reason: I couldn't get my software
to connect to the Oracle server running on the same machine,
due to an undocumented COM error. For someone else in my company
who had the same (apparent) problem, re-installing
Oracle fixed it -- but not for me. So what else could I do? This
is the kind of thing you have to resort to when you have no way to
know what the software is actually *doing*. I've said it before,
and I'll say it again: I've never had a problem on a Linux box
that I absolutely could not at least find the exact cause of -
and usually I can figure out how to fix it, too (with some
help from the good folks at ALE :-)

Someday I will work in an all-open-source environment. Someday
I really want to be able to say, "I've reinstalled Windows
for the last *&#^$% time!"

-- Joe Knapka
"You know how many remote castles there are along the gorges? You
 can't MOVE for remote castles!" -- Lu Tze re. Uberwald
// Linux MM Documentation in progress:
// http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html
2nd Lbl A + 1 = 2nd Pause 2nd Prt GTO 2 R/S
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.