[Crash-utility] [PATCH v2] Remove the VOID_PTR facilitator macro

Petr Tesarik ptesarik at suse.cz
Wed Feb 2 11:56:36 UTC 2011


Dne pátek 28 Leden 2011 22:10:23 Dave Anderson napsal(a):
> ----- Original Message -----
> 
> > ----- Original Message -----
> > 
> > > I've been wondering about the intended use of this facilitator macro
> > > for some time and concluded that it is plainly wrong. It should
> > > take a pointer value from a buffer, but what is the use of a pointer
> > > that pointed to something on the target machine?
> > > 
> > > Since it cannot be meaningfully dereferenced on the host, the only
> > > (arguable) advantage is the ability to do pointer arithmetics on the
> > > variables. This second patch does the correct thing wherever pointer
> > > arithmetics was done, making the actual calculations more explicit.
> > > 
> > > Signed-off-by: Petr Tesarik <ptesarik at suse.cz>
> > 
> > Everything *looks* correct -- but this patch doesn't fix anything, while
> > having the capacity to break what works. The slab-related changes still
> > concern me, at least until I test them.
> 
> As it turns out, I can't even test the slab changes, because I don't have
> any more sample dumpfiles that go that far back to "pre-percpu" days.  That
> being the case, I'm not going to change the parts that modify dump_slab(),
> dump_slab_objects() and gather_slab_free_list().  Why bother?  It's
> essentially dead code, but if there are still any users of it out there,
> I'm not going to risk breaking it on them.
> 
> So I'm afraid it's going to continue to offend your sensibilities -- sorry
> about that...

Hi Dave,

no need to be sorry. It's the same as Rik van Riel's Turtle and the Hare (see 
http://surriel.com/system/files/summit2009-riel-turtle-and-hare.pdf). It's a 
pleasure to work with you, because you've always been consistent in your 
position. You're the turtle, I'm the hare. Occasionally, we can share some 
bits, but I don't expect you to take my patches.

In fact, I'm more than happy with your conservative approach, because I'm 
working for L3 Support here at SUSE, and we use the crash utility on a daily 
basis. The low rate of regressions makes it possible to use the latest and 
greatest version in production. That's unlike many other packages...

On the other hand, the distinction between a bugfix and a feature is a matter 
of judgement, sometimes. You describe support for newer kernels as a bugfix 
("fix for ... not working in Linux 2.6.x and later kernels"), but such things 
would qualify as a feature request rather than a bug report at SUSE. The crash 
utility had never worked with that new kernel.

And, in fact, my motivation to make a cross-platform crash is a perceived 
regression by our partners. They're not so much interested in packages (and 
code bases) as in the _functionality_ provided by those packages. So, they're 
comparing crash with lcrash, which is cross-platform.

Regards,
Petr Tesarik




More information about the Crash-utility mailing list