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
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
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 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", i
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
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 wor
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 ne
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.
Theodore Ts'o wrote:
>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
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
n
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
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 forw
Pekka Enberg wrote:
>
>
>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_has
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 do
On Thu, 23 Jun 2005 14:37:05 -0400, Jeff Mahoney <[EMAIL PROTECTED]> said:
> As someone who spends time debugging reiser3 issues, I've grown
> accustomed to the named assertions. They make discussing a particular
> assertion much more natural in conversation than file:line. It also
> makes difficu
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 und
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 rout
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
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
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 the named as
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 /* po
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 d
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_
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
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;
>
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
> >>+rei
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
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 the assertions. I refe
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 K
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
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.
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:
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 go
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
hund
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
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
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
37 matches
Mail list logo