feature-removal-schedule entry from 2009

feature-removal-schedule entry from 2009

[Rob Landley]

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.

Re: feature-removal-schedule entry from 2009

[Theodore Ts'o]

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

Re: feature-removal-schedule entry from 2009

[Rob Landley]

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.

Re: feature-removal-schedule entry from 2009

[Theodore Ts'o]

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

Re: [uml-devel] feature-removal-schedule entry from 2009

[Rob Landley]

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

Re: [uml-devel] feature-removal-schedule entry from 2009

[Theodore Ts'o]

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

Re: [uml-devel] feature-removal-schedule entry from 2009

[Richard Weinberger]

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