[ale] "Back-End" Filesystems

Jeff Hubbs jhubbs at telocity.com
Mon Jul 23 21:27:26 EDT 2001



> 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.  
 

> (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???

- Jeff
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.





More information about the Ale mailing list