Why not confine the changes to libc?
Use the existing kernel implementation alone. This carries the
least risk, and bloats the kernel least.
Store data forks in a directory with various named parts. Change libc
to add the extra directory layer (slash then named part), and then
back off and do it "the old way" if that fails. You could even
have different named parts for different system calls; e.g. "/exec"
for exec(), "/data" for open(). Create and rename (etc) need a
little attention, but then they would, no matter where you implemented
it.
This way, all file systems get data forks, not just those that support
them.
This way, if done in glibc, all unixes can gave data forks, not just Linux.
This way, a spectacular variety of data fork contents can be used
and experimented with (not just a few shallow ones).
This way, extending the data fork functionality, requires no kernel
support. Done carefully (see "back off" above) requires little or
no libc support, either.
This way, libc can cope with existing FS that do support data forks, with
multiple conflicting schemes, and *still* not need to change the
kernel.
So, why not confine meta-file support to libc?
Regards
Peter Miller E-Mail: millerp@canb.auug.org.au
/\/\* WWW: http://www.canb.auug.org.au/~millerp/
Disclaimer: The opinions expressed here are personal and do not necessarily
reflect the opinion of my employer or the opinions of my colleagues.
-
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.altern.org/andrebalsa/doc/lkml-faq.html