Re: kernel is always too big....

From: Peter T. Breuer (ptb_at_oboe.it.uc3m.es)
Date: 07/19/03 

Date: Sat, 19 Jul 2003 06:51:47 +0200

Dave Uhring <daveuhring@yahoo.com> wrote:
> On Sat, 19 Jul 2003 05:53:38 +0200, Peter T. Breuer wrote:

>> Dave Uhring <daveuhring@yahoo.com> wrote:

>>> If you don't change your hardware, what is the maintainability problem?
>>
>> Fixing bugs in drivers. Trying different irq/io options, and others.

> If you are re-writing those drivers or are using someone else's patches
> for those drivers, yes. Otherwise, no; there is no point whatever in

That's an extremely common situation. I must have changed my 3c905
drivers twenty times for each kernel version in the times when nobody
knew about 3com's own busmastering bugs and it was a question of this
week's random try-this-and-see-if-it-sticks.

Nowadays I'm always changing my xfs.o, for example!

> relying on modutils which may be full of bugs, and those have had an

?? Modutils has no interesting bugs. Never has had, as far as I know.
There are intrinsic race conditions in loading and unloading drivers,
but so what? You only load them once, and that would be the driver's
bug, not modutils, if there were one. And there is a possible loop if
you compile supprt for modutils as a module, but that's about all I can
think off ...

> infamous history.

Your sense of "infamous" seems equal to my sense of "completely solid"!

> If you have had the good sense to use supported hardware in the first

There is no such thing. Some hardware has drivers - that doesn't mean
that either the driver or the hardware is perfect, and bugs in both are
discovered with high frequency. And then there's perfective
maintenance. And there's adaptive maintenance (the environment changes
to expose new flaws ..). I simply have to check many different versions
of the same driver to locate the moment at which a behavior change
happened.

> place ....

Peter

Relevant Pages

  • Re: DVI output, ATI or nVidia
    ... don't necessarily get fixed any faster than closed source bugs. ... You do have a point that neither bugs experienced in vendor only supported drivers and openly available code and known specifications ensures someone or group will fix the problem. ... intel drivers means that someone would get better support. ... Since Linux distributions vary enough with compilers used and their frequency of updates, an open driver which the code can be updated and compiled for optimum performance would sell more hardware in my view. ...
    (Fedora)
  • Re: High-tech gadgets--distraction for motorists?
    ... group get experience with the new devices so the bugs could be worked ... That means drivers will have a wide range of skills and attitudes. ... Normal life which is why technology is put out there with black boxes to ...
    (misc.transport.road)
  • Re: Gnome KDE Xorg.conf
    ... drivers, I have couple of practical issues with them. ... bugs for Xorg. ... and buy some nice Intel one -- you get ...
    (Fedora)
  • Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
    ... The few remaining bugs will probably be ironed ... the maintainer load, and _that_ is neither warranted nor necessary. ... When nobody uses the legacy drivers to the point that ... handling bug reports for _two_ SCSI subsystems, ...
    (Linux-Kernel)
  • Re: kernel is always too big....
    ... > knew about 3com's own busmastering bugs and it was a question of this ... although I keep that in the kernel. ... The drivers in 2.4.21-xfs are ... If you are considering the use of any version of Linux as an NFS server ...
    (comp.os.linux.setup)