Messages in this thread | | | Date | Thu, 4 Mar 2010 03:48:38 +0100 | From | Ingo Molnar <> | Subject | Re: linux-next requirements |
| |
* Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, 3 Mar 2010, Andrew Morton wrote: > > > On Thu, 4 Mar 2010 01:35:43 +0100 (CET) Thomas Gleixner <tglx@linutronix.de> wrote: > > > > > As a side note: We created checkpatch.pl, to have a tool which helps > > > us to alert developers about stuff which is deprecated and as a > > > byproduct the coding style rules. I think it's a useful tool in > > > general, just the outcome is an utter trainwreck: > > > > > > We have hordes of whitespace, spelling and codingstyle cleanup > > > maniacs, while the hard stuff of replacing deprecated interfaces like > > > semaphore based mutexes / completions, cleaning up the BKL horror, > > > etc. is left to a few already overworked people who care. > > > > > > What's even worse is it that developers of new code and the > > > maintainers who are merging it simply ignore its existance for > > > whatever reasons. I can accept the whitespace argument, but I have no > > > grasp why deprecation warnings are ignored at will. > > > > um, write checkpatch rules to detect new additions of deprecated features. > > > > I take patches. > > Guess what ? There are rules already which warn about init_MUTEX, > init_MUTEX_locked for quite a while and that's why I'm ranting at both > developers and maintainers submitting resp. merging code containing > exactly that shit. > > But yeah we do not have one for lock/unlock_kernel, will send one.
That's a good idea i think.
We should probably also rename ->ioctl to ->ioctl_legacy and have ->unlocked_ioctl as the primary thing for new drivers to use.
Ingo
| |