> > For 2) you can just use permission() instead of vfs_permission() which > > is exactly the same in this case (and consolidated into a common > > function later in the vfs-cleanups tree). > > Miklos, don't delude people into thinking the vfs-cleanups tree is ever > going to get merged in its current state. Al's NAKed the path_* stuff, > Christoph's NAKed it too. Actually, the cleanup patches which I'm asking Michael to base his patches on were not NAKed. And Michael is not even working against the vfs-cleanups tree, but rather just a couple of these utimes cleanup patches, none of which are controversial like the path_* stuff. But even if he was working against the vfs-cleanups tree it wouldn't matter, since porting patches to/from the path_* API is trivial. > Ignoring them and putting up a VFS tree of your own is not going to > help matters. Do please tell me how else should I work? I post patches for review, gradually, not as a 100 patch series, when we manage to submit apparmor. That far easier for people to handle, and sure enough I get comments are testing for this stuff. As for Al's NAK: the only alternative suggestion he has been able to come up is to move the security hooks into callers. And that has been NAKed (not surprisingly) by the selinux folks. And there's nothing actually _wrong_ with those patches, they don't add complexity (actually they remove complexity), they don't slow down the kernel, and they even fix some bugs. Now what the hell more do we need? Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
