Andrew Morton wrote:
I must admit that I'm confused. In the context of how this thread started, I
have to ask what use Uncle Tillie has for kernel auditing. For that matter,
what does Uncle Tillie and the evil horde of ANY key worshipers have to do
with all the features that were added for power users and application
developers while LTT was still waiting in line?
If features such as UML, oprofile, audit, security hooks, vserver, etc.,
that are targeted at the same category of users that LTT is targeted at
can make it in the kernel, then I have a hard time understanding how
there could be any justification for refusing LTT's inclusion simply on
the basis that it doesn't benefit the least computer-literate of Linux
If the inclusion algorithm is based on the following three priorities:
1- Uncle tillie and the evil horde of ANY key worshippers
2- Carnivorous pepsi-can super-users
3- Beaver on steroids kernel developers
with features in category N being more important than those of N+1,
shouldn't all features useful for category N be considered based on an
equal footing? I mean, there is a total and complete absence of any tool
to category 2 users that even closely resembles LTT and addresses the
needs I outlined in my earlier email, and yet features that are useful to
an even narrower group than LTT are routinely included in the kernel.
Given that there is a regular set of patches that are being included in
the kernel to cater for the same audience LTT is meant for, given the
importance of having such a tool for the purposes I outlined earlier,
and given that you've agreed that there is no issue with maintenance,
what else remains for us (the LTT development team) to do in order to
get LTT in the kernel? Should we just send you an updated set of patches
for review and inclusion?
Great. Glad to see you agree. At least this one is crossed out.
I've double-checked what I already knew about kprobes and have looked again
at the site and the patch, and unless there's some feature of kprobes I don't
know about that allows using something else than the debug interrupt to add
hooks, you're wrong about this. In order to do what you describe, kprobes has
to hook itself onto the debug interrupt. Don't take my word for it, here's
what their web site says:
Generating new interrupts is simply unacceptable for LTT's functionality.
Not to mention that it breaks LTT because tracing something will generate
events of its own, which will generating tracing events of their own ...
We have, however, contemplated using kernel hooks, which BTW could be used
by the auditing code and quite a few other things too:
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || XXXX@XXXXX.COM || 1-866-677-4546
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/