Re: The disappearing sys_call_table export.

[Jesse Pollard <jesse@cats-chateau.net>]

On Friday 09 May 2003 09:37, Ragnar Kjørstad wrote:
> On Fri, May 09, 2003 at 08:53:04AM -0500, Jesse Pollard wrote:
> > On Thursday 08 May 2003 14:43, Chuck Ebbert wrote:
> > > > Have you tried catching the display IO ???
> > >
> > >   Not in a million years -- display drivers work by pure magic AFAIC.
> > >
> > > > HSM has existed on UNIX based machines for a long time.
> > >
> > >   Show me three HSM implementations for Linux and I'll show you three
> > > different mechanisms. :)
> >
> > Actually... I think they all use the same one (Even the Solaris/IRIX/Cray
> > ones do that). All of them provide a filesystem interface via VFS. The
> > Linux ones were implemented via the "userfs" core or NFS.
>
> I'm not sure what you mean by "via" VFS, but most HSM implementations on
> linux require extra interfaces and special support in the filesystem (XDSM
> or propriatary).

All of the HSM systems I've used had the XDSM handled outside the kernel.
The only thing actually IN the kernel was the VFS module to intercept the
VFS calls (like userfs did) and then pass them to an external daemon to 
retrieve the data of migrated files. In the two cases, the rest of the 
filesystem was implemented within the VFS module. One case I've read about,
(datatree??? something like that) used an NFS interface to allow it to pass
the requests on to a non-HSM filesystem when the data was put on disk.

> The only exceptions I know are openXDSM which was intended to be a
> generic interface in the VFS-layer (but we never got time to implement
> it) and a implementation based on stackable filesystem.
>
> I don't know if the later is actually in use anywere, or if it is
> abandoned.

I don't know either, but all XDSM was to do was support the user mode
infrastructure behind the VFS module.