On Thursday, August 24, 2006 05:16:00 PM -0400 chas williams - CONTRACTOR
<[EMAIL PROTECTED]> wrote:
In message <[EMAIL PROTECTED]>,Jeffrey
Hutzelman w rites:
There's nothing to fix. osi_Panic _does_ print out the message string,
but necessarily does so _before_ it calls BUG(). Which means that
users habitually don't actually copy the message when sending in a
report. Fixing this would require changes to Linux to allow something
calling BUG to include a message that gets included _below_ the "cut
here" line.
well could fix it by making BUG() do something else and actually point
out the line where the trouble occurred. so when we get these truncated
kernel panics (they are following the directions after all) we might
be able to do something with them. we arent going to be able to
change BUG() and we probably cant change all the users in the world.
you could also make osi_Panic() print "REALLY CUT FROM HERE" but that's
even sillier.
i am particularly awed by AFS_ASSERT_GLOCK(). i had never seen that
before.
Besides calling BUG() inline, which is a good thing, your code has the
effect of changing the behavior on 2.4 so that we call BUG() instead of
trying to dereference a NULL pointer. I'm pretty sure there's a reason we
haven't done that already, and I'd rather not make that change now unless
you can prove it works on every AFS_LINUX24_ENV kernel out there.
Also, your change to AFS_ASSERT_GLOCK() means that the macro now expands to
a statement instead of an expression, and a statement that might affect
flow control at that. Consider something like this:
if (should_have_glock)
AFS_ASSERT_GLOCK();
else
AFS_GLOCK();
Instead, I'd leave AFS_ASSERT_GLOCK() alone, and arrange for osi_Panic() to
also expand to an expression. Maybe something like
#define osi_Panic(msg...) (printk(KERN_CRIT "openafs: " msg), bug(), 0)
-- Jeff
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
