Re: under CONFIG_EXPERIMENTAL? (was Re: Why auditing and ACL's areimportant (was: audit_ids system calls))

From: Linda Walsh (
Date: Wed May 03 2000 - 16:08:51 EST

Tigran Aivazian wrote:
> On Wed, 3 May 2000, Linda Walsh wrote:
> > Would putting all the work
> > under a config option and marking it EXPERIMENTAL make everyone
> > happy enough for this to proceed? *Please*? :-)
> Dear Linda,
> may I ask (out of curiosity) if your patch is the same as "all the work"
> you are mentioning above? From the very brief look at your patch I thought
> you provide a framework for 64bit-returning system calls (only for IA32!)
> and also add a couple of system calls to set/get audit id. Was that the
> entire infrastructure needed on kernel side or is it just the beginning
> with some more patches to follow?

	Our experience has been "release early, release often".  It
seems there is one group of people that prefer to see a patch in
bite-sized methodical "chunks", while apparently there are some that
only want to see the "large", whole thing patch.  I'm finding it
difficult to please both camps.  While smaller patches allow a 
reviewer to quickly see the impact and nature of a patch, larger patches
may be viewed as "too complex"/"too big".  It depends on who I am talking
to.  To rephrase -- it's easier to get a minute or two from a reviewer (such
as Linus or whoever else) several times over the course of a few months
than to have them get a big load all at once.  The assertions I can
make about small chunks can be quickly verified and corrected if need be.
As the number assertions in 1 patch grows, the review time doesn't just
grow linearly -- but more exponentially.  Thus it becomes
more work for a reviewer if it is all batched up. That's why I'm leaning
toward smaller patches that can be easily reviewed and digested -- also
so I can make corrections/fixes in design early on.

As for releasing only code for ia32 -- That's the machine I'm working on/developing for. I worked on the PL/M compiler team at Intel for 2-3 years early in my career. As such, I have a *fair* grasp of x86 assembler. I wouldn't pretend to know anything about any other platform at the assembly level -- it's like maybe with alot of effort I could write code for other platforms, but then you *really* probably wouldn't want it.... :-) (: Danger, danger, newbie writing code for alien platform kernel....danger).

> I am just trying to understand - because, perhaps, unwillingless to > include your stuff is merely due to the fact that it is not complete yet > and one (e.g. Linus) would be naturally inclined to see the whole picture > first before having any opinion? --- One can see a sample implementation using an 'audit_id' on under the B1 project. That's the *general* direction. I'd like to provide piecemeal pieces for reasons described in my large email last night. Releasing small functional chunks allows others to build on those chunks and work in parallel.

> > I don't know about auditing implementations but if your patch was able to > actually implement all that is necessary, it was *very* impressively > compact :) --- Well ya know...we do write really good code here...:-)

-l -- Linda A Walsh | Trust Technology, Core Linux, SGI | Voice: (650) 933-5338

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:13 EST