Re: Patch Acceptance Procedure

sarnoldat_private

On Mon, Jul 23, 2001 at 07:27:59PM -0400, jmjonesat_private wrote:
> There's no clear indication that, say, dividing the audit patch into 3
> sections will result in 1, 2, or 3 of them being accepted.  Or even that
> they are LIKELY to be accepted.

Well, it is easier to debate individual smaller points than a ball of
points. So, while it isn't a given that all three pieces will be
eventually lauded, the chance for any one point is going to be higher.

We can separate the patch under discussion into three pieces:
o modifying hooks to pass fd
o moving MAC before DAC
o including error code in post hooks

I *think* we have reached the consensus on the file descriptor issue
that though many of us don't see the inherent value, it doesn't cost too
much more to pass it along as information where it is available. (Though
the NOFD_AVAILABLE #define doesn't seem real friendly to me...) If I am
wrong, and this issue is unresolved in someone's mind, I trust the list
will know in short order.

For the MAC/DAC issue, I think we are still in the discussion stage; at
least, I haven't seen a real convincing argument for the movement, and
I'm sure the proponents of the change would say about the same for my
arguments of putting DAC first.

And, for putting the error code into the post hooks, I don't think there
has been any discussion yet. I would like to know if there is any
performance penalty paid (or saved!) by including the error code in the
post hooks, though I think in the end it will all about even out. (I
wonder about performance changes because the calls were moved to
unconditional versus conditional calls. I could see how performance
could go either way with these changes.) Perhaps other people have other
concerns?

By breaking the pieces into three patches, each issue can be debated
individually and possibly accepted individually. By taking all three as
a whole, all three need to have a consensus of some sort before the
omnibus patch would be added to the current tree.

Cheers! :)

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module