qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test ker


From: Karel Zak
Subject: Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
Date: Tue, 8 Nov 2011 14:29:35 +0100
User-agent: Mutt/1.5.19 (2009-01-05)

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 <address@hidden> 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  <address@hidden>
 http://karelzak.blogspot.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]