Andre M. Hedrick wrote:
> On Tue, 8 Sep 1998, Jeffrey Hundstad wrote:
>
> > I have hardware that is already blacklisted for Linux. ...This
> > blacklisted hardware works fine with my current configuration, so I
> > turn on the feature that was disabled AFTER the boot. No harm done.
> >
> > Consider these two senerios:
> >
> > 1. Device gets blacklisted while not deserving it.
> >
> > Consequence: Hardware doesn't perform to its maximum.
> > Fix: Test the blacklisted feature, if it works turn the feature on
> > after the boot, if not leave feature turned off.
>
> This is a valid point, but I have been smashing ideas and banging out
> code variations to consider variable hardware combinations.
>
> The VIA code that I currently have is listed as (EXPERIMENTAL).
> Other thoughts are to dynamically tune the (U)DMA transfer rates
> based on chipsets and drives, with possible locks to prevent
> (without manually changing a flag, not handled by Config.in files)
> someone from accidentally enabling a DMA mode that has potential
> compatablity errors. (this is a thought in progress)
>
> Yeah, this sounds of big brother, but I don't want to be flamed for
> someone else's mistake by poking in the wrong place without being
> informed of the potental results.
>
> > 2. Device is not blacklisted when it should be.
> >
> > Consequence: a. Hardware fails during boot, can't continue
> > b. Hardware fails silently, corruption occurs.
> > Fix: a. throw out bad hardware, replace.
> > b. after months of wondering what's wrong, throw out bad
> > hardware, replace.
> >
> > Which senerio seems to be easier to live with. In my opinion 1 seems
> > easier to cope with on the downside. Of course the natural argument
>
> Some of the downsides that I am hearing about distribution install
> problems, may be a result of questionable stuff being blocked out.
>
> > is to blacklist all possible problems then whitelist known good
> > combinations... This smells like kernel bloat to me.
>
> Cheers,
> Andre
>
> -
> 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/faq.html
-
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/faq.html