All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Theodore Ts'o <tytso@mit.edu>,
	user-mode-linux-devel@lists.sourceforge.net, jdike@addtoit.com
Subject: Re: [uml-devel] feature-removal-schedule entry from 2009
Date: Tue, 17 Jul 2012 12:19:38 -0500	[thread overview]
Message-ID: <50059EAA.9080000@landley.net> (raw)
In-Reply-To: <20120716152140.GA27656@thunk.org>

That should be over on _this_ list then...

(Discussion of IRQF_SAMPLE_RANDOM removal.)

On 07/16/2012 10:21 AM, Theodore Ts'o wrote:
> On Sun, Jul 15, 2012 at 03:41:53PM -0500, Rob Landley wrote:
>> 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?
> 
> The patches in the random.git tree unconditionally call
> add_interrupt_randomness() in handle_irq_event_percpu(), so the
> drivers don't need to do anything at this point.
> 
>> And will this upcoming patch set remove 'em, or leave the NOP debris
>> there?
> 
> The current status is here:
> 
> http://git.kernel.org/?p=linux/kernel/git/tytso/random.git;a=summary
> 
> At this point the flag is a no-op, and can be removed.  This close to
> the merge window, I don't think I'm going to have time to create
> patches which remove the flag from all of the drivers, but it's
> basically clean up work, and having the extra bit set isn't going to
> harm anyone.
> 
> The only thing that might require a bit of care is the usage in
> arch/um, where someone needs to do a bit more analysis to see if it's
> just a matter of removing the flag from the call to request_irq().  My
> current thinking was to merge the new interrupt structure during this
> merge window, and then clean up the NOP debris during the next
> development cycle.
> 
> 						- 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.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel


  reply	other threads:[~2012-07-17 17:19 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
2012-07-16 15:21     ` Theodore Ts'o
2012-07-17 17:19       ` Rob Landley [this message]
2012-07-17 21:29         ` [uml-devel] " 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=50059EAA.9080000@landley.net \
    --to=rob@landley.net \
    --cc=jdike@addtoit.com \
    --cc=tytso@mit.edu \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /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.