lkml.org 
[lkml]   [1999]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux/IA-64 byte order


    On 9 Mar 1999, Jes Sorensen wrote:
    >
    > I might be missing a point, but why do _we_ care that much about x86
    > compatibility?

    Because an operating system is only as good as the people using it
    consider it to be.

    > I see why M$ and others want it will all their closed
    > source applications but for Linux it is just a matter of recompilation
    > and that is what people really want to do.

    I don't think people want to do that. I know _I_ don't want to do that.
    What I do, in just about 99% of all cases, is to just install readymade
    binaries. I've grown to like the fact that rpm can upgrade my system over
    ftp, adn that I don't have to worry about makefiles for programs that I
    don't care about all that much.

    And I suspect other people feel the same way. Everybody has his own
    project that he's involved with (be it the kernel or the compiler or the
    libraries or more user-friendly things like KDE, Gnome, whatever), and
    people usually don't want to care.

    I don't expect people to track my kernels, for example, unless they are
    doing real kernel development. Some people still do, but most people
    obviously don't want to.

    > You say you care very
    > little about kernel module binary compatibility, why do you suddenly
    > care about compatibility of binary only user land applictions?

    Ask anybody - it's not sudden.

    Compatibility is of supreme importance. It's been the #1 priority for
    Linux since pretty much day one - although early on it used to be more of
    a source compatibility with Solaris, simply because binary compatibility
    with Linux itself didn't mean much.

    Why do you think I worked hard at making Linux/alpha be binary compatible
    with Digital UNIX? There's a huge power in having binary compatibility,
    especially in early days of porting: moving applications over _without_
    having to worry about whether there are major bugs in the compiler of the
    libraries, and knowing that if something broke, it is broken in the
    kernel.

    > I do not say we should use one byte order or the other, I just don't
    > see x86 binaries as a big reason reason for choosing one over the
    > other.

    What does an OS do? Really. What is the _one_ thing an OS is supposed to
    do for its users?

    Nice colourful icons? No.

    The main reason for having an OS in the first place is to act as a buffer
    between user programs and the hardware. User programs don't want to care
    whether they are talking to a SCSI controller or an IDE disk. User
    programs do not want to know whether the system has a floating point unit
    or not. User programs just want to run, and run as efficiently as possible
    given some abstraction level high enough that they don't have to worry
    about each small detail.

    Anything that we can reasonably do to be better at that job is our primary
    directive as kernel developers. Ours is not to ask _why_ people do things.
    That's why you shouldn't have policy in a kernel: the only policies that
    are acceptable tend to be security-related or related to some basic
    implementation or design issue that just limits what you should allow your
    users to do.

    And that's also why we should work hard at giving users as much freedom
    ass we can. On the UltraSparc, this means the ability to run old SunOS
    32-bit binaries: because people still use them, and in many cases it
    doesn't actually give them anything to upgrade. On the Merced, it means
    running x86 binaries.

    You obviously DO have to balance all of these kinds of decisions with
    other issues:
    - how clean it is to implement
    - what is performance like
    - what are the implications for the kernel in the long run

    but at least for the Merced/x86, these are all pretty much non-issues, as
    the whole machine has been designed to also run x86 binaries anyway.

    So why are kernel modules so different? And why are "system programs"
    different (I don't mind occasionally breaking programs like "ifconfig" and
    "modprobe" etc, for example)?

    Basically, with kernel modules and system programs, the upside of
    maintaining compatibility is not nearly as big (they are counted in the
    tens rather than in the tens of thousands), and the _downsides_ are huge.
    When something interacts that closely with the kernel, the implications in
    the long run of maintaining compatibility are just prohibitive.

    Linus


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:50    [W:7.894 / U:0.292 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site