The same red herring as always.
The same red herring as always.
Posted Jul 17, 2013 23:16 UTC (Wed) by tao (subscriber, #17563)In reply to: The same red herring as always. by HelloWorld
Parent article: On kernel mailing list behavior
If he'd written something along the lines of "Ok, what kind of ass-hat idiot wrote this thing?" it would have been abusive though.
I don't mind having my work criticized as long as it's justified. And for Linus to use such words the critique probably is... What I do mind is people calling me stupid if I'd do a bad job (though if I'd keep doing the same kind of bad job over and over it'd be nice to be told that maybe I should look for a different project to work on).
And at least in my case a harsh reaction against shitty code is far more effective to get my attention than something like "This code isn't what I'd expect", "I won't pull this", or similar.
In my opinion the lack of explanation of *why* something is crap is the big problem here, not the use of harsh language. Telling someone that they're doing it wrong, but not telling them what the right way is usually quite unhelpful, unless there's only one other way it could be done or if the proper way of doing things is already documented and part of things that you're expected to have read before submitting code.
So, for instance something like "The coding style here is fucked up beyond repair, go fix!" is enough (since there's a CodingStyle document that everyone who writes kernel code is expected to follow), but "This code is a total clusterfuck, I won't pull this" isn't, since it doesn't convey *why* the code sucks.
Posted Jul 18, 2013 6:00 UTC (Thu)
by khim (subscriber, #9252)
[Link]
This is latter case. If you want to write driver for the hardware then you need to know how said hardware works. And in today's world of level-triggered IRQs devices must be explicitly silenced in IRQ handler before interrupts are enabled again. The code in question violates this fundamental principle. Worse: there are no way to write said code without violating this principle. I don't even know what to compare it to... well, I think "you are supposed to not just hang up wheel on the axis, it must be fastened up with screws, too, or lives will be in danger". Only here screws are not just not attached - bolts are used for fancy ribbons which means that can not ever fasten these screws and make car safe again! I remember how my brother-in-law talked to guys who did that after minor fix in his car - Linus message looked nice in comparison. And I fully understand why: car which loses it's wheels on the highway because someone "honestly forgot" to use screws is not something which should ever happen. Dead machine is less of a problem then dead person I guess which explains why Linus used relatively mild curses here. What lack of details? Linus explained quite well why such design can not be ever implemented correctly. Note: problem here is not even code of this concrete function, but with the fact that offered design requires such function - which in turn guarantees that there will be deadlocks on some systems.
The same red herring as always.
Telling someone that they're doing it wrong, but not telling them what the right way is usually quite unhelpful, unless there's only one other way it could be done or if the proper way of doing things is already documented and part of things that you're expected to have read before submitting code.
In my opinion the lack of explanation of *why* something is crap is the big problem here.