Re: silent semantic changes with reiser4

[Markus Törnqvist]

[ This will probably go down in history as the most pointless message
  ever, I just told Nik on IRC I'd take it up on the list :) ]

On Sun, Aug 29, 2004 at 09:22:08PM +0400, Nikita Danilov wrote:
>Spam writes:

>Hmm... drag-and-drop also doesn't work constently over all
>applications. Let's put it into kernel.

What I'm after is that the file system should be able to store
any arbitrary metadata. No matter what the format is.

Maybe I was a bit harsh on XML in my previous email, but whatever.

>Seriously, kernel prformance is critical to the system, and to achieve
>high performance all kernel code runs in single address space (actually,
>in portion of address spaces of user processes shared by all
>processes). All shared system state is located there. This means that
>bug in a kernel affects whole system. This means that kernel should be
>kept as simple as possible (and a bit more simple).

I do agree here. But is it seriously such a big issue to implement
the files-as-dirs kind of thing?

Be it overloading MAY_READ so it works with chdir or implementing openat
or whatever it takes.

I don't think this should be much more, if any more, than the capability
to store this data. Which Reiser4 does. But moved from the Reiser4
level to the VFS level. Right?

>This is why only things that cannot be done efficiently in the user
>level are put into kernel. And political agendas of various camps of
>user-level developers change nothing here.

What I'd want to do is to be able to write a Reiser4 plugin that suits
my needs for something. Not that I'd even know how to, but that's a
matter of time.

Are there other means of doing this than Reiser? I mean Reiser4 plugin
functionality by other means.

>>   Still.  Why do you oppose plugins, streams and meta files? The could
>>   be   valuable   and  easy  to use tools for many purposes. One could
>>   be  would be advanced ACLs defined as a meta-file using XML format.
>POSIX has standard ACL API in C (well, "eternal draft" only), one can
>use it to extract ACLs from kernel and convert it to any format to one's
>heart content. Advantage of this is that when XML goes out of fashion (I
>hope this wouldn't yet happen when you will read this message), kernel
>API will remain intact.

Aa, this apparently is an argument against XML parsing in the kernel,
not the idea that if someone wanted ACLs, that are in XML format, and
could not use them (because the kernel doesn't parse), he should be
able to write such a plugin.

Besides, let's say the Reiser4 XML-ACL plugin has a parser that actually
DOES something. For argument's sake. Would it not be up to the individual
user to disable this plugin? I'd assume it's possible to write plugins
so that they do not affect anything but themselves, meaning this parser.

Of course the problem of copying a file with XML-ACLs to another Reiser4
fs without support for them should be thought of. But I guess this is
where you take the shortest route; the XML-ACL files are intact in the
file's metadata, but totally unusable?

-- 
mjt

-
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/