public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Bowler <nbowler@elliptictech.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/4] BKL: move CONFIG_BKL to staging
Date: Wed, 19 Jan 2011 13:21:42 -0500	[thread overview]
Message-ID: <20110119182142.GA3620@elliptictech.com> (raw)
In-Reply-To: <201101191717.58277.arnd@arndb.de>

On 2011-01-19 17:17 +0100, Arnd Bergmann wrote:
> On Wednesday 19 January 2011, Nick Bowler wrote:
> > I think this patch is not very nice.  It will cause working kernel
> > configurations to turn into broken kernel configurations when the user
> > does 'make oldconfig', with no warning.
> > 
> > These drivers that use the BKL work fine.  Removing working features
> > with no adequate replacement available seems like a serious regression
> > to me.
> 
> I wouldn't call it a serious regression since the code is still there
> and both the symptom and the solution are rather obvious.

Well, the code wouldn't still be there if they're removed in 2.6.39 as
stated in your patch description.  While it may be obvious to people
like you and me who know what the BKL is, I don't it's obvious to
everyone that the cause of "my system doesn't boot anymore" is "oh,
someone moved a dependency of a driver I've been using without issue for
the past 5 years to staging!"

> What's more important is to make any people still relying on the code
> aware that it's going away unless someone fixes it, so they have the
> chance to send patches or pay someone to fix it for them.

Shouldn't the onus for fixing *working* drivers (or encouraging others
to fix them) lie with the person(s) who are so keen to kill off features
that they use?

Surely we don't need to break oldconfig just to raise awareness that
these drivers use deprecated features?

> The remaining drivers that are still relying on the BKL are very
> rarely used and for the less obscure ones (ufs, ipx and x.25), people
> have volunteered to fix them (though I have seen no proper patches
> for these yet).
>
> For the rest, I suppose if nobody complains, they can actually go
> away, according to the logic that if nobody is using them, they most
> likely are broken anyway and more a security risk than they are worth.

Notwithstanding any of the above, one release cycle hardly seems like
enough time to infer from "nobody complained" that "not a single person
uses this driver."  Surely people concerned with security issues in code
that they don't use can just... not enable it?  Nobody's forcing anyone
to use these drivers.

Neither the BKL nor any of these drivers are even mentioned in the
feature removal schedule yet.

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

  reply	other threads:[~2011-01-19 18:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-18 21:16 [PATCH 0/4] Phasing out the BKL Arnd Bergmann
2011-01-18 21:16 ` [PATCH 1/4] drm/i810: remove " Arnd Bergmann
2011-01-18 21:17 ` [PATCH 2/4] BKL: disable by default Arnd Bergmann
2011-01-18 21:17 ` [PATCH 3/4] BKL: mark lock_kernel as deprecated Arnd Bergmann
2011-01-18 21:17 ` [PATCH 4/4] BKL: move CONFIG_BKL to staging Arnd Bergmann
2011-01-19 15:44   ` Nick Bowler
2011-01-19 16:17     ` Arnd Bergmann
2011-01-19 18:21       ` Nick Bowler [this message]
2011-01-23 22:19         ` Andrew Hendry
     [not found]         ` <AANLkTimOzU328aHnB7+ERSq1ovPBSZgxNQsYRhLghH5L@mail.gmail.com>
2011-01-24 15:59           ` Arnd Bergmann
2011-01-25  0:33             ` Andrew Hendry
2011-01-25 12:06               ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110119182142.GA3620@elliptictech.com \
    --to=nbowler@elliptictech.com \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox