On Sat, Sep 01, 2001 at 07:25:03PM -0400, jmjonesat_private wrote: > > I had not thought this was the "policy", at this point, but rather had > believed that SGI was reviewing "some authoritative" and had responded > positively to a limitted application. > > If it's a complete "NO", I will procede forward based on that. Come on people. We went over this months ago. I was very surprised to see it come up again at the BOF meeting, which I interpreted as Crispin of WireX giving SGI the benefit of the doubt. Since neither of them have really talked about it since then on the list, I don't see any reason why we would change the proposed plan that I thought we had all agreed upon. > I'd think that a mechanism to init blobs reliably without conflict would > be a consideration if this support was to be applied. I admit I haven't > looked "very closely" at the patch with this regard... our prototypes > assume that a NULL is an un-allocated blob and don't deal with locking. That's a good assumption to make :) But you really should consider locking things when modifying them if another processor could be modifying them at that same moment also (like within your same function.) > We DID see locking as a consdir-able issue and hoped it would get more > discussion. I'd be glad to talk about it if anyone has any questions. Locking problems are something that I like to mess with. There are lots of different ways to implements locks in the Linux kernel, depending on your requirements. thanks, greg k-h _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Sat Sep 01 2001 - 17:16:34 PDT