Hello, Christoph
We have fixed most of your complains.
Would you be so kind to find some time and take a quick look at reiser4
(2.6.14-rc5-mm1 +
ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.14-rc5-mm1/broken-out-3)
However, there are some problems:
Christoph Hellwig wrote:
more trivial
On Mon, Sep 26, 2005 at 07:03:52PM +0400, Vladimir V. Saveliev wrote:
- you still do your plugin mess in -readpage. honsetly could you
please explain why mpage_readpage{,s} don't work for you?
The reason is performance. Reiser4 uses a search through the filesystem tree
to
access
Christoph Hellwig wrote:
On Mon, Sep 26, 2005 at 07:03:52PM +0400, Vladimir V. Saveliev wrote:
- you still do your plugin mess in -readpage. honsetly could you
please explain why mpage_readpage{,s} don't work for you?
The reason is performance. Reiser4 uses a search through the
Hello
Christoph Hellwig wrote:
more trivial review comments ontop of the previous one, after looking
at things:
- please never use list_for_each in new code but list_for_each_entry
done
- never use kernel_thread in new code but kthread_*
done
- do_sendfile duplicates the common
Gregory Maxwell wrote:
Very interesting indeed, although it almost seems silly to tackle the
difficult problem of making filesystems highly robust against oddball
failure modes while our RAID subsystem falls horribly on it's face in
the fairly common (and conceptually easy to handle) failure mode
On 9/23/05, David Greaves [EMAIL PROTECTED] wrote:
who's not keeping up with the linux-raid list then ;)
David
PS I'm sure assistance would be appreciated in testing and reviewing
this few day old feature - or indeed the newer 'add a new disk to the
array' feature.
After posting that I
On Sep 20, 2005, Stephen Pollei [EMAIL PROTECTED] wrote:
it takes gcc -Wall test_proto.c --std=c99 -pedantic-errors to cause it
not to create the a.out .
So gcc should have caused an error as I didn't set --std=gnu99 .. bad
compiler.
So I don't know howto get gcc to follow the standards in
Hello.
Среда 21 сентября 2005 02:10 | Pavel Machek:
At tytso's request... could you put some reiser3 and reiser4
filesystem images inside test data?
I've not tested Reiser3, but Reiser4 images (fsck.okay and repaired
fsck.damaged is here (sorry, I have no log of 125 passes test run, only
one
On Wednesday 21 September 2005 01:11, Theodore Ts'o wrote:
On Tue, Sep 20, 2005 at 12:18:46PM -0600, Jonathan Briggs wrote:
I use Reiser3 and Reiser4 on all my systems and fsck has always worked
even if it has been much slower than I would like. The only problems
I've experienced have
On Wednesday 21 September 2005 07:05, Hans Reiser wrote:
Ric Wheeler wrote:
Hans Reiser wrote:
Ric Wheeler wrote:
As an earlier thread on lkml showed this summer, we still have a long
way to go to getting consistent error semantics in face of media
failures between the various
Hans Reiser writes:
Stephen Pollei wrote:
Also note my opinion, doesn't really count if you grep the kernel
sources for pollei, you won't find anything.
Your opinion counts, but lets see what Nikita says before I say
anything. Nikita is more expert than I in regards
Gregory Maxwell wrote:
On 9/20/05, Hans Reiser [EMAIL PROTECTED] wrote:
Another goal of the group should be to formulate a requested set of
changes or extensions to the makers of drives and other storage
systems. For example, it might be advantageous to be able to disable
bad block
Nikita Danilov wrote:
Hans Reiser writes:
Stephen Pollei wrote:
Also note my opinion, doesn't really count if you grep the kernel
sources for pollei, you won't find anything.
Your opinion counts, but lets see what Nikita says before I say
anything. Nikita is more
Ric Wheeler wrote:
Gregory Maxwell wrote:
On 9/20/05, Hans Reiser [EMAIL PROTECTED] wrote:
Another goal of the group should be to formulate a requested set of
changes or extensions to the makers of drives and other storage
systems. For example, it might be advantageous to be able to
Hans Reiser wrote:
Ric Wheeler wrote:
Gregory Maxwell wrote:
On 9/20/05, Hans Reiser [EMAIL PROTECTED] wrote:
Another goal of the group should be to formulate a requested set of
changes or extensions to the makers of drives and other storage
systems. For example, it might be
Hans Reiser writes:
[...]
So what do you suggest we change it to, Nikita?
Just remove #ifdef/#endif as was suggested.
Nikita.
Nikita Danilov wrote:
Hans Reiser writes:
Horst von Brand wrote:
Funny that the texbook algorithms aren't used in real life. Wonder why...
Try BSD. If the BSD book can be believed, they usetexbook algorithms.
The textbook one-way elevator (as indeed exemplified by
Nikita Danilov wrote:
Hans Reiser writes:
[...]
Yes, and one can compensate for them fairly cleanly. I can't say more
without the customer releasing the code first.
That's the point: text-book algorithms are usually useless as is. They
need adjustments and changes to work in real
Theodore Ts'o wrote:
On Tue, Sep 20, 2005 at 09:41:36AM -0500, David Masover wrote:
And personally, if it was my FS, I'd stop working on fsck after it was
able to check. That's what it's for. To fix an FS, you wipe it and
restore from backups.
If that's Reiser4's philosophy, just
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 elevator code for instance. Ugh.
What's
Hi!
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.
Really? Last time I checked, even V3's fsck was not too
Nick Piggin wrote:
On Mon, 2005-09-19 at 23:28 -0700, Hans Reiser wrote:
Nick Piggin wrote:
What's wrong with the elevator code?
The name for one. There is no elevator algorithm anywhere in it. There
is a least block number first algorithm that was called an elevator,
Horst von Brand wrote:
Care to give names?
Not publicly, no. If akpm or Linus asks, I will happily encourage
either of them to try to win him back.
who decided to work on BSD
because they had too much dignity to develop a filesystem for Linux.
CC list trimmed.
On Tue, 2005-09-20 at 00:59 -0700, Hans Reiser wrote:
Nick Piggin wrote:
On Mon, 2005-09-19 at 23:28 -0700, Hans Reiser wrote:
Well the terminology changed to io scheduler now, however the
residual elevator name found in places doesn't cause anyone
any problems and
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 znode_is_loaded() outside of
the debugging mode.
On Tue, Sep 20 2005, Hans Reiser wrote:
The name for one. There is no elevator algorithm anywhere in it. There
is a least block number first algorithm that was called an elevator, but
Well the terminology changed to io scheduler now, however the
residual elevator name found in
On Tuesday 20 September 2005 13:42, Jens Axboe wrote:
On Tue, Sep 20 2005, Hans Reiser wrote:
The name for one. There is no elevator algorithm anywhere in it. There
is a least block number first algorithm that was called an elevator, but
Well the terminology changed to io
On Tue, Sep 20 2005, Lorenzo Allegrucci wrote:
On Tuesday 20 September 2005 13:42, Jens Axboe wrote:
On Tue, Sep 20 2005, Hans Reiser wrote:
The name for one. There is no elevator algorithm anywhere in it. There
is a least block number first algorithm that was called an elevator, but
Lorenzo Allegrucci [EMAIL PROTECTED] writes:
[...]
Why not just rename the kernel option elevator to iosched ?
At least update Documentation/kernel-parameters.txt to be consistent,
but I think kernel boot options are considered to be a part of the user
space API and, as such, cannot be
Pavel Machek wrote:
Hi!
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.
Really? Last time I checked, even
On Tue, 20 Sep 2005, Lorenzo Allegrucci wrote:
On Tuesday 20 September 2005 13:42, Jens Axboe wrote:
On Tue, Sep 20 2005, Hans Reiser wrote:
The name for one. There is no elevator algorithm anywhere in it. There
is a least block number first algorithm that was called an elevator, but
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
Nick Piggin wrote:
[snip devfs]
Yeah I was just trying to introduce some humour to the thread!
Or maybe deflate one flamewar by starting another :)
;-)
Jens Axboe wrote:
Seeing as you are the one that is apparently bothered by the misnomer,
it follows that you would be the one submitting a patch for this. Not
that it would be accepted though, I don't see much point in renaming
functions and breaking drivers just because of a slightly bad name.
David Masover wrote:
And personally, if it was my FS, I'd stop working on fsck after it was
able to check. That's what it's for. To fix an FS, you wipe it and
restore from backups.
Umm, this is going too far David. Our fsck should work, and we will
give his script to Vitaly to play with
Horst von Brand wrote:
Nikita Danilov [EMAIL PROTECTED] 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
that
Nikita Danilov wrote:
Lorenzo Allegrucci [EMAIL PROTECTED] writes:
[...]
Why not just rename the kernel option elevator to iosched ?
At least update Documentation/kernel-parameters.txt to be consistent,
but I think kernel boot options are considered to be a part of the user
space API
Thanks much for this test script, Vitaly, please give it a try and tell
me how it goes.
Hans
Pavel Machek wrote:
Hi!
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.
Horst von Brand wrote:
Funny that the texbook algorithms aren't used in real life. Wonder why...
Try BSD. If the BSD book can be believed, they usetexbook algorithms.
;-)
On Sep 20, 2005, Stephen Pollei [EMAIL PROTECTED] wrote:
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 znode_is_loaded() outside of
Horst von Brand wrote:
Could you /please/ stop your snide remarks on the code and its authors? If
for nothing else, the very people you are insulting in public are the exact
ones that will decide if they take on the work of auditing and integrating
your code.
Our code was called messy. It
On Tue, Sep 20, 2005 at 09:41:36AM -0500, David Masover wrote:
And personally, if it was my FS, I'd stop working on fsck after it was
able to check. That's what it's for. To fix an FS, you wipe it and
restore from backups.
If that's Reiser4's philosophy, just make sure you tell all of your
On Tue, Sep 20 2005, Hans Reiser wrote:
Jens Axboe wrote:
Seeing as you are the one that is apparently bothered by the misnomer,
it follows that you would be the one submitting a patch for this. Not
that it would be accepted though, I don't see much point in renaming
functions and
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.
On Tue, 2005-09-20 at 13:57 -0400, Theodore Ts'o wrote:
On Tue, Sep 20, 2005 at 09:41:36AM -0500, David Masover wrote:
And personally, if it was my FS, I'd stop working on fsck after it was
able to check. That's what it's for. To fix an FS, you wipe it and
restore from backups.
If
On Tue, Sep 20 2005, Hans Reiser wrote:
Horst von Brand wrote:
Funny that the texbook algorithms aren't used in real life. Wonder why...
Try BSD. If the BSD book can be believed, they usetexbook algorithms.
Even the BSD people are looking for better algorithms. To be honest, I
Hans Reiser writes:
Horst von Brand wrote:
Funny that the texbook algorithms aren't used in real life. Wonder why...
Try BSD. If the BSD book can be believed, they usetexbook algorithms.
The textbook one-way elevator (as indeed exemplified by FreeBSD's
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
that
Hello.
Вторник 20 сентября 2005 11:51 | Pavel Machek:
Can V4 survive few hours of test below?
Maybe I'm doing something wrong here, but ext2 have failed on second check
of first pass with
Second check...
e2fsck 1.34 (25-Jul-2003)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking
On Tue, 20 Sep 2005 23:28:12 +0400, Roman I Khimov said:
--nextPart1692600.LIfSYN1P7A
Maybe I'm doing something wrong here, but ext2 have failed on second check
of first pass with
Second check...
e2fsck 1.34 (25-Jul-2003)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking
On Tue, Sep 20, 2005 at 12:18:46PM -0600, Jonathan Briggs wrote:
I use Reiser3 and Reiser4 on all my systems and fsck has always worked
even if it has been much slower than I would like. The only problems
I've experienced have been on the same level as when an ext2/3
filesystem fsck dumps
On Tue, Sep 20, 2005 at 04:15:41PM -0400, [EMAIL PROTECTED] wrote:
On Tue, 20 Sep 2005 23:28:12 +0400, Roman I Khimov said:
--nextPart1692600.LIfSYN1P7A
Maybe I'm doing something wrong here, but ext2 have failed on second check
of first pass with
Second check...
e2fsck 1.34
On Tue, 20 Sep 2005 17:17:13 EDT, Theodore Ts'o said:
An exit code of 1 means that filesystem errors were corrected
(successfully).
Right. The problem is that this was a *second* check, after the first one
terminated with exit code 0, 1, or 2. Thus, it *should* have exited with 0.
The
Hi!
Can V4 survive few hours of test below?
Maybe I'm doing something wrong here, but ext2 have failed on second check
of first pass with
No, you have probably just found bug in e2fsck...
Second check...
e2fsck 1.34 (25-Jul-2003)
I have 1.38 here, so yours is too old.
OTOH if reiser4
Hello.
Среда 21 сентября 2005 01:37 | Pavel Machek:
Second check...
e2fsck 1.34 (25-Jul-2003)
I have 1.38 here, so yours is too old.
I'll compile something new tomorrow and try to retest it.
OTOH if reiser4 survives that for 80 cycles... that's pretty good.
Actually 125 before I've
On 9/20/05, Hans Reiser [EMAIL PROTECTED] wrote:
Horst von Brand wrote:
Nikita Danilov [EMAIL PROTECTED] wrote:
It is supposed to go into the kernel, which is not exactly warning-free.
Is that what this thread boils down to, that you guys think the compile
should fail not warn?
I don't care
Hi!
Second check...
e2fsck 1.34 (25-Jul-2003)
I have 1.38 here, so yours is too old.
I'll compile something new tomorrow and try to retest it.
OTOH if reiser4 survives that for 80 cycles... that's pretty good.
Actually 125 before I've got completely tired of HDD noise. :)
On 9/20/05, Stephen Pollei [EMAIL PROTECTED] wrote:
On 9/20/05, Hans Reiser [EMAIL PROTECTED] wrote:
Horst von Brand wrote:
Nikita Danilov [EMAIL PROTECTED] wrote:
It is supposed to go into the kernel, which is not exactly warning-free.
Is that what this thread boils down to, that you
On 9/20/05, Alexandre Oliva [EMAIL PROTECTED] wrote:
On Sep 20, 2005, Stephen Pollei [EMAIL PROTECTED] wrote:
On 9/19/05, Horst von Brand [EMAIL PROTECTED] wrote:
Since when has a missing declaration prevented anyone calling a function in
C?!
Never AFAIK... KR, ANSI,ISO C89, c99,
On Tue, 20 Sep 2005, James Lamanna wrote:
On 9/20/05, Stephen Pollei [EMAIL PROTECTED] wrote:
On 9/20/05, Hans Reiser [EMAIL PROTECTED] wrote:
Horst von Brand wrote:
Nikita Danilov [EMAIL PROTECTED] wrote:
It is supposed to go into the kernel, which is not exactly warning-free.
Is
On 9/20/05, Vadim Lobanov [EMAIL PROTECTED] wrote:
On Tue, 20 Sep 2005, James Lamanna wrote:
On 9/20/05, Stephen Pollei [EMAIL PROTECTED] wrote:
On 9/20/05, Hans Reiser [EMAIL PROTECTED] wrote:
Horst von Brand wrote:
Nikita Danilov [EMAIL PROTECTED] wrote:
What about #warning /
On Tue, Sep 20, 2005 at 09:51:33AM +0200, Pavel Machek wrote:
Do you have working fsck for V4? Until then, you should not claim that
users should switch. Journalling does not help you, if you have
unexpected kernel problem or hardware trouble, fsck _is_ mandatory.
Can V4 survive few hours of
Theodore Ts'o wrote:
On Tue, Sep 20, 2005 at 12:18:46PM -0600, Jonathan Briggs wrote:
I use Reiser3 and Reiser4 on all my systems and fsck has always worked
even if it has been much slower than I would like. The only problems
I've experienced have been on the same level as when an ext2/3
Thanks Ted, I'll ask Vitaly to read the paper, and tell us what he
thinks should be learned from it for V4.
Hans
Theodore Ts'o wrote:
On Tue, Sep 20, 2005 at 09:51:33AM +0200, Pavel Machek wrote:
Do you have working fsck for V4? Until then, you should not claim that
users should switch.
Stephen Pollei wrote:
Also note my opinion, doesn't really count if you grep the kernel
sources for pollei, you won't find anything.
Your opinion counts, but lets see what Nikita says before I say
anything. Nikita is more expert than I in regards to compiler tricks.
Pavel Machek wrote:
Hi!
Second check...
e2fsck 1.34 (25-Jul-2003)
I have 1.38 here, so yours is too old.
I'll compile something new tomorrow and try to retest it.
OTOH if reiser4 survives that for 80 cycles... that's pretty good.
Actually 125 before I've got
Theodore Ts'o wrote:
Another interesting refinement would be to analyze the resulting
filesystem after it has been repaired to determine how much data could
be salvaged by the fsck program.
We use reiserfs3 to store data and have had very good luck in getting
data off of real world, hard
Ric Wheeler wrote:
As an earlier thread on lkml showed this summer, we still have a long
way to go to getting consistent error semantics in face of media
failures between the various file systems. I am not sure that we even
have consensus on what that default behavior should be between
On 9/20/05, Theodore Ts'o [EMAIL PROTECTED] wrote:
The script could be improved by select random locations to damage the
filesystem, instead of hard-coding the seek=7 value. Seek=7 is good
for testing ext2/ext3 filesystems, but it may not be ideal for other
filesystems.
What would be
Hans Reiser wrote:
Ric Wheeler wrote:
As an earlier thread on lkml showed this summer, we still have a long
way to go to getting consistent error semantics in face of media
failures between the various file systems. I am not sure that we even
have consensus on what that default behavior
Gregory Maxwell wrote:
On 9/20/05, Theodore Ts'o [EMAIL PROTECTED] wrote:
There is a very interesting paper that I coincidentally just came
across today that talks about making filesystems robust against
various different forms of failures of modern disk systems. It is
going to be presented
Ric Wheeler wrote:
Hans Reiser wrote:
Ric Wheeler wrote:
As an earlier thread on lkml showed this summer, we still have a long
way to go to getting consistent error semantics in face of media
failures between the various file systems. I am not sure that we even
have consensus on what
On 9/20/05, Hans Reiser [EMAIL PROTECTED] wrote:
I am not a big fan of formal committees, but would be happy to take
part in any effort to standardize, code and test the result...
The committee could simply exchange a set of emails, and agree on
things. I doubt it needs to get all
[EMAIL PROTECTED] wrote:
Hans, unfortunately the most obvious reading of the above is
Reiser4 is so damned fast because it doesn't bother doing
sanity-checking.
Hmm, you seem to have forgotten the Hellwig complaints about too many
assertions. ;-)
Algorithms make a difference Valdis,
Hello
Christoph Hellwig wrote:
I threw in your new codedrop into a compilation and the byte-order
mess is _still_ now sorted out.
Did compiling notice this mess?
We used to compile with C=1. Should we compile somehow else before sending code
out?
Please kill the d* as struct type
crap
On Mon, Sep 19, 2005 at 01:18:58PM +0400, Vladimir V. Saveliev wrote:
Hello
Christoph Hellwig wrote:
I threw in your new codedrop into a compilation and the byte-order
mess is _still_ now sorted out.
Did compiling notice this mess?
We used to compile with C=1. Should we compile
On Mon, Sep 19, 2005 at 01:18:58PM +0400, Vladimir V. Saveliev wrote:
Christoph Hellwig wrote:
I threw in your new codedrop into a compilation and the byte-order
mess is _still_ now sorted out.
Did compiling notice this mess?
We used to compile with C=1. Should we compile somehow else
On Sul, 2005-09-18 at 22:07 -0700, Hans Reiser wrote:
the ability to fix some of those bugs fast, but we also all remember
what happened with reiser3 later on despite early fast fixing.
What was that?
Jeff Mahoney added file attributes to reiserfs3, you whined and pointed
people at the
On Sul, 2005-09-18 at 22:44 -0700, Hans Reiser wrote:
We are supposed to write a filesystem so that overheating CPUs do not
make it crash?
The reverse - and before you lose data.
I think Alan Cox is the only poster who has no intention of using
Reiser4 but said at one point that he thinks it
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 avoid using #if/#endif:
#if
Hans Reiser writes:
[...]
Well maybe he should just go away then and save his and our time.
Reiser4 works just fine without Christoph. Users are happy with it.
None of them have asked for his help. I don't consider Christoph to be
qualified to work on our filesystem. I would not
On Sun, Sep 18 2005, Hans Reiser wrote:
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 elevator code for instance. Ugh.
That's pretty bold, coming from someone who cannot even figure out how
Alan Cox wrote:
On Sul, 2005-09-18 at 22:07 -0700, Hans Reiser wrote:
the ability to fix some of those bugs fast, but we also all remember
what happened with reiser3 later on despite early fast fixing.
What was that?
Jeff Mahoney added file attributes to reiserfs3, you
Alan Cox wrote:
Perhaps you do. The kernel follows a coding style. It isn't my coding
style but like everyone else except you I try and follow it.
I also don't care enough about coding style issues to resist them.;-)
We have conformed to the coding style issues that were pointed out, and
as
One way in which half-OS was superior to DOS was how spectacularly the
former project failed after a lot of hype. :-)
OS/2 was technically superior to windows 95. The only failure was the
marketing/herd movement issues. I used OS/2, it was better.
On 9/18/05, Nikita Danilov [EMAIL PROTECTED] wrote:
Denis Vlasenko writes:
On Friday 16 September 2005 20:05, Hans Reiser wrote:
You can declare functions even if you never use them.
Thus here you can avoid using #if/#endif:
It's other way around: declaration is guarded by the
Denis Vlasenko wrote:
On Sunday 18 September 2005 03:34, Chris White wrote:
CC-List trimmed
On Saturday 17 September 2005 20:15, Denis Vlasenko wrote:
At least reiser4 is smaller. IIRC xfs is older than reiser4 and had more
time to optimize code size, but:
reiser42557872 bytes
xfs
Hello,
On Friday 16 September 2005 21:40, Christoph Hellwig wrote:
more trivial review comments ontop of the previous one, after looking
at things:
- please never use list_for_each in new code but list_for_each_entry
- never use kernel_thread in new code but kthread_*
done. thanks
Stephen Pollei writes:
On 9/18/05, Nikita Danilov [EMAIL PROTECTED] wrote:
Denis Vlasenko writes:
On Friday 16 September 2005 20:05, Hans Reiser wrote:
You can declare functions even if you never use them.
Thus here you can avoid using #if/#endif:
It's other way around:
Maybe, but kernel developers are supposed to watch for compiler
messages. People who use that technique definitely do.
You are making no sense. If the function isn't defined, it will break at
link time or depmod time instead of compile time, big deal... get rid of
those useless #ifdef's
Bill Davidsen wrote:
Denis Vlasenko wrote:
Maybe xfs shouldn't be accepted too, this may be an answer.
That argument is specious, and raises the chance that someone will
suggest that we learn from our mistakes.
It wasn't a mistake to accept xfs, xfs is a great piece of technology.
I
Nikita Danilov wrote:
It's enough to monitor your own code, rather than the whole kernel.
To this I would add, the kernel should not have warnings when it
compiles. Now THAT is a style requirement I would rigorously enforce if
I could. I deeply regret that long ago there was a Linux scsi
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 reviewing hans code is probably
at the
On 9/18/05, Kyle Moffett [EMAIL PROTECTED] wrote:
On Sep 18, 2005, at 13:22:27, michael chang 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
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 if it
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 znode_is_loaded() outside of
the debugging mode.
Since when has a missing declaration
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 elevator code for instance. Ugh.
What's wrong with the elevator
The longer I read discussions about the inclusion of reiser4 into the
kernel the more I think the whole discussion has to do with personal
oppinions, not with technical problems or limitations that should be
adressed.
Anybody who is a ext3 fan seems to find his own reasons why reaiser4
should stay
1 - 100 of 141 matches
Mail list logo
