Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 23 Jan 2017 08:52:00 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Greg KH <gregkh@...uxfoundation.org>
CC: "keescook@...omium.org" <keescook@...omium.org>,
	"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
	"arnd@...db.de" <arnd@...db.de>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>, "Anvin, H Peter"
	<h.peter.anvin@...el.com>, "peterz@...radead.org" <peterz@...radead.org>,
	"will.deacon@....com" <will.deacon@....com>, "dwindsor@...il.com"
	<dwindsor@...il.com>
Subject: RE: [RFCv2 PATCH 00/18] refcount_t API + usage

> -----Original Message-----
> From: Greg KH [mailto:gregkh@...uxfoundation.org]
> Sent: Monday, January 23, 2017 10:36 AM
> To: Reshetova, Elena <elena.reshetova@...el.com>
> Cc: keescook@...omium.org; kernel-hardening@...ts.openwall.com;
> arnd@...db.de; tglx@...utronix.de; mingo@...hat.com; Anvin, H Peter
> <h.peter.anvin@...el.com>; peterz@...radead.org; will.deacon@....com;
> dwindsor@...il.com
> Subject: Re: [RFCv2 PATCH 00/18] refcount_t API + usage
> 
> On Mon, Jan 23, 2017 at 07:52:17AM +0000, Reshetova, Elena wrote:
> > > Then comes the real work :)
> > >
> > > You will need to break up the remaining patches into "one-per-type" and
> > > start submitting them to the various submaintainers for inclusion.
> >
> > Could you please elaborate more on "one-per-type"? Sorry if the question is
> > too basic, but I could not find any proper explanations anywhere now.
> 
> One patch per atomic_t variable that you change to refcount_t.

Oh, I didn't understand you meant this granularity, yes now it is clear and actually pretty easy
to break down :)

> 
> > If I run get_maintainer.pl, it sometimes produces rather big list (like it was the
> > case with atomic changes for example) and for a big patch like for example
> networking
> > it might not be straightforward to determine how to break it up properly.
> 
> I doubt that you will have a "touch the whole network stack" patch if
> you break it up into one-per-variable, but I don't really know.  See
> what it looks like when you are done.
> 
> > If there any BKMs or generic heuristics that people use in this case?
> 
> "BKM"?  What's that

Sorry, I was thinking it is a general English-speakers acronym (Best Known Method). 

> 
> > Does it help to send it to a general subsystem maintainer and mailing list first
> > for a look and ask how they prefer it to be broken up?
> 
> Again, one per variable should be fine.  Then send all of the patches
> for a specific subsystem (i.e. wireless drivers) to that list and
> maintainer for the subsystem and individual driver authors.  I'm sure
> that others at Intel can help you out with this, it should be documented
> pretty well somewhere in your internal system :)

Sure, this makes sense: I was thinking we need to do smth more clever than this to minimize patches,
but this way it is clear.  

Thank you very much for explaining!

Best Regards,
Elena.

> 
> good luck!
> 
> greg k-h

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.