lkml.org 
[lkml]   [1998]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Cyrix Detection -- NO SMP, please ?????
    On Sun, 18 Oct 1998, Khimenko Victor wrote:

    > SMP=1 commented out ? No multicasting with eepro100 ???? What a hell ? SUCH
    > RECOMENDATION IS NOT ACCEPTABLE for 2.2 kernel! Reason ? 2.2 kernel SHOULD
    > work for AT LEAST 99.9% peoples in precompiled binary-only version with all
    > needed capabilities !!!

    First off, before you get all hot and bothered: SMP=1 SHOULD BE OFF BY
    DEFAULT!. No one SHOULD be running a SMP kernel on a non SMP box! Yes, it
    should not lockup.. But it's performance should be less. It should be no
    problem for a dist to ship two sets of kernels and modules, and a util to
    pick the right one.

    It would be nice if a kernel could work optimally on SMP and UP. This is
    not possible however, without such monstrosities as self modifying code.

    > It's Ok for development kernel to have comment "this feature will not work
    > with that other feature enabled" since
    > 1. It's development kernel -- why you think it will work at all ?
    > 2. Most users will compile development kernel for her own configuration.

    Yep.

    > For STABLE kernel situation when all NON-EXPERIMENTAL features are turned
    > on SHOULD produce kernel which will work for 99.9% peoples since this kernel
    > will be included in distributions and peoples SHOULD BE able to install
    > Linux "in full glory" WITHOUT kernel recompilation (I think that more then
    > half Linux users does not know how to recompile kernel just now and per cent
    > of such "dumb" users will grow in future). That's why modules was introduced
    > in 1.3 & 2.0 AFAIK. To avoid mess of 1.2.x-based distributions where was few
    > tens of different precompiled kernels :-(( 2.2 SHOULD NOT return that times!
    > Of course we could declare SMP and multicasting as experimental features but
    > what a gosh: SMP and multicasting are STILL EXPERIMENTAL ???? After few years
    > of development and great effort of Linus himself in SMP area ? Something is
    > REALLY wrong here. IMHO anyway.

    No there should be seperate SMP and UP kernels. Do you think that x86 and
    Alpha should run from the same kernel binary? SMP and UP are DIFFERNT
    BEASTS.

    Multicasting is only an issue with one driver (AFAIK) and is probably the
    result of the kludgery required to make multicast work on that card. How
    many places do use ethernet multicast? I do agree that it should be fixed,
    and they ARE working on it.

    > P.S. The same is about APM stuff: APM stuff SHOULD work with SMP enabled on
    > when there are really only one processor installed. Unfortunatelly looks like
    > a 2.3 stuff -- to many places to change :-(( But when SMP-enabled kernel could
    > not even START on UP comp -- that's other story. This should be avoided for
    > AT LEAST 99.9% of computers.

    No it shouldn't. You shouldn't be using APM with a SMP kernel. You
    shouldn't be using a SMP kernel on a UP box. SMP adds a lot of overhead
    and it's impossible to have a optimum UP (which most systems are) with a
    SMP kernel without self-modifying code.

    If downgrades wern't a consideration I'd be yelling to make SMP kernels
    refuse to boot on UP systems. I still think there should be a BIG notice
    that you shouldn't use a SMP kernel on a UP system...

    The dists can simply use a setup command to pick SMP or UP..



    -
    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:45    [W:3.370 / U:0.176 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site