Hello, On Sun, 10 Jul 2016 15:15:19 -0700 John Nemeth <jnem...@cue.bc.ca> wrote:
> On Jul 10, 9:37pm, David Holland wrote: > } On Sat, Jul 09, 2016 at 08:45:15PM -0700, John Nemeth wrote: > } > } The substance of that reservation is that there's not much point doing > } > } it without also taking the time to correct the behavior, i.e., back > } > } out properly if something fails. And that requires attention, not just > } > } mechanical changes. > } > > } > Sure, but that's something that can be done over time, driver > } > by driver. The first step is the infrastructure support (changing > } > the return type, having autoconf respond intelligently, etc.). > } > The very first step of changing the return type is a purely mechanical > } > change. > } > } Well, yes, but if you change the return type mechanically first then > } you end up with a thousand or two attach functions that *look* like > } they handle errors but actually don't. > > Thanks for the reminder. I meant to add to my list of steps > that the xxx_attach() function needs to be flagged somehow (possibly > with a standardised comment) to show that it still needs to be > audited. The flag is something that needs to be easily found > mechanically so that lists can be made. > > Also, I expect that some drivers will never be audited/tested > since there are drivers for ancient hardware that very few people > now own/use. Of course, that might be a hint that the driver should > be retired (or, at least commented out in GENERIC). Maybe make that marker a cpp macro that can throw a warning/error/whatever controlled by a kernel config option. I'd like to fix all my drivers but I'd probably forget about half of them. have fun Michael