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.