[lkml]   [2000]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH #2] console lock grabbed too early in printk...
> > 5. As such, a kernel developer may not invest as much thought into printk
> > placement as, say, a new buffer cache design.
> The rules:
> 1. Don't pass user addresses to printk

What makes an address a user address? When going through someone elses
code, sometimes you can tell when it gets copied in, sometimes not... and
should i have to do something like this everytime I want to printk?

{ char Buffer[1000];
copyinto buffer

??? Whoops, hope I don't overflow the stack!?!? :(

I think this is completely ridiculous. I'm asking to put one low
contention lock and unlock into the printk path. Printk is not called
very often except when "things are going wrong" or you are debugging... in
either case, don't you want it to be as forgiving as possible??

> With what I've said above, the kernel developer would have to be very
> dumb to put a printk in those places.

I'm starting to get annoyed at people who keep arguing that people don't
make mistakes, and when they do, they should get punished for it. That is
completely inappropriate crap. Maybe you are some macho experienced
kernel developer, but I would be willing to be that even Linux and Alan
make a mistake every once in a while... hell I bet they have to debug
stuff they write too [and they might even use printk on occasion to do

My point is that this doesn't cost much of anything, and it can save some
people a lot of pain. What is the big conceptual problem here???



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.071 / U:5.284 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site