[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1004261525410.3739@i5.linux-foundation.org>
Date: Mon, 26 Apr 2010 15:32:51 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Frederic Weisbecker <fweisbec@...il.com>
cc: David Miller <davem@...emloft.net>, Arnd Bergmann <arnd@...db.de>,
linux-kernel@...r.kernel.org, tglx@...utronix.de,
viro@...iv.linux.org.uk, jblunck@...e.de, mingo@...e.hu,
jkacur@...hat.com
Subject: Re: [GIT PULL v2] Preparation for BKL'ed ioctl removal
On Tue, 27 Apr 2010, Frederic Weisbecker wrote:
>
> I've queued it for the next merge window in
>
> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git
> bkl/ioctl
Btw, I hope you took the second version, that had the two additional fixes
from Arnd (and my expansion of his fix to au1550_ac97.c).
Looking at the arch code, I doubt there are any big architecture-specific
things. But there could easily be some other drivers like au1550_ac97.c
that only get enabled on certain architectures and missed the grepping for
some reason.
That said, because of Arnd's fix, I did end up grepping for
'file_operations' and old-style gcc initializers (ie "ioctl: xyz" rather
than the proper ".ioctl = xyz"), and the grep came up empty.
But it's possible that there's something hiding: with all of serial,
bluetooth, block drivers, sound, socket proto's and v4l2 each having their
own 'ioctl' pointers, it's not entirely trivial to grep for it all and be
sure..
So there might be one or two cases still hiding, but it looks unlikely.
And I'm almost certain that it definitely isn't more than just one or two.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists