On Sat, Jun 25 2005, Pekka Enberg wrote:
Hi,
On Thu, 2005-06-23 at 21:32 +0200, Jens Axboe wrote:
then it's impossible to know which one it is without the identical
source at hand.
In which case, debugging is risky IMO (the source code could have
changed a lot).
That's not an
On Thu, 2005-06-23 at 21:32 +0200, Jens Axboe wrote:
That said, I don't like the reiser name-number style. If you must do
something like this, mark responsibility by using a named identifier
covering the layer in question instead.
assert(trace_hash-89, is_hashed(foo) !=
On Mon, 2005-06-27 at 09:28 +0200, Andi Kleen wrote:
You can just dump the expression (with #argument). That is what
traditional userspace assert did forever.
It won't help for BUG_ON(a || b || c || d || e) but these
are bad style anyways and should be avoided.
Sounds good to me. Jens,
On Mon, Jun 27, 2005 at 10:49:19AM +0300, Pekka J Enberg wrote:
On Mon, 2005-06-27 at 09:28 +0200, Andi Kleen wrote:
You can just dump the expression (with #argument). That is what
traditional userspace assert did forever.
It won't help for BUG_ON(a || b || c || d || e) but these
are
On Mon, 27 June 2005 10:49:19 +0300, Pekka J Enberg wrote:
#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (unlikely((condition)!=0)) BUG(); }
while(0)
+#define BUG_ON(condition) do { \
+ if (unlikely((condition) != 0)) { \
+ printk(kernel BUG '%s' at
Hubert Chan [EMAIL PROTECTED] writes:
On Sat, 25 Jun 2005 12:23:41 -0700, Hans Reiser [EMAIL PROTECTED] said:
assert(trace_hash-89, is_hashed(foo) != 0);
Lots of people like corporate anonymity. Some don't. I don't. I
like knowing who wrote what. ...
For what it's worth (I know: not
Hi,
On Thu, 2005-06-23 at 21:32 +0200, Jens Axboe wrote:
then it's impossible to know which one it is without the identical
source at hand.
In which case, debugging is risky IMO (the source code could have
changed a lot).
On Thu, 2005-06-23 at 21:32 +0200, Jens Axboe wrote:
That said, I
On Sat, Jun 25, 2005 at 12:23:41PM -0700, Hans Reiser wrote:
assert(trace_hash-89, is_hashed(foo) != 0);
Lots of people like corporate anonymity. Some don't. I don't. I like
knowing who wrote what. It helps me know who to pay how much. It helps
me know who to forward the bug
On Sat, 25 Jun 2005 12:23:41 -0700, Hans Reiser [EMAIL PROTECTED] said:
assert(trace_hash-89, is_hashed(foo) != 0);
Lots of people like corporate anonymity. Some don't. I don't. I
like knowing who wrote what. ...
For what it's worth (I know: not much), I like the named asserts in
Hubert Chan schrieb:
How about something of the form nikita-955(file:line)? Or the
reverse: file:line(nikita-955). Would that keep everyone happy?
Damn, I was wondering how long it would take until someone would come up
with a compromise solution ; ) Compromises everywhere will lead to
Christian Trefzer wrote:
Hubert Chan schrieb:
How about something of the form nikita-955(file:line)? Or the
reverse: file:line(nikita-955). Would that keep everyone happy?
Makes me happy.
Hans Reiser schrieb:
Christian Trefzer wrote:
Hubert Chan schrieb:
How about something of the form nikita-955(file:line)? Or the
reverse: file:line(nikita-955). Would that keep everyone happy?
Makes me happy.
Nice, how about the others?
Hey, if we need some objective and
Hi Hans,
On 6/22/05, Hans Reiser [EMAIL PROTECTED] wrote:
I would in particular love to have you Andi Kleen do a full review of V4
if you could be that generous with your time, as I liked much of the
advice you gave us on V3.
Well, I am not Andi Kleen and this is not even in the ballpark of a
Pekka Enberg wrote:
Hi Hans,
On 6/22/05, Hans Reiser [EMAIL PROTECTED] wrote:
I would in particular love to have you Andi Kleen do a full review of V4
if you could be that generous with your time, as I liked much of the
advice you gave us on V3.
Well, I am not Andi Kleen and this is
Pekka J Enberg wrote:
Hi Hans,
On Thu, 2005-06-23 at 00:42 -0700, Hans Reiser wrote:
These assertion codes are meaningless to the rest of us so please drop
them.
I think you don't appreciate the role of assertions in making code
easier to audit and debug.
I did not say you should drop
Hello
On Thu, 2005-06-23 at 11:42, Hans Reiser wrote:
Pekka Enberg wrote:
--- /dev/null 2003-09-23 21:59:22.0 +0400
+++ linux-2.6.11-vs/fs/reiser4/pool.c 2005-06-03 17:49:38.668204642
+0400
+/* initialise new pool */
+reiser4_internal void
On Thu, Jun 23, 2005 at 08:15:03PM +0400, Vladimir Saveliev wrote:
Pekka, would you prefer something like:
reiser4_fill_super()
{
if (init_a() == 0) {
if (init_b() == 0) {
if (init_c() == 0) {
if (init_last() == 0)
return 0;
Vladimir Saveliev wrote:
+/*
+ * Initialization stages for reiser4.
+ *
+ * These enumerate various things that have to be done during reiser4
+ * startup. Initialization code (init_reiser4()) keeps track of what stage
was
+ * reached, so that proper undo can be done if error occurs during
+
Pekka Enberg wrote:
--- /dev/null 2003-09-23 21:59:22.0 +0400
+++ linux-2.6.11-vs/fs/reiser4/pool.c 2005-06-03 17:49:38.668204642 +0400
+/* initialise new pool */
+reiser4_internal void
+reiser4_init_pool(reiser4_pool * pool /* pool to initialise */ ,
+ size_t obj_size /*
Jeff Mahoney [EMAIL PROTECTED] wrote:
+ assert(nikita-955, pool != NULL);
These assertion codes are meaningless to the rest of us so please drop
them.
As someone who spends time debugging reiser3 issues, I've grown
accustomed to the named assertions. They make discussing a
Jeff Mahoney wrote:
Pekka Enberg wrote:
--- /dev/null2003-09-23 21:59:22.0 +0400
+++ linux-2.6.11-vs/fs/reiser4/pool.c2005-06-03 17:49:38.668204642
+0400
+/* initialise new pool */
+reiser4_internal void
+reiser4_init_pool(reiser4_pool * pool /* pool to initialise */
On Thu, Jun 23 2005, Andrew Morton wrote:
Jeff Mahoney [EMAIL PROTECTED] wrote:
+ assert(nikita-955, pool != NULL);
These assertion codes are meaningless to the rest of us so please drop
them.
As someone who spends time debugging reiser3 issues, I've grown
accustomed to
Jeff Mahoney wrote:
All the assertions (a quick grep through the code shows something like
3800 of them) ultimately result in a reiser4_panic, which BUG()'s. Are
*all* of these assertions really worth taking the system down? I think a
reiser4_error function that can abort just that filesystem and
On 6/23/05, Olivier Galibert [EMAIL PROTECTED] wrote:
No, I think he means the traditional:
reiser4_fill_super()
{
if (init_a())
goto failed_a;
.
.
.
IMO this works very well when the initialization always completes or
fails totally in a single routine. When your init routine can
Hans Reiser writes:
[...]
I think the above is easier to read than the below. Macros can obscure
sometimes, and one of our weaknesses is a tendency to use macros in such
a way that it frustrates meta-. use in emacs. Nikita did however
mention that there was something that could
Jeff Garzik wrote:
Hans' team says its good stuff is not a criteria for merging.
Try benchmarking it. Maybe benchmarks mean more than our
chattering. at least to the users.
Hans Reiser wrote:
Jeff Garzik wrote:
Hans' team says its good stuff is not a criteria for merging.
Try benchmarking it. Maybe benchmarks mean more than our
chattering. at least to the users.
Still not a criteria for merging.
We have to care about the code behind the benchmarks.
Andi Kleen wrote:
On Tue, Jun 21, 2005 at 11:44:55AM -0700, Hans Reiser wrote:
vs and zam, please comment on what we get from our profiler and spinlock
debugger that the standard tools don't supply. I am sure you have a
reason, but now is the time to articulate it.
We would like to keep the
Hans Reiser wrote:
V4 has a mailing list, and a large number of testers who read the code
and comment on it. V4 has been reviewed and tested much more than V3
was before merging. Given that we sent it in quite some time ago, your
suggestion that an additional review by unspecified additional
On Tue, Jun 21, 2005 at 06:38:07PM -0700, Hans Reiser wrote:
V4 has a mailing list, and a large number of testers who read the code
and comment on it. V4 has been reviewed and tested much more than V3
was before merging. Given that we sent it in quite some time ago, your
suggestion that an
Andi Kleen wrote:
Just there are doubts that your
code follows the Linux coding standards enough to not be a undue
mainteance burden in mainline.
We get only a few bugfixes from outsiders, and the rest are done by us.
The customers who buy licenses in addition to the GPL from us for
hundreds
Hans Reiser wrote:
I like feedback on our code, and I particularly like feedback from a Mr.
Andi Kleen, but there is no need to tie it to merging. If, however, it
serves as an effective excuse to get some of your time allocated by SuSE
management, sure, go for it.;-)
All merges of new code
32 matches
Mail list logo
