* feature-removal-schedule entry from 2009
@ 2012-07-11 16:15 Rob Landley
2012-07-13 3:03 ` Theodore Ts'o
0 siblings, 1 reply; 7+ messages in thread
From: Rob Landley @ 2012-07-11 16:15 UTC (permalink / raw)
To: LKML, rgetz, mpm
IRQF_SAMPLE_RANDOM is 3 years past its sell-by date in
feature-removal-schedule:
What: IRQF_SAMPLE_RANDOM
Check: IRQF_SAMPLE_RANDOM
When: July 2009
Why: Many of IRQF_SAMPLE_RANDOM users are technically bogus as
entropy sources in the kernel's current entropy model. To
resolve this, every input point to the kernel's entropy pool
needs to better document the type of entropy source it actually
is. This will be replaced with additional add_*_randomness
functions in drivers/char/random.c
Who: Robin Getz <rgetz@blackfin.uclinux.org>
& Matt Mackall <mpm@selenic.com>
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?
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: feature-removal-schedule entry from 2009 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 0 siblings, 1 reply; 7+ messages in thread From: Theodore Ts'o @ 2012-07-13 3:03 UTC (permalink / raw) To: Rob Landley; +Cc: LKML, rgetz, mpm On Wed, Jul 11, 2012 at 11:15:20AM -0500, Rob Landley wrote: > IRQF_SAMPLE_RANDOM is 3 years past its sell-by date in > feature-removal-schedule: > > What: IRQF_SAMPLE_RANDOM > Check: IRQF_SAMPLE_RANDOM > When: July 2009 > > Why: Many of IRQF_SAMPLE_RANDOM users are technically bogus as > entropy sources in the kernel's current entropy model. To > resolve this, every input point to the kernel's entropy pool > needs to better document the type of entropy source it actually > is. This will be replaced with additional add_*_randomness > functions in drivers/char/random.c > > Who: Robin Getz <rgetz@blackfin.uclinux.org> > & Matt Mackall <mpm@selenic.com> > > 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. I've just been slammed with work, 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. - Ted ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: feature-removal-schedule entry from 2009 2012-07-13 3:03 ` Theodore Ts'o @ 2012-07-15 20:41 ` Rob Landley 2012-07-16 15:21 ` Theodore Ts'o 0 siblings, 1 reply; 7+ messages in thread From: Rob Landley @ 2012-07-15 20:41 UTC (permalink / raw) To: Theodore Ts'o, LKML, rgetz, mpm 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: feature-removal-schedule entry from 2009 2012-07-15 20:41 ` Rob Landley @ 2012-07-16 15:21 ` Theodore Ts'o 2012-07-17 17:19 ` [uml-devel] " Rob Landley 0 siblings, 1 reply; 7+ messages in thread From: Theodore Ts'o @ 2012-07-16 15:21 UTC (permalink / raw) To: Rob Landley; +Cc: LKML, rgetz, mpm 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [uml-devel] feature-removal-schedule entry from 2009 2012-07-16 15:21 ` Theodore Ts'o @ 2012-07-17 17:19 ` Rob Landley 2012-07-17 21:29 ` Theodore Ts'o 0 siblings, 1 reply; 7+ messages in thread From: Rob Landley @ 2012-07-17 17:19 UTC (permalink / raw) To: Theodore Ts'o, user-mode-linux-devel, jdike 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [uml-devel] feature-removal-schedule entry from 2009 2012-07-17 17:19 ` [uml-devel] " Rob Landley @ 2012-07-17 21:29 ` Theodore Ts'o 2012-07-17 22:29 ` Richard Weinberger 0 siblings, 1 reply; 7+ messages in thread From: Theodore Ts'o @ 2012-07-17 21:29 UTC (permalink / raw) To: Rob Landley; +Cc: jdike, user-mode-linux-devel On Tue, Jul 17, 2012 at 12:19:38PM -0500, Rob Landley wrote: > That should be over on _this_ list then... > > (Discussion of IRQF_SAMPLE_RANDOM removal.) I took a closer look at the arch/um code, and it wasn't as hard as I thought. I have a proposed set of patches to completely remove IRQF_SAMPLE_RANDOM that I will be sending out shortly.... - Ted ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [uml-devel] feature-removal-schedule entry from 2009 2012-07-17 21:29 ` Theodore Ts'o @ 2012-07-17 22:29 ` Richard Weinberger 0 siblings, 0 replies; 7+ messages in thread From: Richard Weinberger @ 2012-07-17 22:29 UTC (permalink / raw) To: Theodore Ts'o, user-mode-linux-devel; +Cc: jdike, Rob Landley Am Tue, 17 Jul 2012 17:29:46 -0400 schrieb Theodore Ts'o <tytso@mit.edu>: > On Tue, Jul 17, 2012 at 12:19:38PM -0500, Rob Landley wrote: > > That should be over on _this_ list then... > > > > (Discussion of IRQF_SAMPLE_RANDOM removal.) > > I took a closer look at the arch/um code, and it wasn't as hard as I > thought. I have a proposed set of patches to completely remove > IRQF_SAMPLE_RANDOM that I will be sending out shortly.... > I'll happily test them, please CC me. BTW: On UML we have anyway CONFIG_UML_RANDOM to get good random numbers. It reads from thes host's /dev/random. Thanks, //richard ------------------------------------------------------------------------------ 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-07-17 22:30 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 ` [uml-devel] " Rob Landley 2012-07-17 21:29 ` Theodore Ts'o 2012-07-17 22:29 ` Richard Weinberger
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.