On martedì 26 giugno 2007, Richard Andrews wrote:
> --- Antoine Martin <[EMAIL PROTECTED]> wrote:
> > Recent distros (except slackware) may not work with 2.4 (udev/devfs/etc)
> > but apart from that any recent 2.6 kernel should do (bearing in mind
> > that few bugfixes are backported (except for 2.6.16).
>
> I was thinking more in terms of features added throughout the 2.6 series
> like syslets, USB handling changes, udev versus hotplug, selinux, sysctls,
> ioctls, alsa v oss; that sort of thing.

What you say is not unreasonable, but is mostly wrong,

Binary compatibility is a must - which means that the latest kernel should 
always run all older binaries, and all older distro images (except for module 
support, which changed from 2.4 to 2.6). Another important change is /sys 
support, added in 2.6 (so, newer distro will require 2.6 kernels).

Then:

* syslets have not been merged, nor there is consensus over the definitive API 
shape
* USB handling changes: no idea about user-visible ones - automounting 
pendrives is a feature of KDE and gnome, implemented with the help of HAL and 
DBUS
* udev versus hotplug: yeah, a 2.6 distro won't work with a 2.4 kernel, but 
you can use a 2.6 one with a static /dev filesystem.
* sysctls: I do not remember any massive change
* ioctls: they're part of the ABI, so they are stable
* alsa provides oss compatibility, and this does not matter for UML since 
there's no sound support; 

> These features have evolved over 
> time as code has become unmaintained or gone out of favour and I would
> expect that these changes in the kernel's support for features would cause
> some grief if the kernel used didn't match the facilities an image expected
> the kernel to provide.

Well, code becomes unmaintained, but ABIs may not. The day a syscall is added 
to the Linux kernel, it must be maintained forever.

> > > The nagafix page seems to promote a mix-and-match approach which
> > > doesn't sound like it would deliver the best results.
> >
> > Heh? It's just a repository of prebuilt filesystems and kernel images,
> > it is not meant to promote any particular combination, what makes you
> > think that?
>
> It's also probably the first place beginners go to get a quick-start with
> UML (it was for me). I just expect there to be particular incompatibilites
> between certain uml-kernels and distro images (reasoning outlined above). I
> expected to see mention of a kernel or kernels known to work with each
> image as a basic guide for beginners; eg. a debian pack, fc7 pack, centos
> pack, etc where you can get a kernel and image already tested together.
>
> When I look at nagafix I see N kernels and M images; so how do I chose
> which kernel to get for a particular image I decide to run?
>
> If there are no kernel-v-image incompatibilities
Yes, except the one noted on the page (and that's because older UML kernels 
miss a certain complex feature, i.e. full TLS support).

> then all is well - just my 
> inexperience showing. But it would also be nice to have an indication one
> way or the other in a prominent place.

Well, stating clearly such a thing is a very good idea - can you do it, 
Antoine?

Bye
-- 
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade

Attachment: signature.asc
Description: This is a digitally signed message part.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user

Reply via email to