On Mon, Nov 07, 2011 at 03:12:28PM +0200, Pekka Enberg wrote: > On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o <ty...@mit.edu> wrote: > > I don't think perf should be used as a precendent that now argues that > > any new kernel utility should be moved into the kernel sources. Does > > it make sense to move all of mount, fsck, login, etc., into the kernel > > sources? There are far more kernel tools outside of the kernel > > sources than inside the kernel sources.
[...] > I don't know if it makes sense to merge the tools you've mentioned above. > My gut feeling is that it's probably not reasonable - there's already a > community working on it with their own development process and coding > style. I don't think there's a simple answer to this but I don't agree with > your rather extreme position that all userspace tools should be kept out > of the kernel tree. Ted's position is not extreme. He follows the simple and exactly defined border between userspace and kernel. The native userspace feature is variability and substitutability. The util-linux package is really nice example: - you don't have to use it, you can use busybox - we have currently three implementation of login(1), many getty implementations, etc. - it's normal that people use the latest util-linux releases with very old kernels (in year 2008 I had report from person with kernel 2.4:-) - userspace is very often about portability -- it's crazy, but some people use some utils from util-linux on Hurd, Solaris and BSD (including very Linux specific things like mkswap and hwclock) Anyway, I agree that small one-man projects are ineffective for important system tools -- it's usually better to merge things into large projects with reliable infrastructure and alive community (here I agree with Lennart's idea to have 3-5 projects for whole low-level userspace). Karel -- Karel Zak <k...@redhat.com> http://karelzak.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html