Prev: Announce loop-AES-v3.3a file/swap crypto package
Next: [PATCH] OMAP: Devkit8000: Add missing package selection
From: John Kacur on 18 Mar 2010 09:10
On Thu, Mar 18, 2010 at 1:33 PM, Frank Ch. Eigler <fche(a)redhat.com> wrote:
> Ingo Molnar <mingo(a)elte.hu> writes:
>
>> [...]
>> Distributions are very eager to update kernels even in stable periods of the
>> distro lifetime - they are much less willing to update user-space packages.
>> [...]
>
> Sorry, er, what? �What distributions eagerly upgrade kernels in stable
> periods, were it not primarily motivated by security fixes? �What users
> eagerly replace their kernels?
>

Us guys reading and participating on the list. ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: John Kacur on 18 Mar 2010 10:10
On Thu, Mar 18, 2010 at 2:59 PM, Ingo Molnar <mingo(a)elte.hu> wrote:
>
> * Daniel P. Berrange <berrange(a)redhat.com> wrote:
>
>> On Thu, Mar 18, 2010 at 02:31:24PM +0100, Ingo Molnar wrote:
>> >
>> > * Avi Kivity <avi(a)redhat.com> wrote:
>> >
>> > > On 03/18/2010 03:02 PM, Ingo Molnar wrote:
>> > > >
>> > > >> [...] What users eagerly replace their kernels?
>> > > >
>> > > > Those 99% who click on the 'install 193 updates' popup.
>> > > >
>> > >
>> > > Of which 1 is the kernel, and 192 are userspace updates (of which one may be
>> > > qemu).
>> >
>> > I think you didnt understand my (tersely explained) point - which is probably
>> > my fault. What i said is:
>> >
>> > �- distros update the kernel first. Often in stable releases as well if
>> > � �there's a new kernel released. (They must because it provides new hardware
>> > � �enablement and other critical changes they generally cannot skip.)
>> >
>> > �- Qemu on the other hand is not upgraded with (nearly) that level of urgency.
>> > � �Completely new versions will generally have to wait for the next distro
>> > � �release.
>>
>> This has nothing todo with them being in separate source repos. We could
>> update QEMU to new major feature releaes with the same frequency in a Fedora
>> release, but we delibrately choose not to rebase the QEMU userspace because
>> experiance has shown the downside from new bugs / regressions outweighs the
>> benefit of any new features.
>>
>> The QEMU updates in stable Fedora trees, now just follow the minor bugfix
>> release stream provided by QEMU & those arrive in Fedora with little
>> noticable delay.
>
> That is exactly what i said: Qemu and most user-space packages are on a
> 'slower' update track than the kernel: generally updated for minor releases.
>
> My further point was that the kernel on the other hand gets updated more
> frequently and as such, any user-space tool bits hosted in the kernel repo get
> updated more frequently as well.
>
> Thanks,
>
> � � � �Ingo

Just to play devil's advocate, let's not mix up the development model with the
distribution model. There is nothing to stop packagers and distributors from
providing separate kernel "proper" packages and perf tools packages.

It might even make good sense assuming backwards compatibility for distros
that have conservative policies about new kernel versions to provide newer
perf tools packages with older kernels.

John
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 18 Mar 2010 13:00
On Thu, Mar 18, 2010 at 6:38 PM, Anthony Liguori <anthony(a)codemonkey.ws> wrote:
>>>> There are all kernel space projects, going through Xorg would be a
>>>> horrible waste of performance for full-screen virtualization. It's fine
>>>> for the windowed or networked case (and good as a compatibility
>>>> fallback), but very much not fine for local desktop use.
>>
>> For the full-screen case (which is a very common mode of using a guest OS
>> on the desktop) there's not much of window management needed. You need to
>> save/restore as you switch in/out.
>
> I don't think I've ever used full-screen mode with my VMs and I use
> virtualization on a daily basis.
>
> We hear very infrequently from users using full screen mode.

Sorry for getting slightly off-topic but I find the above statement interesting.

I don't use virtualization on daily basis but a working, fully
integrated full-screen model with VirtualBox was the only reason I
bothered to give VMs a second chance. From my point of view, the user
experience of earlier versions (e.g. Parallels) was just too painful
to live with.

/me crawls back to his hole now...

Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 22 Mar 2010 08:40
On Mon, Mar 22, 2010 at 1:48 PM, Ingo Molnar <mingo(a)elte.hu> wrote:
>> What about line number information? �And the source? �Into the kernel with
>> them as well?
>
> Sigh. Please read the _very first_ suggestion i made, which solves all that. I
> rarely go into discussions without suggesting technical solutions - i'm not
> interested in flaming, i'm interested in real solutions.
>
> Here it is, repeated for the Nth time:
>
> Allow a guest to (optionally) integrate its VFS namespace with the host side
> as well. An example scheme would be:
>
> � /guests/Fedora-G1/
> � /guests/Fedora-G1/proc/
> � /guests/Fedora-G1/usr/
> � /guests/Fedora-G1/.../
> � /guests/OpenSuse-G2/
> � /guests/OpenSuse-G2/proc/
> � /guests/OpenSuse-G2/usr/
> � /guests/OpenSuse-G2/.../
>
> �( This feature would be configurable and would be default-off, to maintain
> � �the current status quo. )

Heh, funny. That would also solve my number one gripe with
virtualization these days: how to get files in and out of guests
without having to install extra packages on the guest side and
fiddling with mount points on every single guest image I want to play
with.

Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 22 Mar 2010 09:00
On Mon, Mar 22, 2010 at 2:36 PM, Avi Kivity <avi(a)redhat.com> wrote:
>> Here it is, repeated for the Nth time:
>>
>> Allow a guest to (optionally) integrate its VFS namespace with the host
>> side
>> as well. An example scheme would be:
>>
>> � �/guests/Fedora-G1/
>>
>
> [...]
>
> You're missing something. �This sub-thread is about someone launching a
> kernel with 'qemu -kernel', the kernel lives outside the guest disk image,
> they don't want a custom initrd because it's hard to make.

Well, you know, I am missing your point here about initrd. Surely the
guest kernels need to use sys_mount() at some point at which time they
could just tell the host kernel where they can find the mount points?
But maybe we're not talking about that kind of scenario here?

Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2 3
Prev: Announce loop-AES-v3.3a file/swap crypto package
Next: [PATCH] OMAP: Devkit8000: Add missing package selection