On Mon, Jan 07, 2013 at 20:11 -0800, Casey Schaufler wrote: > On 1/7/2013 7:59 PM, Stephen Rothwell wrote: > > You probably also want to think a bit harder about the order of the > > patches - you should introduce new APIs before you use them and remove > > calls to functions before you remove the functions. > > > The unfortunate reality is that I couldn't find a good way to stage the > changes. It's a wonking big set of infrastructure change. I could introduce > the security blob abstraction separately but that is a fraction of the > change. If it would have gone through mail filters as a single patch I'd > have sent it that way. > > I can spend time on patch presentation, and will if necessary.
I guess it can be divided this way: 1) Introduce lsm_get_cred(), etc. which unconditionally return ->security, ->i_security, etc. 2) Move all LSMs, procfs, etc. to the new API, a patch per LSM/subsystem. 3) Change structures along with new API. The pro of the division is that if you have a bug in the series (and you surely have! ;)) it is MUCH more simple to locate this bug (bisect, etc.). Also it is more descriptive as you divide LSM changes and the core security subsystem itself targeted on multiple LSMs which divides LSM implementations (which might be not very important for someone) and the core architecture (which is important for everybody). Thanks, -- Vasily Kulikov http://www.openwall.com - bringing security into open computing environments -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
