Johannes, > All in all I'm so much in favour of this cleanup patch (and even would > apprechiate more of these, especailly getting rid of all those > camelCase foo we have in the scsi hba drivers). > > Let's see how Martin and James deceide about it. I am thoroughly annoyed by all the legacy whitespace problems. I've been working on two different sd patch series over the holidays and both caused me no end of grief due to legacy formatting issues. I have had an unbreak-sd patch sitting in my queue for several years but never pulled the trigger on it. For the usual reasons. I'm not particularly worried about bisection. But fixing whitespace does make it harder on the distro backporting front (Very pleased that you have now inadvertently volunteered to deal with all the issues that may arise at SUSE from such a subsystem-wide cleanup :). Anyway. I'm OK with fixing up the core pieces since they are the ones that annoy me the most. But I'm not sure we should enforce cleanups on drivers without an ack from the relevant maintainer. And for the unmaintained legacy baggage, I'm just not sure it's worth the hassle to clean things up. Fixing the crufty old things gives an illusion of the driver being actively worked on. I'd rather see dead code being left as such. Gives us a good indication of when it's safe to drop. One thing I specifically don't want is to open the flood gates for drive-by whitespace patches. I have no interest in wasting cycles on that. I generally only take arbitrary 3rd party cleanups if a driver is actively maintained and the maintainer specifically acks the change. PS. I'll at least partially unbreak sd.c as part of the series I'll be posting shortly. -- Martin K. Petersen Oracle Linux Engineering
