On Mon, 9 Feb 2004, Jon Smirl wrote:
>
> There are lots of solutions to this:
> 1) queue the printk's
> 2) add an in-kernel path for write to console that cooperates with the normal
> user space one
> 3) if you know you are going to be debugging code like this, use an alternative
> solution like the serial port or a second video card running framebuffer.,
No.
There is one basic requirement: debugging is hard enough already, and
having to have two machines or two heads for debugging is NOT GOING TO EB
ACCEPTED! Not because of any technical problems per se, but because of
_people_ problems.
It's very simple: most problem reports are actually from people "in the
wild". There is a very good reason for why Linux tries to spew out a
minimal debug report: so that people can write it down, or take a snapshot
with a digital camera when things just stop.
Yes, many kernel bugs leave the kernel entirely functional. That's on
purpose: the more often we can get a nice oops and the user can just
cut-and-paste it from the error logs, the more often we're going to get a
good bug report.
However, quite a lot of the time, especially in multi-processor
environments, the bugs cause a totally hung machine. This is already a
huge problem under X, and this literally makes it tons harder to chase
down a problem that only happens with X is active, but happily most bugs
aren't that kind, and once you can trigger them, you can usually trigger
them on the console too.
Making the normal console not able to print out these bugs would be a HUGE
problem. To the point where such a solution just isn't appropriate. It
might be ok as a stand-alone project to explore the issues, but it
absolutely must not be a long-term goal.
And dual graphics adapters and/or serial cables are not an option. Because
that option just means that you will never ever get a bug-report from the
wild except for "it just stopped". Which is painful as hell.
> You can't see a kernel oops from an interrupt when running XWindows any way.
And this is a PROBLEM. How many times have DRM people cursed it? I bet it
is a concern that is pretty high up on the list of things that are painful
when doing kernel module development for DRM.
So instead of saying "this is already a problem under X, so it's not a big
deal, it just makes it even worse", a new console infrastructure should
say: "we know this is a problem, let's make sure we can fix it".
In other words, if we start doing more graphics support in the kernel,
let's make sure that the kernel can paint to some texture directly.
And yes, by all means make it an option to just queue the messages. That's
what syslogd is there for. But it should not be something that the design
forces on you.
Many other things can be done from user space, but not basic text
printing. Even then, they should at least have serialization support in
the kernel. For example, while you can likely do things like mode
switching _technically_ from user space, you'd likely need some kind of
kernel interfaces to at least have the user space tell the new tiling and
layout etc, so ...
Linus
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
