Searched hist:"32 a3d848" (Results 1 – 4 of 4) sorted by relevance
/openbmc/linux/fs/overlayfs/ |
H A D | copy_up.c | 32a3d848 Sun Dec 04 11:33:17 CST 2016 Al Viro <viro@ZenIV.linux.org.uk> ovl: clean up kstat usage
FWIW, there's a bit of abuse of struct kstat in overlayfs object creation paths - for one thing, it ends up with a very small subset of struct kstat (mode + rdev), for another it also needs link in case of symlinks and ends up passing it separately.
IMO it would be better to introduce a separate object for that.
In principle, we might even lift that thing into general API and switch ->mkdir()/->mknod()/->symlink() to identical calling conventions. Hell knows, perhaps ->create() as well...
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> 32a3d848 Sun Dec 04 11:33:17 CST 2016 Al Viro <viro@ZenIV.linux.org.uk> ovl: clean up kstat usage FWIW, there's a bit of abuse of struct kstat in overlayfs object creation paths - for one thing, it ends up with a very small subset of struct kstat (mode + rdev), for another it also needs link in case of symlinks and ends up passing it separately. IMO it would be better to introduce a separate object for that. In principle, we might even lift that thing into general API and switch ->mkdir()/->mknod()/->symlink() to identical calling conventions. Hell knows, perhaps ->create() as well... Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
|
H A D | dir.c | 32a3d848 Sun Dec 04 11:33:17 CST 2016 Al Viro <viro@ZenIV.linux.org.uk> ovl: clean up kstat usage
FWIW, there's a bit of abuse of struct kstat in overlayfs object creation paths - for one thing, it ends up with a very small subset of struct kstat (mode + rdev), for another it also needs link in case of symlinks and ends up passing it separately.
IMO it would be better to introduce a separate object for that.
In principle, we might even lift that thing into general API and switch ->mkdir()/->mknod()/->symlink() to identical calling conventions. Hell knows, perhaps ->create() as well...
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> 32a3d848 Sun Dec 04 11:33:17 CST 2016 Al Viro <viro@ZenIV.linux.org.uk> ovl: clean up kstat usage FWIW, there's a bit of abuse of struct kstat in overlayfs object creation paths - for one thing, it ends up with a very small subset of struct kstat (mode + rdev), for another it also needs link in case of symlinks and ends up passing it separately. IMO it would be better to introduce a separate object for that. In principle, we might even lift that thing into general API and switch ->mkdir()/->mknod()/->symlink() to identical calling conventions. Hell knows, perhaps ->create() as well... Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
|
H A D | overlayfs.h | 32a3d848 Sun Dec 04 11:33:17 CST 2016 Al Viro <viro@ZenIV.linux.org.uk> ovl: clean up kstat usage
FWIW, there's a bit of abuse of struct kstat in overlayfs object creation paths - for one thing, it ends up with a very small subset of struct kstat (mode + rdev), for another it also needs link in case of symlinks and ends up passing it separately.
IMO it would be better to introduce a separate object for that.
In principle, we might even lift that thing into general API and switch ->mkdir()/->mknod()/->symlink() to identical calling conventions. Hell knows, perhaps ->create() as well...
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> 32a3d848 Sun Dec 04 11:33:17 CST 2016 Al Viro <viro@ZenIV.linux.org.uk> ovl: clean up kstat usage FWIW, there's a bit of abuse of struct kstat in overlayfs object creation paths - for one thing, it ends up with a very small subset of struct kstat (mode + rdev), for another it also needs link in case of symlinks and ends up passing it separately. IMO it would be better to introduce a separate object for that. In principle, we might even lift that thing into general API and switch ->mkdir()/->mknod()/->symlink() to identical calling conventions. Hell knows, perhaps ->create() as well... Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
|
H A D | super.c | 32a3d848 Sun Dec 04 11:33:17 CST 2016 Al Viro <viro@ZenIV.linux.org.uk> ovl: clean up kstat usage
FWIW, there's a bit of abuse of struct kstat in overlayfs object creation paths - for one thing, it ends up with a very small subset of struct kstat (mode + rdev), for another it also needs link in case of symlinks and ends up passing it separately.
IMO it would be better to introduce a separate object for that.
In principle, we might even lift that thing into general API and switch ->mkdir()/->mknod()/->symlink() to identical calling conventions. Hell knows, perhaps ->create() as well...
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> 32a3d848 Sun Dec 04 11:33:17 CST 2016 Al Viro <viro@ZenIV.linux.org.uk> ovl: clean up kstat usage FWIW, there's a bit of abuse of struct kstat in overlayfs object creation paths - for one thing, it ends up with a very small subset of struct kstat (mode + rdev), for another it also needs link in case of symlinks and ends up passing it separately. IMO it would be better to introduce a separate object for that. In principle, we might even lift that thing into general API and switch ->mkdir()/->mknod()/->symlink() to identical calling conventions. Hell knows, perhaps ->create() as well... Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
|