lkml.org 
[lkml]   [2008]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Kernel version numbering scheme change
    On Fri, Oct 17, 2008 at 11:56:04AM +0300, Adrian Bunk wrote:
    > On Fri, Oct 17, 2008 at 12:55:44AM -0700, Greg KH wrote:
    > > On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
    > >...
    > > > Packages are built in a chroot with the correct release installed.
    > >
    > > Then why would this break if they are being built against the correct,
    > > older, kernel?
    >
    > How could you build userspace "against a kernel"?
    >
    > sys_*uname() returns the version of the running kernel.

    Which is why you don't want your build scripts to rely on that, but
    on the target kernel version instead. It's quite common in distros
    to patch makefiles and build scripts to force some constants instead
    of calls to nasty or misplaced commands. Uname certainly is one of
    them.

    > > But not against the proper kernel it will be run on, which sounds
    > > broken.
    >
    > Building software in a chroot is a common thing if you don't want to
    > setup a dedicated machine for a build environment (and all these hyped
    > virtualization solutions tend to not support architectures like alpha
    > or parisc).

    The chroot is OK when you want to maintain a few packages once in
    a while (eg: have it on your notebook to build packages for your
    customers' various distros). But it's not suited to maintain full
    distros, nor to cross-compile.

    > The OpenSSL 0.9.8 config script is existing userspace, and it will
    > break.

    And ? All distros shipping version 0.9.8 with a current kernel will
    have no problem because they backport fixes only. Once the new kernel
    is out, openssl will release a minor update with a few fixes and features,
    one of them being tagged as "support for Linux 2.8 and above". New distros
    will then have no trouble shipping a standard openssl with a standard
    kernel. All software have always worked like this, I really don't see
    the problem Adrian.

    > That is one example that "Will" definitely break (no matter how broken
    > or how easy to fix it is).

    What makes you think that current 0.9.8g will work on 2.6.521 ? One day
    you might have to upgrade your openssl anyway. What is important is that
    the upgrade follows a smooth path. Adding a two-liner patch in a minor
    release to support new versions is smooth.

    > > And hey, if it's a problem, just fix userspace reporting to always say
    > > we are the 2.6.30 release and go on our merry way, perhaps providing
    > > another sysctl if it's really needed (glibc probably wants it, so it
    > > would be easy to add.)
    > >
    > > That's just a minor technical thing that can be trivially fixed _IF_ we
    > > decide it is something that we want to do.
    >
    > If we do not continue to report the correct version in sys_*uname()
    > (and therefore in "uname -r") we break standard POSIX behavior.

    I would not like it if uname -r would not report real version. I'd
    better get a tool to force the version if this is needed (ala cpuid).
    It reminds me that I had this for years under DOS :-)

    Regards,
    Willy



    \
     
     \ /
      Last update: 2008-10-18 11:03    [W:5.332 / U:0.548 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site