On Tue, 2008-08-12 at 16:32 -0400, Steve Grubb wrote:
And any code created needs to be backwards compatible. you could have new
user
space/new kernel, or new user space/old kernel, and new kernel/old user
space. You have no way of dictating which versions of anything people will
use.
On Tue, 2008-08-12 at 21:33 -0300, Klaus Heinrich Kiwi wrote:
On Tue, 2008-08-12 at 16:32 -0400, Steve Grubb wrote:
And any code created needs to be backwards compatible. you could have new
user
space/new kernel, or new user space/old kernel, and new kernel/old user
space. You have
Eric Paris wrote:
On Tue, 2008-08-12 at 21:33 -0300, Klaus Heinrich Kiwi wrote:
I think that if we take this discussion to extremes, we'd be talking
about a 'self-descriptive meta language' so that upgrades to
userspace/kernel are well covered (can you say xml?)
HAHAHA, kernel output
Hi again,
For what it's worth, I dug through the code a bit, and am pretty sure that this
particular issue exists in lines 71-78 of ellist.c:
ptr = strtok_r(buf, , saved);
if (ptr == NULL)
return -1;
do {// If there's an '=' sign, its a keeper
On Wednesday 13 August 2008 12:25:09 Klaus Heinrich Kiwi wrote:
I like Mathew's idea of having a binary format though. Maybe it's
possible to carry the legacy format for some time while we have a more
robust (and extensible) binary format in parallel? And then having a
binary format version
Linda Knippers wrote:
Steve Grubb wrote:
In a binary representation, you would have a version number to
describe what structure to cast the pointer to. If you have new log
with old user space, it won't parse because it won't have the
template to cast with.
Is that any different from not
On Tue, 2008-08-12 at 19:47 -0400, Steve Grubb wrote:
On Wednesday 06 August 2008 10:36:46 Mimi Zohar wrote:
We are interested in using auditing's context pathname information.
Is this the best way of accessing it?
Add support for accessing auditing's inode full pathname.
What would
Klaus Heinrich Kiwi wrote:
On Tue, 2008-08-12 at 16:32 -0400, Steve Grubb wrote:
And any code created needs to be backwards compatible. you could have new user
space/new kernel, or new user space/old kernel, and new kernel/old user
space. You have no way of dictating which versions of
