On Fri, Jul 08, 2005 at 02:48:03PM -0500, Timothy R. Chavez wrote:
> I've chosen not to respond to individual segments because the overall theme
> is that the right thing to do is to not duplicate functionality.
Correct.
> Your suggestion is to merge the two projects.
Or at the minimal, the common parts of them.
> In your mind, this benefits both projects.
I'm guessing that you don't think this will?
> It will
> consolidate the common functionality and enhance Inotify such that it is not
> only an event notification system for user space, but for other parts of the
> kernel -- namely audit -- as well. Is this a fair assessment?
Correct.
> I think we can all agree that functionality should not be duplicated. I have
> conceded that having two seperate hooks side-by-side that have the same
> purpose should be consolidated. Because this would be generic, all other
> notification hooks should be available to Inotify (and any other subsystem)
> as well. Agreed?
Yes.
> My vision is that audit, Inotify, and whatever else plugs into this framework
> and receives notifications this way -- a file system event notification system
> for the kernel. Then, audit, Inotify, etc would process this even information
> it receives and does with it what they will.
Sounds good.
> Ultimately, the part where we differ most, is the processing of information in
> fs/dcache.c to give dynamic updates in response to file system activity (such
> as attaching audit information to an auditable file whose inode just changed).
> I believe this should be kept seperate and not part of this framework nor Inotify.
> It's a specific requirement for audit, but not for Inotify. This is one of the places
> the two systems are functionally different.
I don't think it should be different. If inotify wants to just ignore
this information, it can.
> By doing it this way, both projects can retain their original goals and meet
> their individual requirements, and all the common pieces are consolidated in
> a logical way. This is something Robert and I had discussed on LKML in early
> December 2004, and was brought up in a discussion more recently for an RFC
> on LKML in early June between Christoph Hellwig and myself.
I'm very sad to see you ignored these comments by others. Any reason
why? It is pretty rude...
> Can this patch not be placed in -mm for the time being, as-is? Surely the
> logic it implements, what I envision will ultimately be retained, could benefit
> from the exposure in the interim?
Why not get it right, you agree that you know how to do this, and that
it should be done. What's the point of adding it now, as it will be
redone anyway? That would cause more work for others (andrew doesn't
maintain patches for free in -mm), and cause reports from people for a
codebase that is not going to ever make it into mainline.
Just do the right thing, you know what it is.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |