I have another idea: Suppose we take the inode substructures for
keeping track of file length and blocks used and created a
duplicate of these structures. This way we would have a meta data
area tracked in the inode along with the data area. The meta data
area could function like the data area for a directory, i.e. you
can not simply write to it; Instead you can only manipulate the
data area via system calls that are specific to it. Also, the
data area could be organized into variable length logical entries,
in the same manner that directories are. Each entry could be
organized into a tag and a value. Some characteristic of the
tag (e.g. the first byte or the high order bit) could determine
if it is a kernel tag or a user tag. The entire meta data area
could be read with an open_meta() call, and parsed something like
the way we parse a directory.
This way, meta data would be associated with the inode, so
it would not be subject to confusion if the file is linked
in multiple directories, each with it's own ".metadata" file.
The kernel could have some easy way to determine its level
of interrest in a tag. This approach is flexable enough
that we would not have to make fundimental changes to the
inode structure to add additional meta data functionality,
we would only go through that pain once. A meta-aware
version of tar could save all the meta without having
to understand what any of it means. It could restore the
metadata with an insert_meta_entry() call, and the kernel
would be free to reject any request that it doesn't like,
again without tar having to understand what the tags are.
The kernel could return with the error EDONTDOTHAT for
tags that are never altered by the user, and tar could
know not to complain and not to try to set that tag for
any later files. You could save and restore individual
files, without having to go through some complex locking,
reading, and updating process on the ".metadata" file that
holds info for all files in a directory.
User tags could be assigned in the same way we assign
well known ports under IP, without the kernel caring
what they mean. The meta data for a file that is
still open, but has been unlinked, would still be
accessable through the "/proc" subdirectory for the
process that has it open.
Sooner of later, I think it will be handy to be able
to attach meta data to the inode for a file, and
not to the directory (even in a logical sense). No
matter how you look at it, attaching more kinds of
data to the inode will require changing the inode
structure, and this means creating a new filesystem.
Shouldn't we be coming up with a flexible enough
scheme to keep us from having to jump filesystems
any more than necessary? The VFS hooks to support
what I propose would also give us a means to fake
some of the more complex features of non-unix,
filesystems like NTFS, SMBFS, and Novel, even if
we did not know about them before freezing the
inode structure layout. A loadable module could
register its ownership of a "kernel" tag that the
base kernel didn't understand. It could also
register itself into a list of modules to be called
before a "EPERM" error is indicated to the user.
People who didn't want the kernel bloat associated
with a complex ACL scheme could leave it out.
people who wanted to experiment with a really
bizarre tag could load and unload it without
rebooting, and without a creating a new type
of filesystem for each iteration of the feature
being designed.
Just an idea....
--- L. Adrian Griffis - KE6CSX - adrian@idir.net- 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.tux.org/lkml/faq.html