[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B41C417EE@IRSMSX102.ger.corp.intel.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
