[lkml]   [2004]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: silent semantic changes with reiser4
Hash: SHA1

Horst von Brand wrote:
|>Second, there are quite a few things which I might want to do, which can
|>be done with this interface and without patching programs,
| Such as?

They've been mentioned.
|> but would
|>require massive patches to userspace. There have been numerous examples.
| Haven't seen any that made sense to me, sorry.

Sorry if they don't make sense to you, but I don't feel like discussing
them now. Either you get it or you don't, either you agree or you
don't. Read the archives.
|>There are some things which can't be solved without patching.
| Maybe. Question is, is it worth it (kernel modifications + userland
| support, or just userland support, or leave it alone). Sure, it might make
| your particular application easier to write (at a cost for _all_
| hackers!), perhaps even a bit faster; but is _your_ particular convenience
| worth the cost for _everybody_?

There are far more userland developers than filesystem hackers. If
you're a filesystem hacker, it's easier to understand how much work it
is to do something in the filesystem/kernel, and harder to understand
how it works in userland, or for the actual user.
|> Version
|>control is one such thing.
| bk, cvs, svn, rcs, ... are working just fine here, thank you so much. Used
| to work on SunOS and Solaris, even SCO Unix (I used at least rcs and cvs
| there). No Reiser4 in sight.


It _works_ to do
zcat file.gz > /tmp/file
vim /tmp/file
gzip -c /tmp/file > file.gz
rm /tmp/file
You can even do that as a script, call it zvim. You could even do it as
a generic script, where "vim" is replaced with "$1". But is it as
elegent as transparently compressed files?

I'm not sure about the version control thing -- I don't think people
have hit every conceptual issue about it yet. But the point is:

Moving complexity from kernel space to user space (or the other way)
doesn't make it any less complex.

|> But then there can be more generic patches
|>- -- as soon as the transaction API is done, you only have to patch apps
|>to use that, and have a version control reiser4 plugin.
| Again, _what_ version control exactly? Will the above packages be able to
| make use of it (remember they all are cross-platform (at least
| and so quite unlikely to make use of a Reiser4 on Linux whackiness...)?

Probably. It wasn't specified what version control would be used --
that's currently just as abstract as what compression algorithm to use
to transparently compress files.

Maybe something new. Version control just doesn't look that complex
once you've got the interface and the data storage done. I do
incremental backups using rsync and hardlinks -- why would version
control be so much more complex than that?

Said backup system uses hardlinks, btw, which not all systems support.
And rsync is fairly broken on some platforms.

|>| I'd go the other way around: Get userspace to agree on a common
|>| make it work in userspace; if (extensive, hopefully) experience
shows that
|>| a pure userspace solution has issues that can't be solved except by
|>| assistance, so be it.
|>We already have such a framework -- it's called "VFS".
| Right. It offers what applications need to build their own stuff. It is
| minimalistic (well, sort of) and time-proven.

x86 assemby is minimalistic and time-proven.
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.568 / U:33.136 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site