Messages in this thread | | | Date | Fri, 17 Oct 1997 01:00:19 -0500 (CDT) | From | dledford@dialnet ... | Subject | Re: serial input overrun(s) using ide-cd |
| |
On 16 Oct, John Kelly wrote:
> The CMD640 and RZ1000 problems are well known, and defensive > programming of the chipset can circumvent the problem. FreeBSD does ^^^^^^^^^^^^ > so without any need to disable interrupts during IDE disk I/O. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<RANT ON> Puh-leese. This argument, in and of itself is so ridiculous that no person in their right mind should ever utter such garbage. Let me explain. The argument implies that the FreeBSD IDE driver does not disable interrupts by default, and therefore the linux driver should do so as well. Involved in making this argument, there are several implicit premises involved in the above argument in order to make the first premise flow into the conclusion. One possible path of premises is as follows:
A. The FreeBSD IDE driver does not disable interrupts by default B. No FreeBSD system has FS corruption as a result of A. C. The linux IDE driver is the same as the FreeBSD driver.
Therefore, the linux IDE driver can do the same.
Well, that one falls flat without any further inspection since the linux and FreeBSD IDE drivers are *not* the same. Furthermore, even were they the same, it would still be fallacious unless you could show that linux was never used on any computer upon which FreeBSD wasn't also used. One can write other possible scenarios to try and justify your statement, but they only get more ridiculous the more you try. As a matter of argument, the following counter argument to yours can be made (and justified):
A. The FreeBSD user community is comprised of a higher percentage of highly skilled users and server platforms than is the linux user community (aka, we have a much larger number of the unwashed masses using linux than does FreeBSD). B. Statistical reports of problems or successes with certain hardware and drivers in the FreeBSD community represent said community. C. Statistical reports of the FreeBSD community do not include a significant number of samples from the "unwashed masses" and the hardware and software run by said "unwashed masses" in relation to the linux community.
Therefore, statistical reports from the FreeBSD community are not a valid statistical sample arena upon which to draw conclusions for the linux community as a whole.
So, can we now stop the "FreeBSD does it so linux should too" crap before I loose my dinner? Really, the worst implied premise in that argument is the premise that FreeBSD can do no wrong, since if that argument is applied unilaterally to the FreeBSD kernel, then it indeed implies that the FreeBSD kernel is doing things the right way in all cases. Give me a break. <RANT OFF>
> With such a small number of users to be affected, It would be much > better to enable interrupts during IDE disk I/O in the kernel and give > users a LILO/LOADLIN parameter to override the default behavior.
Sure, so now we cause disk corruption on flaky machines by default.
> The various distributions could even apply the override in their boot > disks if they were fearful of negative user feedback.
OK...so now we don't cause disk corruption on those machines by default. Hmmm...seems to me we are right back where we started except now we are confusing people by changing around the way we do things but ending up with the exact same results.
> Changing the Linux kernel default to ENABLE interrupts during IDE disk > I/O would be FAR SUPERIOR to probing for a recognizable PCI controller > in an effort to determine whether it seems "safe" to enable interrupts > during IDE disk I/O. With so many PCI users now, why go to such great > lengths merely to maintain a Linux tradition?
Because the tradition, unlike your proposal, is safe and avoids tons of repetitive email about disk corruption. I'd rather have people email about serial overruns, which are harmless, than email about "Why did linux trash my hard drive and loose the source code for my project that's due tomorrow?"
> Any why be hidebound by tradition? Just change the default and give > users a boot-time parm to override it!
<RANT ON, AGAIN> Sure, like the unwashed masses mentioned above are going to magically know that they should use this boot param on their particular drive and controller setup. Maybe they absorbed the information via osmosis as they slept with their tidy RedHat manual resting on their forehead since we all know that most people don't bother to actually read the damn things. <RANT OFF>
-- ***************************************************************************** * Doug Ledford * Unix, Novell, Dos, Windows 3.x, * * dledford@dialnet.net 873-DIAL * WfW, Windows 95 & NT Technician * * PPP access $14.95/month ***************************************** * Springfield, MO and surrounding * Usenet news, e-mail and shell account.* * communities. Sign-up online at * Web page creation and hosting, other * * 873-9000 V.34 * services available, call for info. * *****************************************************************************
| |