Re: silent semantic changes with reiser4

[Hans Reiser]

A friend asked me a question, and because he is very bright it reminded 
me that I have not done a good job of reviewing the history of the 
design's evolution.

He asked me, why not just access a filename's size as filename/size?

So, the original idea was to access metafiles as just files within a 
directory, and it actually remains that way. However, I first decided to 
make the standard unix metafiles less intrusive on the namespace. So 
that led to calling it filename/..size and filename/..owner, etc. In 
this scheme, the use of '..' was just a style convention for metafiles, 
and not a requirement in anyway.

This was actually pretty decent as a design, but then a user on the 
mailing list suggested replacing the '..' prefix with a subdirectory 
prefix. I forget who suggested this and what the prefix was exactly. So 
we then created a '..metas' subdirectory, and this had the advantage 
that one could ls it to see all the builtins supported by a given 
plugin. This is not an important advantage, and I encourage others to 
critique it.

So, instead of filename/size we have filename/..metas/size. The only 
thing gained by this is that 'size' has a rarer name of '..metas/size'. 
The use of the '..metas/' prefix is purely a non-mandated style 
convention. File plugins that dislike it are free to violate the 
convention. There is no deep semantic to it, just a cowardly aversion to 
intruding on current namespace usage with something as common as 'size'. 
It has the significant disadvantage of being a longer name than 'size' 
or '..size'. I could be talked out of it.

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/