From: Rob Landley <rob@landley.net>
To: "Theodore Ts'o" <tytso@mit.edu>,
LKML <linux-kernel@vger.kernel.org>,
rgetz@blackfin.uclinux.org, mpm@selenic.com
Subject: Re: feature-removal-schedule entry from 2009
Date: Sun, 15 Jul 2012 15:41:53 -0500 [thread overview]
Message-ID: <50032B11.7070505@landley.net> (raw)
In-Reply-To: <20120713030325.GB12245@thunk.org>
On 07/12/2012 10:03 PM, Theodore Ts'o wrote:
> On Wed, Jul 11, 2012 at 11:15:20AM -0500, Rob Landley wrote:
>> There are 12 remaining uses under drivers/ and 14 more under arch/, the
>> rest of the hits look like infrastructure implementing it.
>>
>> Should I run those files through bother-maintainer.pl and try to get
>> people to stop it, or is there a plan underway I don't know about?
>
> I was going to deal with that in the new /dev/random tree; once those
> changes go in, IRQF_SAMPLE_RANDOM effectively becomes a no-op. But
> I'd prefer that the ordering be that we get the new
> sample_interrupt_randomness() changes in first, and then remove the
> IRQF_SAMPLE_RANDOM.
Does it become a "please add a call to sample_interrupt_randomness()"
reminder, or will the infrastructure figure out when to do that outside
the driver?
And will this upcoming patch set remove 'em, or leave the NOP debris there?
> I've just been slammed with work,
I know the feeling. At my day job we work with such a "will never see
the light of day" kernel that my open source stuff is strictly
recreational, hence catching up with email on the weekend...
(How this can be license compliant: start with an obsolete version
recently _upgraded_ to 2.6.37, then the android fork off of that, then
the TI fork off of android, then our local fork off of TI. I'm sure the
hardware we eventually ship will get a technically compliant
corresponding source tarball snapshot sans repository history posted
_somewhere_, but nobody will ever care.)
> processing patches for the ext4
> merge window, and kernel summit planning, and quite frankly, I
> considered this to be relatively low priority --- especially since we
> no shortage of IRQF_* flag bits, and once the new
> sample_interrupt_randomness() goes in, the flag is a complete no-op.
Sure, I'm just bussing tables and asking "you done with that". I only
poke 'cuz it's been 3 years.
> - Ted
Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
next prev parent reply other threads:[~2012-07-16 3:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-11 16:15 feature-removal-schedule entry from 2009 Rob Landley
2012-07-13 3:03 ` Theodore Ts'o
2012-07-15 20:41 ` Rob Landley [this message]
2012-07-16 15:21 ` Theodore Ts'o
2012-07-17 17:19 ` [uml-devel] " Rob Landley
2012-07-17 21:29 ` Theodore Ts'o
2012-07-17 22:29 ` Richard Weinberger
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=50032B11.7070505@landley.net \
--to=rob@landley.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=rgetz@blackfin.uclinux.org \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.