Messages in this thread | | | Date | Tue, 4 Jul 2000 11:51:30 -0700 (PDT) | From | Chris Lattner <> | Subject | Re: [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 printk(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 so!].
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???
*sigh*
-Chris
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |