Driver removals - Kernel

This is a discussion on Driver removals - Kernel ; Just a general thought on removing drivers in general, when a driver is removed because there's a better one, it would be good to have either a message which shows up at "make oldconfig" time, or a file listing the ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Driver removals

  1. Driver removals

    Just a general thought on removing drivers in general, when a driver is
    removed because there's a better one, it would be good to have either a
    message which shows up at "make oldconfig" time, or a file listing the
    driver(s) which replace it.

    Half the resistance to removing drivers is finding what is supposed to
    replace the driver. For instance a list of all the drivers Adrian Bunk
    has suggested to replace sk98lin, so users have something better than
    searching the source code and/or LKML archive to find the next thing to try.

    In general, if a driver works and is being used, until it *needs*
    attention I see no reason to replace it. I don't agree that "it forces
    people to try the new driver" is a valid reason, being unmaintained is
    only a problem if it needs maintenance. I am not going to reopen that
    topic, I'm simply noting a general opposition to unfunded mandates, and
    requiring changes to kernel, module and/or rc.local config is just that.

    --
    Bill Davidsen
    "We have more to fear from the bungling of the incompetent than from
    the machinations of the wicked." - from Slashdot

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

  2. Re: Driver removals

    On Wed, Feb 13, 2008 at 09:26:26PM -0500, Bill Davidsen wrote:
    >...
    > In general, if a driver works and is being used, until it *needs*
    > attention I see no reason to replace it. I don't agree that "it forces
    > people to try the new driver" is a valid reason, being unmaintained is
    > only a problem if it needs maintenance. I am not going to reopen that
    > topic, I'm simply noting a general opposition to unfunded mandates, and
    > requiring changes to kernel, module and/or rc.local config is just that.


    Keeping a working unmaintained driver in the tree is not a big deal - we
    have hundreds of them.

    But you miss the main point that removal of an obsolete driver with a
    new replacement driver forces people to finally report their problems
    with the new driver, thus making the new driver better.

    After all, the people who scream loudly that the new driver doesn't work
    for them when the old driver gets removed are the people who should have
    reported their problems with the new driver many years ago...

    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

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

  3. Re: Driver removals

    On Fri, Feb 15, 2008 at 02:07:41PM -0500, Bill Davidsen wrote:
    > Adrian Bunk wrote:
    >> On Wed, Feb 13, 2008 at 09:26:26PM -0500, Bill Davidsen wrote:
    >>> ...
    >>> In general, if a driver works and is being used, until it *needs*
    >>> attention I see no reason to replace it. I don't agree that "it
    >>> forces people to try the new driver" is a valid reason, being
    >>> unmaintained is only a problem if it needs maintenance. I am not
    >>> going to reopen that topic, I'm simply noting a general opposition
    >>> to unfunded mandates, and requiring changes to kernel, module and/or
    >>> rc.local config is just that.

    >>
    >> Keeping a working unmaintained driver in the tree is not a big deal -
    >> we have hundreds of them.
    >>
    >> But you miss the main point that removal of an obsolete driver with a
    >> new replacement driver forces people to finally report their problems
    >> with the new driver, thus making the new driver better.
    >>

    > You sure are proud of that new driver! People won't use it because the
    > old one is working fine, so you think it's fine to force them to make
    > changes in their system to use the new driver.


    Sometimes what is best in the global picture is not what everyone
    subjectively considers to be the best thing for him.

    Well, our whole society is based on this principle...

    > Best case is it works
    > after costing the user some time, worst case it doesn't and breaks their
    > system, so they stop upgrading the kernel and don't get security fixes.
    >...


    Instead of sending a bug report?

    When removing an obsolete driver adult people suddenly start whining
    "the new driver didn't work for me when I tried it one year ago".

    And when asking where they reported the bug in the new driver the answer
    is that they didn't report it.

    Driver development heavily relies on getting bug reports when something
    doesn't work.

    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

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

  4. Re: Driver removals

    Adrian Bunk wrote:
    > On Fri, Feb 15, 2008 at 02:07:41PM -0500, Bill Davidsen wrote:
    >
    >> Adrian Bunk wrote:
    >>
    >>> On Wed, Feb 13, 2008 at 09:26:26PM -0500, Bill Davidsen wrote:
    >>>
    >>>> ...
    >>>> In general, if a driver works and is being used, until it *needs*
    >>>> attention I see no reason to replace it. I don't agree that "it
    >>>> forces people to try the new driver" is a valid reason, being
    >>>> unmaintained is only a problem if it needs maintenance. I am not
    >>>> going to reopen that topic, I'm simply noting a general opposition
    >>>> to unfunded mandates, and requiring changes to kernel, module and/or
    >>>> rc.local config is just that.
    >>>>
    >>> Keeping a working unmaintained driver in the tree is not a big deal -
    >>> we have hundreds of them.
    >>>
    >>> But you miss the main point that removal of an obsolete driver with a
    >>> new replacement driver forces people to finally report their problems
    >>> with the new driver, thus making the new driver better.
    >>>
    >>>

    >> You sure are proud of that new driver! People won't use it because the
    >> old one is working fine, so you think it's fine to force them to make
    >> changes in their system to use the new driver.
    >>

    >
    > Sometimes what is best in the global picture is not what everyone
    > subjectively considers to be the best thing for him.
    >
    > Well, our whole society is based on this principle...
    >
    >
    >> Best case is it works
    >> after costing the user some time, worst case it doesn't and breaks their
    >> system, so they stop upgrading the kernel and don't get security fixes.
    >> ...
    >>

    >
    > Instead of sending a bug report?
    >


    To get the system working.
    > When removing an obsolete driver adult people suddenly start whining
    > "the new driver didn't work for me when I tried it one year ago".
    >
    > And when asking where they reported the bug in the new driver the answer
    > is that they didn't report it.
    >
    > Driver development heavily relies on getting bug reports when something
    > doesn't work.


    If you don't see an ethical problem in removing a working driver which
    is not taking support resources, in order to force people to test and
    debug a driver they don't now and never would need, so that it might in
    time offer them the same functionality those users already had... then I
    can never make you see why technological extortion is evil. People have
    always moved to new drivers without pushing because they were *better*,
    guess that model is dead.

    --
    Bill Davidsen
    "Woe unto the statesman who makes war without a reason that will still
    be valid when the war is over..." Otto von Bismark


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

  5. Re: Driver removals

    On Fri, 15 Feb 2008 20:08:13 EST, Bill Davidsen said:

    > can never make you see why technological extortion is evil. People have
    > always moved to new drivers without pushing because they were *better*,
    > guess that model is dead.


    And the drivers get better because the Code Fairy comes and sprinkles magic
    bugfix dust all over them? And the Code Fairy knows where to sprinkle bugfix
    dust because it can see where the Bugreport Fairy sprinkled Bugreport Dust?

    Yes, people will move without pushing when the drivers are better. However,
    remember that a major cultural motivation for the GPL is the concept of "give
    back". And if a user can't be bothered to even give back enough to say
    "wow, this blows, my Frobnozz9800 doesn't work with this driver", that's a
    problem with the user. They're getting it for free, they should at least
    give the developers the kindness of a bug report if something is broken...

    ....

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.8 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFHtkHacC3lWbTT17ARAk8kAKDglpj4+fnRUUDEJ2E1dj RMifRGbQCg5KdK
    Xd37j8ro4nPLw3+rLtNfkrQ=
    =CmfT
    -----END PGP SIGNATURE-----


  6. Re: Driver removals

    On Fri, Feb 15, 2008 at 08:08:13PM -0500, Bill Davidsen wrote:
    >...
    > If you don't see an ethical problem in removing a working driver which
    > is not taking support resources, in order to force people to test and
    > debug a driver they don't now and never would need, so that it might in
    > time offer them the same functionality those users already had... then I
    > can never make you see why technological extortion is evil.
    >...


    You miss one basic principle of free software:

    Forks are allowed, so when you don't like the way some software is
    developed you can always release a version of the software that is in
    your eyes better.

    And that's nothing evil, after all each distribution kernel is a fork of
    the upstream kernel.

    Hey, you can even use the 2.6.16 branch *I* do maintain to avoid what
    you claim was an "ethical problem".

    And if you don't like 2.6.16 either for whatever reason there's still no
    ethical problem but only the technical problem of you not getting your
    ass up and doing whatever is "better" in your opinion.

    After all, free software is not driven by people whining but by people
    doing stuff.

    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

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

  7. Re: Driver removals

    On Fri, Feb 15, 2008 at 08:52:27PM -0500, Valdis.Kletnieks@vt.edu wrote:
    > On Fri, 15 Feb 2008 20:08:13 EST, Bill Davidsen said:
    >
    > > can never make you see why technological extortion is evil. People have
    > > always moved to new drivers without pushing because they were *better*,
    > > guess that model is dead.

    >
    > And the drivers get better because the Code Fairy comes and sprinkles magic
    > bugfix dust all over them? And the Code Fairy knows where to sprinkle bugfix
    > dust because it can see where the Bugreport Fairy sprinkled Bugreport Dust?
    >
    > Yes, people will move without pushing when the drivers are better. However,
    > remember that a major cultural motivation for the GPL is the concept of "give
    > back". And if a user can't be bothered to even give back enough to say
    > "wow, this blows, my Frobnozz9800 doesn't work with this driver", that's a
    > problem with the user.


    I don't understand why kernel developers always think that users spend
    their whole time testing their new stuff. That is mostly true for a lot
    of desktop users, but definitely not for servers. On a server, you may
    *ignore* that a new driver exists for years. The basic make oldconfig
    does the stuff right.

    An old driver must spend some time marked "deprecated", if possible with
    the config option changed so that at least *something* informs the admin
    that it may soon be removed. It looks like this is something that people
    building a kernel every day and never getting more than one week of uptime
    do not understand. But there are many people who build once a year and
    upgrade that often at most, unless there is a big security issue.

    If the old driver simply keeps silently building when marked deprecated,
    noone will notice. And as Bill pointed it out, we should also make sure
    that when marked deprecated, the old one always refers to the new one so
    that the guy noticing this during the build has time to set up a test
    machine to try that new driver.

    Not everyone has a mouse and a joystick attached to the computers he
    builds kernels for...

    Willy

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

  8. Re: Driver removals

    Adrian Bunk wrote:
    > Forks are allowed, so when you don't like the way some software is
    > developed you can always release a version of the software that is in
    > your eyes better.
    >

    What a silly thought. Nobody, I should hope, wants multiple Linuxes
    competing and diluting the market. That's what went wrong with UNIX,
    and it's what's wrong with BSD (and what gave Linux a foothold.) Read
    your history; and for goodness sake, the less said on this the better.

    > After all, free software is not driven by people whining but by people
    > doing stuff.


    Howling protest is not whining. The whining comes from those who want
    to kill the old driver, which is reported to be used, works well and is
    wanted. It sounds insecure to want to terminate one's competition with
    such extreme prejudice. Let the old driver die of natural causes, if
    that's its destiny. And don't whine if the new can't make it on its own
    merits.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: Driver removals

    Valdis.Kletnieks@vt.edu wrote:
    > On Fri, 15 Feb 2008 20:08:13 EST, Bill Davidsen said:
    >
    >
    >> can never make you see why technological extortion is evil. People have
    >> always moved to new drivers without pushing because they were *better*,
    >> guess that model is dead.
    >>

    >
    > And the drivers get better because the Code Fairy comes and sprinkles magic
    > bugfix dust all over them? And the Code Fairy knows where to sprinkle bugfix
    > dust because it can see where the Bugreport Fairy sprinkled Bugreport Dust?
    >


    Drivers get better because someone who finds a benefit in them also
    finds a problem. They don't get better by developers looking for
    intermittent, probably load dependent, bugs which effect eight year old
    server hardware which was a low volume item, the developers are unlikely
    to have, and which is in use providing services, not on someone's
    desktop where it can reasonably be rebooted to test patches.
    > Yes, people will move without pushing when the drivers are better. However,
    > remember that a major cultural motivation for the GPL is the concept of "give
    > back". And if a user can't be bothered to even give back enough to say
    > "wow, this blows, my Frobnozz9800 doesn't work with this driver", that's a
    > problem with the user. They're getting it for free, they should at least
    > give the developers the kindness of a bug report if something is broken...
    >


    Not when drivers are "better" but when a new driver offers some benefit,
    be it reliability, capability, etc. When the new driver offers not a
    single benefit and the only "feature" is "possible unknown bugs," people
    are not going to change, and I don't think forcing people off working
    drivers is any more ethical than Microsoft killing XP to force people to
    VISTA. Less ethical, actually, because MSFT is looking for profit, and
    they make no pretense of caring about the users in any role but revenue
    stream.
    > ....
    >


    Insert it right next to the diatribe about developers who think that
    because some new feature was a lot of work that Linus *must* put it in
    the kernel, or users show show proper respect and gratitude and disrupt
    their production hardware to test and debug some new code which offers
    zero added functionality on that hardware. If you think downtime is
    "free" then you have not been working in the right environments, or for
    the right management.

    --
    Bill Davidsen
    "Woe unto the statesman who makes war without a reason that will still
    be valid when the war is over..." Otto von Bismark


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

  10. Re: Driver removals

    On Sat, 16 Feb 2008 08:39:08 +0100, Willy Tarreau said:

    > I don't understand why kernel developers always think that users spend
    > their whole time testing their new stuff. That is mostly true for a lot
    > of desktop users, but definitely not for servers. On a server, you may
    > *ignore* that a new driver exists for years. The basic make oldconfig
    > does the stuff right.


    Been there, done that. We got a number of boxes that sit there for ages
    between reboots and even longer between upgrades. Deploying Solaris 10 was
    like a 2-year process for some of our boxes (when the boxes are running the
    Oracle databases that house the enterprise business systems, and your
    organizational budget is pushing the $1B/year mark, everybody gets *really*
    cautious to avoid a CLM while upgrading... And we may actually manage to
    finally kill off our last AIX 4.3.3 box this quarter (4.3.3 was released all
    the way back in Sep 1999, and EOL'ed back in 2004 - don't ask.

    Of course, the difference is that we *expect* that there's a good chance that
    if we try to subject that sort of box to 3 year's worth of updates, there's a
    good chance we'll discover that some driver has been EOL'ed or otherwise
    problematic on now-ancient hardware...

    (And yes, there's a *lot* of risk-management going on centered around "What if
    we have to patch Server23 for a critical kernel security issue?". Of course,
    if it was actually *feasible* to blindly upgrade-and-reboot twice a month, the
    job could be done by a much less expensive patch monkey, so it's good job
    security





    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.8 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFHt7etcC3lWbTT17ARApCXAJ90tDCbdf3jMTFk5il0vC Hn50Sd9gCgnact
    jwilPgbeG/XS6qt+OZ7n6yI=
    =N6fW
    -----END PGP SIGNATURE-----


+ Reply to Thread