lkml.org 
[lkml]   [2008]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] e1000=y && e1000e=m regression fix
    Ingo Molnar wrote:
    > * Kok, Auke <auke-jan.h.kok@intel.com> wrote:
    >
    >>>> config E1000E_ENABLED
    >>>> - def_bool E1000E != n
    >>>> + def_bool E1000E = y || ((E1000E != n) && (E1000 = E1000E))
    >>> Uh, that's /not/ what Ingo's patch does. His patch makes e1000
    >>> claim the e1000e IDs if e1000 is built-in and e1000e is a module.
    >> so that's definately _not_ what I would like to see at all. Matthew
    >> points out that this will just prolong users to use e1000 instead of
    >> e1000e (which is what they should be encouraged to switch to in those
    >> cases).
    >>
    >> so I'm dropping my ACK
    >
    > why you want to cripple an existing, rather well working and popular
    > Linux driver is beyond me.

    Because we decided a long time ago to do this driver split. And everyone at that
    time agreed with that, and we set out to do this. And part of that plan was to
    move (not copy) the device IDs over.

    We accepted that that might break some kernel developers' systems in the process
    and consulted several vendors and distros if they were OK with the change and they
    all agreed with the plan.

    I do not want people with PCI Express e1000 cards to use e1000 for any day longer
    than is strictly needed, and I certainly do not want to prolong the period where
    both drivers could work on their adapters. That will be a far bigger nightmare for
    me than just a few kernel developers having a bad day.

    I guarantee, I will get e-mails about 2.6.25+e1000(e) issues for far longer then
    you guys :)

    Users will outnumber us kernel developers in complaints if we keep the situation
    unclear to them, and we already told them that they need to switch to e1000e for
    their PCI Express devices. If we now do stuff like what you proposed in that
    patch, we just prolong this confusion. That cannot be good for anyone. Imagine if
    distro's start picking random device IDs or worse. Stuff like that is already
    happening, and discussions like these just add to the confusion.

    Again - If there is a way to auto-enable e1000e in the right way so that more
    systems migrate better then I'm all for it (even if forcing E1000E=y). But it
    seems that the various patches proposed don't cut it and frankly Kconfig is
    completely inadequate as a hardware enabling script since it knows absolutely
    nothing about the hardware in the first place. And it wasn't meant for that
    either. `make oldconfig` is not the answer ;).

    Again - this has happened before, I remember many of my boxes not booting because
    SATA Kconfig options changed and all my boxes failed to move the proper Kconfig
    symbols over when I ran `make oldconfig` myself. Somewhere around 2.6.20 or so.



    Auke


    \
     
     \ /
      Last update: 2008-04-10 23:29    [W:4.289 / U:0.156 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site