Arnd Bergmann writes:
> On Sun, Nov 8, 2020 at 12:21 PM Kalle Valo wrote:
>> Jakub Kicinski writes:
>>
>> So I don't know what to do. Should we try adding a warning like below? :)
>>
>> "This ancient driver will be removed from the kernel in 2022, but if
>>it still works send report to <.
On Sun, Nov 8, 2020 at 12:21 PM Kalle Valo wrote:
> Jakub Kicinski writes:
>
> So I don't know what to do. Should we try adding a warning like below? :)
>
> "This ancient driver will be removed from the kernel in 2022, but if
>it still works send report to <...@...> to avoid the removal."
>
Jakub Kicinski writes:
>> For the wireless drivers, removing the old drivers
>> instead of just the dead code might be an alternative, depending
>> on whether anyone thinks there might still be users.
>
> Dunno if you want to dig into removal with a series like this,
> anything using ioctls will
On Sun, Nov 8, 2020 at 1:06 AM Jakub Kicinski wrote:
>
> On Fri, 6 Nov 2020 23:17:15 +0100 Arnd Bergmann wrote:
> > Any suggestions on how to proceed? I think the ndo_siocdevprivate
> > change is the most interesting here, and I would like to get
> > that merged.
>
> Splitting out / eliminating i
On Fri, 6 Nov 2020 23:17:15 +0100 Arnd Bergmann wrote:
> Any suggestions on how to proceed? I think the ndo_siocdevprivate
> change is the most interesting here, and I would like to get
> that merged.
Splitting out / eliminating ioctl pass-thry in general seems like
a nice clean up. How did you
From: Arnd Bergmann
This series is some fallout from the series I sent earlier today to get
rid of compat_alloc_user_space() and copy_in_user().
I wanted to be sure I address all the ways that 'struct ifreq' is used
in device drivers through .ndo_do_ioctl, originally to prove that
my approach of
