> 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