Re: reiser4 plugins

Horst von Brand
2005-06-30T20:34:49Z

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2511 bytes --]

Markus Törnqvist <mjt@nysv.org> wrote:
> On Thu, Jun 30, 2005 at 07:18:47PM +0400, Nikita Danilov wrote:
> >Sorry, I don't see your point. Again: if you think that user level
> >developers are unlikely to agree to the common framework, what
> >difference it makes whether this framework is defined at the kernel or
> >library boundary? Applications would have to be changed to conform to
> >the common API either way.

> I see it as a heavier incentive to do it by a framework that's in
> the kernel.

API is API, if in-kernel, in-X-lib, or in-userland-VFS-lib is completely
irrelevant.

> >If you can force application developers to conform to the LSB why you
> >cannot do the same with the library level interface?

> If I want to access metadata with bash, do I patch bash to support
> both Gnome's and KDE's solutions? Was there one of XFCE too?
> And FooBarXyzzyWM that'll want to do it's own VFS next year?

It's your only option... or get them together and define a common
framework.

But then again, what would I want to do with metadata in bash? If needed,
it is probably much easier to write tools to extract whatever is needed, no
reason to futz around with the shell. That simple idea was the single most
important advance Unix introduced: The shell is a /simple/ program, it
doesn't do word processing and coffee brewing for you. That is handled by
other programs, one for each task.

> I'd also guess that the upstream guys would much rather have
> patches for their progs that conform to the kernel than some
> obscure neighbor userspace system.

Or just keep only their own obscure userspace system, no need to have to
mess with our own format and a kernel system.

> Sure looks like having this in the kernel makes it easiest; there's
> just one common denominator to patch for.

Again: API is API. If in kernel or in a standard library makes no
difference. Libary is /much/ easier to develop, and hugely more
flexible. It is for a reason that printf(3) and qsort(3) are /not/
in-kernel.

> This doesn't even invalidate the userland VFSs of the other guys,
> they're still needed for systems whose kernels don't have a
> metadata facility.

So the metadata facility in kernel won't be used, for portability's sake.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513