In message <[EMAIL PROTECTED]>, Tigran
Aivazian writes:
> I noticed the stackable fs item on Alan's list ages ago but there was no
> pointer to the patch (I noticed FIST stuff but surely that is not a "small
> passive patch" you are referring to?)
Yes the patches are small and passive. No new vfs/mm code is added or
changed! The most important part of my patches had already been included
since 2.3.17; that was an addition/renaming of a private field in struct
vm_area_struct. What's left are things that are necessary to support
stacking for the first time in linux: exposing some functions/symbols from
{mm,fs}/*.c, adding externs to headers, additions to ksyms.c, and moving
some macros and inline functions from private .c files to a header, so they
can be included in any file system.
I've used these patches on dozens of linux machines for the past 2+ years,
and have had no problems. I constantly get people asking me when my patches
will become part of the main kernel. I have about 9 active developers who
write file systems using my templates. I've had more than 21,000 downloads
of my templates in the past two years.
> So, my point is - if you point everyone to those patches, someone might
> help Alan out if one feels like it (and has time).
http://www.cs.columbia.edu/~ezk/research/software/fist-patches/
The latest 2.3 patches in that URL include two things: my small main kernel
patches, and a fully working lofs. The lofs of course is several thousands
of lines of code, but it is not strictly necessary to include it with the
main kernel; it can be distributed and built separately, just as my other f/s
modules are. However, I do think that lofs is a useful enough f/s that it
should be part of the main kernel.
If you go to the 2.3 directory under the above URL, there's a README
describing the latest 2.3 patches. I've included it below, so everyone can
read it and see what my patches do, and how harmless they are.
BTW, I've got a prototype unionfs for linux if anyone is interested.
> Regards,
> Tigran.
As always, I'll be delighted to help *anyone* use my work, and would love to
help the linux maintainers incorporate my patches, answer any concerns they
might have, etc.
Cheers,
Erez.
==
Summary of changes for 2.3.25 to support stackable file systems and lofs.
(Note: some of my previous patches had been incorporated in 2.3.17.)
(1) Created a new header file include/linux/dcache_func.h. This header file
contains dcache-related definitions (mostly static inlines) used by my
stacking code and by fs/namei.c. Ion and I tried to put these
definitions in fs.h and dcache.h to no avail. We would have to make
lots of changes to fs.h or dcache.h and other .c files just to get these
few definitions in. In the interest of simplicity and minimizing kernel
changes, we opted for a new, small header file. This header file is
included in fs/namei.c because everything in dcache_func.h was taken
from fs/namei.c. And of course, these static inlines are useful for my
stacking code.
If you don't like the name dcache_func.h, maybe you can suggest a better
name. Maybe namei.h?
If you don't like having a new header file, let me know what you'd
prefer instead and I'll work on it, even if it means making more changes
to fs.h, namei.c, and dcache.h...
(2) Inline functions moved from linux/{fs,mm}/*.c to header files so they
can be included in the same original source code as well as stackable
file systems:
check_parent macro (fs/namei.c -> include/linux/dcache_func.h)
lock_parent (fs/namei.c -> include/linux/dcache_func.h)
get_parent (fs/namei.c -> include/linux/dcache_func.h)
unlock_dir (fs/namei.c -> include/linux/dcache_func.h)
double_lock (fs/namei.c -> include/linux/dcache_func.h)
double_unlock (fs/namei.c -> include/linux/dcache_func.h)
(3) Added to include/linux/fs.h an extern definition to default_llseek.
(4) include/linux/mm.h: also added extern definitions for
filemap_swapout
filemap_swapin
filemap_sync
filemap_nopage
so they can be included in other code (esp. stackable f/s modules).
(5) added EXPORT_SYMBOL declarations in kernel/ksyms.c for functions which I
now exposed to (stackable f/s) modules:
EXPORT_SYMBOL(___wait_on_page);
EXPORT_SYMBOL(add_to_page_cache);
EXPORT_SYMBOL(default_llseek);
EXPORT_SYMBOL(filemap_nopage);
EXPORT_SYMBOL(filemap_swapout);
EXPORT_SYMBOL(filemap_sync);
EXPORT_SYMBOL(remove_inode_page);
EXPORT_SYMBOL(swap_free);
EXPORT_SYMBOL(nr_lru_pages);
EXPORT_SYMBOL(console_loglevel);
(6) mm/filemap.c: make the function filemap_nopage non-static, so it can be
called from other places. This was not an inline function so there's no
performance impact.
ditto
