Hans Reiser [EMAIL PROTECTED] wrote:
Jeff Mahoney wrote:
Hans Reiser wrote:
Jeff Mahoney wrote:
1) Because then the behavior of /proc/fs/reiserfs/ would be
inconsistent. Devices that contain slashes end up being one level deeper
than other devices, which is silly and a userspace visible
Nikita Danilov [EMAIL PROTECTED] wrote:
Stephen Pollei writes:
On 9/19/05, Horst von Brand [EMAIL PROTECTED] wrote:
Nikita Danilov [EMAIL PROTECTED] wrote:
It's other way around: declaration is guarded by the preprocessor
conditional so that nobody accidentally use
Hans Reiser [EMAIL PROTECTED] wrote:
Nick Piggin wrote:
Hans Reiser wrote:
So why is the code in the kernel so hard to read then?
Linux kernel code is getting better, and Andrew Morton's code is
especially good, but for the most part it's unnecessarily hard to
read. Look at the
David Masover [EMAIL PROTECTED] wrote:
Pavel Machek wrote:
V3 is obsoleted by V4 in every way. V3 is old code that should be
marked as deprecated as soon as V4 has passed mass testing. V4 is far
superior in its coding style also. Having V3 in and V4 out is at this
point just stupid.
Hans Reiser [EMAIL PROTECTED] wrote:
Horst von Brand wrote:
[...]
It is supposed to go into the kernel, which is not exactly warning-free.
While I have no passionate feelings about Nikita's ifdef, I must note
that Reiser4 will always be warning free within 3 days of my finding out
Nikita Danilov [EMAIL PROTECTED] wrote:
Denis Vlasenko writes:
On Friday 16 September 2005 20:05, Hans Reiser wrote:
All objections have now been addressed so far as I can discern.
Random observation:
You can declare functions even if you never use them.
Thus here you can
Hans Reiser [EMAIL PROTECTED] wrote:
Horst von Brand wrote:
that and there's much more exciting filesystems like ocfs2 around that
This is exciting to... whom?
To Cristoph, obviously. You should thank him for doing the (hard, boring,
thankless) work of reviewing code for free. Even
michael chang [EMAIL PROTECTED] wrote:
On 9/18/05, Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote:
This is it. I do not say accept reiser4 NOW, I am saying give Hans
good code review.
After he did his basic homework. Note that
Hans Reiser [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
The type-unsafety of existing list_heads gives me conniptions too. Yes,
it'd be nice to have a type-safe version available.
[...]
Vladimir spent 24 hours straight unsafing the lists in reiser4, and
didn't finish yet. We need 1-2
David Masover [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
Horst von Brand wrote:
Hans Reiser [EMAIL PROTECTED] wrote:
Stefan Smietanowski wrote:
[...]
Better to spend one's mind looking for bugs instead of this issue.
.if bugs were seen as such a big deal.
I think it's far
Hans Reiser [EMAIL PROTECTED] wrote:
Stefan Smietanowski wrote:
I think ... and .meta both serve as a logical delimiter. However
some programs implement their own ... which would make it clash with
them. Naturally if some program created a directory called .meta we're
equally screwed.
I
David Masover [EMAIL PROTECTED] wrote:
[...]
Both camps seem to want to allow easy access to the metadata of a
file, whether we're given that file as an inode or as a pathname.
That's why I suggested /meta/vfs and /meta/inode -- sometimes I want
to look up a file by name, and sometimes by
David Masover [EMAIL PROTECTED] wrote:
[...]
Just don't allow user-created hardlinks inside either metafs (/meta) or
the magical meta directory inside files.
And what is it useful for, after its advantage was that it was /exactly/
like regular files c, and now it is severely crippled?
--
Dr.
Hubert Chan [EMAIL PROTECTED] wrote:
On Fri, 01 Jul 2005 03:41:00 -0400, Chet Hosey [EMAIL PROTECTED] said:
Horst von Brand wrote:
And who says that a normal user isn't allowed to annotate each and
every file with its purpose or something else?
Explain how you currently allow users
Hans Reiser [EMAIL PROTECTED] wrote:
[...]
I think the exokernel approach by Frans is a very interesting approach.
I wish I had the experience with it necessary to know if it was
effective. I do NOT take the position that name resolution should be in
the kernel. I DO take the position
Hubert Chan [EMAIL PROTECTED] wrote:
On Wed, 06 Jul 2005 12:52:23 -0600, Jonathan Briggs [EMAIL PROTECTED] said:
On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote:
Hubert Chan wrote:
And a question: is it feasible to store, for each
inode, its parent(s), instead of just the hard link
David Masover [EMAIL PROTECTED] wrote:
Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
David Weinehall wrote:
On Fri, Jul 01, 2005 at 03:08:58AM -0500, David Masover wrote:
David Weinehall wrote:
[...]
Even if they don't, it would be more beneficial to me
How, exactly
Kevin Bowen [EMAIL PROTECTED] wrote:
[...]
So, for instance, if I want to grab all mp3s with Artist Paul
Oakenfold and change the genre to techno (can you do that?), I can
use Beagle's search tool to find all mp3s by Oakenfold, but to change
the genre, I have to use some separate tool
David Masover [EMAIL PROTECTED] wrote:
David Weinehall wrote:
On Fri, Jul 01, 2005 at 03:08:58AM -0500, David Masover wrote:
David Weinehall wrote:
GNOME and KDE run on operating systems that run other kernels than
Linux, hence they have to implement their own userland VFS anyway.
Adding
David Weinehall [EMAIL PROTECTED] wrote:
On Thu, Jun 30, 2005 at 11:57:27AM -0400, Hubert Chan wrote:
On Thu, 30 Jun 2005 08:29:56 +0200, David Weinehall [EMAIL PROTECTED]
said:
[...]
From the web *browser*'s point of view, it is handled by the
filesystem (which is provided by the
Markus Törnqvist [EMAIL PROTECTED] 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
Kevin Bowen [EMAIL PROTECTED] wrote:
might be nice to have on exclusively one-user, isolated machines, like
keep /my/ annotations/icon/application name/whatever with the file's
data, but that break down in multiuser (even serially, one user after the
If this is really the core of your (and
Hubert Chan [EMAIL PROTECTED] wrote:
[...]
Of course. With file-as-dir, you can cd /usr/games/tetris/... and
mess with the game files, or you can run /usr/games/tetris and get on
with ... stacking blocks.
And doing tar cf /dev/tape /usr/games/tetris gives you a nice tangle of
undecipherable
Markus Törnqvist [EMAIL PROTECTED] wrote:
[...]
Note that MacOS has the monopoly on what they ship, Linux has a
motherload of file managers and window systems and all.
Yep. Part of what is nice about it, too ;-)
What pisses me off is the fact that Gnome and friends implement
their own
Markus Törnqvist [EMAIL PROTECTED] wrote:
On Thu, Jun 23, 2005 at 11:34:50PM -0400, Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
I think Hans (or someone) decided that when hardware stops working, it's
not the job of the FS to compensate, it's the job of lower layers
Alexander Zarochentsev [EMAIL PROTECTED] wrote:
On Sunday 26 June 2005 21:02, Christoph Hellwig wrote:
[...]
David and Hans, I've read through my backlog a lot now, and I must say
it's pretty pointless - you're discussing lots of highlevel what if and
don't actually care about something
David Masover [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
[...]
Reiser4 plugins are not per user, but per kernel. They are compiled
in. The model is intended to ease the development process, nothing
more. Apologies if the naming suggests more.
What do you gain by this? It is just a
David Masover [EMAIL PROTECTED] wrote:
Kyle Moffett wrote:
On Jun 26, 2005, at 22:37:48, David Masover wrote:
[...]
That just means the zip plugin has to be more carefully written than I
thought. It would have to be sandboxed and limited to prevent buffer
overruns and zip bombs.
[...]
David Masover [EMAIL PROTECTED] wrote:
Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
Jeff Garzik wrote:
[...]
Ain't broke is the battle cry of stagnation.
I see it as the battle cry
David Masover [EMAIL PROTECTED] wrote:
Alan Cox wrote:
On Iau, 2005-06-23 at 23:04, David Masover wrote:
[...]
What for? It works just fine as it stands, AFAICS.
So does DOS. Do you use DOS? I don't even use DOS to run DOS programs.
False argument. So does the pen, so do hinges on
Timothy Webster [EMAIL PROTECTED] wrote:
[...]
I think it is the task of the linux community to
generalize the vfs layer and not lock out reiserfs4
until that is done.
No... the task of the Linux community is to make a better kernel.
You will have to do the work to convince it that the
David Masover [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
Jeff Garzik wrote:
[...]
You missed his point. He is saying ext3 code should migrate towards
becoming reiser4 plugins, and reiser4 should be merged now so that the
migration can get started.
Sort of.
I think ext3 would be
Artem B. Bityuckiy [EMAIL PROTECTED] wrote:
Markus TÐrnqvist wrote:
So merge it as it is
Fix it first. The merge as it stands just gives rise to stuff that is
/never/ fixed properly.
and move the stuff to the VFS as needed or
deemed necessary. And enable the pseudo
Alexander G. M. Smith [EMAIL PROTECTED] said:
Hans Reiser wrote on Mon, 20 Dec 2004 09:21:35 -0800:
Ok, go talk to the befs driver guy, and you'll find out he has already
done work on it.
I just did some work in making a test file system with hard links and
bidirectional references (files
Hans Reiser [EMAIL PROTECTED] said:
David Masover wrote:
Hans Reiser wrote:
[...]
| My solution is to tell Nate Diller that there is extensive literature on
| it, that it isn't really the big problem it is made out to be, and leave
| it to him to go read the literature and code it up
Hans Reiser [EMAIL PROTECTED] said:
Horst von Brand wrote:
Peter Foldiak [EMAIL PROTECTED] said:
[...]
Perhaps a better way to think about this is that instead of talking
about directories and files, we just talk about objects.
Then you have a collection of interrelated objects, i.e
Peter Foldiak [EMAIL PROTECTED] said:
[...]
Perhaps a better way to think about this is that instead of talking
about directories and files, we just talk about objects.
Then you have a collection of interrelated objects, i.e., a database.
Operating systems that work on databases (no
Peter Foldiak [EMAIL PROTECTED] said:
Horst von Brand wrote:
Now think about files with other formats, for instance the (in)famous
sendmail.cf, or less structured stuff like you find in /etc/init.d/, or
just Postgres databases (with fun stuff like permissions on records and
fields)... or just
Peter Foldiak [EMAIL PROTECTED] said:
On Tue, 2004-11-30 at 14:51, Horst von Brand wrote:
I was suggesting this idea mainly form XML files, where the tags define
the parts clearly.
Use a XML parsing library then.
But namespace unification is important,
Why? Directories
Peter Foldiak [EMAIL PROTECTED] said:
On Tue, 2004-11-30 at 16:31, Horst von Brand wrote:
But namespace unification is important,
Why? Directories are directories, files are files, file contents is file
contents. Mixing them up is a bad idea.
I disagree, I think it is a good idea
Christian Mayrhuber [EMAIL PROTECTED] said:
On Saturday 27 November 2004 12:09, Peter Foldiak wrote:
On Fri, 2004-11-26 at 21:13, Christian Mayrhuber wrote:
Regarding namespace unification + XPath:
For files: cat /etc/passwd/[. = joe] should work like in XPath.
I don't understand
Spam [EMAIL PROTECTED] said:
Christer Weinigel [EMAIL PROTECTED] said:
[...]
Could you please try summarize a few of the arguments that you find
especially compelling? This thread has gotten very confused since
there are a bunch of different subjects all being intermixed here.
Spam [EMAIL PROTECTED] said:
Christer Weinigel [EMAIL PROTECTED] said:
[...]
But this still solves only part of the problem. A backup application
won't have any use for a copyfile syscall, it will need to be taught
about streams.
Yes, but backup programs always needed to be taught
Spam [EMAIL PROTECTED] said:
Horst von Brand [EMAIL PROTECTED] said:
Helge Hafting [EMAIL PROTECTED] said:
[...]
The only new thing needed is the ability for something to be both
file and directory at the same time.
Then why have files and directories in the first place?
Good
Spam [EMAIL PROTECTED] said:
Dave Kleikamp [EMAIL PROTECTED] said:
Spam [EMAIL PROTECTED] said:
[...]
You're missing the point. We don't need transparency in all apps. You
can write an application to be as transparent as you want, but you don't
need every app to to understand every
Rik van Riel [EMAIL PROTECTED] said:
On Thu, 26 Aug 2004, Linus Torvalds wrote:
So /tmp/bash is _not_ two different things. It is _one_ entity, that
contains both a standard data stream (the file part) _and_ pointers to
other named streams (the directory part).
Thinking about it some
Spam [EMAIL PROTECTED] said:
Chris Wedgwood wrote:
[...]
Gnome, KDE, Emacs and Bash all see different virtual filesystems.
(All but Bash implement their own virtual filesystem extensions).
That makes them much less useful than they could be.
Exactly, and I doubt they have
entry. Right?
If they are unreferenced, they can be dropped without much cost. The
problem is what to do if you have 40 pages, each 1/10 filled with data in
active use.
--
Horst von Brand http://counter.li.org # 22616
48 matches
Mail list logo
