linux-kernel - Re: [RFC][PATCH] SCHED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Sep 2009 08:08:52 -0700
From:	Daniel Walker <dwalker@...o99.com>
To:	Avi Kivity <avi@...hat.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Jonathan Corbet <corbet@....net>,
	Raistlin <raistlin@...ux.it>,
	Peter Zijlstra <peterz@...radead.org>, claudio@...dence.eu.com,
	michael@...dence.eu.com, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, johan.eker@...csson.com, p.faure@...tech.ch,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	Dhaval Giani <dhaval.giani@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Tommaso Cucinotta <tommaso.cucinotta@...up.it>
Subject: Re: [RFC][PATCH] SCHED_EDF scheduling class

On Wed, 2009-09-23 at 17:58 +0300, Avi Kivity wrote:
> On 09/23/2009 05:50 PM, Daniel Walker wrote:
> > On Wed, 2009-09-23 at 14:25 +0200, Ingo Molnar wrote:
> >    
> >> * Avi Kivity<avi@...hat.com>  wrote:
> >>
> >>      
> >>>> discouraging contributions is more something that happens when you
> >>>> get the responses I got earlier in this thread..
> >>>>          
> >>> That's probably intentional.  Whitespace fixes have their place but
> >>> not at this stage in a patch's lifecycle.
> >>>        
> >> Exactly. What might make sense is to scan linux-next for new commits
> >> that show serious cleanliness trouble - and send fix patches to the
> >> parties involved. That's a real effort and brings the code forward.
> >>      
> > Often times when a patch is at youngest that when you want to catch
> > these issues .. This EDF patch will likely get submitted more than
> > twice. If you catch all the minor problems first you will not be dealing
> > with them later when it comes time to include the code.
> >    
> 
> Not true, you want to address the major issues first.  What's the point 
> of fixing whitespace if the whole approach is rejected? if it has to 
> undergo a rewrite? (not an opinion on EDF btw, just as an example)

I'm not sure why your fixated on whitespace , but thinking about it more
I don't think it matters .. If you fix whitespace or major issues first,
it doesn't matter .. All the issues have to eventually get fixed .. Not
to mentioned that LKML is not something you could remotely control in
that way.

> > In this case the author is not totally aware of how to submit this
> > code.. I don't think it's at all inappropriate to comment on that. His
> > next submission will likely be much cleaner and nicer. It may even speed
> > up the inclusion process since he'll be more easily able to submit the
> > code (with practice and comments from us).
> >    
> 
> Give people some credit.

What do you mean?

Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/