Messages in this thread |  | | | Date | Tue, 25 Mar 1997 20:05:58 -0500 | | From | "David S. Miller" <> | | Subject | Re: Sharing SCSI disks |
| |
Date: Tue, 25 Mar 1997 14:25:38 -0800 (PST) From: Michael Neuffer <neuffer@nomis.i-Connect.Net>
On Tue, 25 Mar 1997, Illuminati Primus wrote: > However, unlike an MS OS, you are always free to join in the development > effort. If RAW IO in linux is important to you, you could always help > implement it instead of continue to whine about its absence. We did, it got stopped cold it its tracks by Linus.
Since when does pinhead Torvalds completely control what features Linux provides for "everyone" on the planet? He never has and he never will.
He said that the day that RAW devices would be in the Linux kernel, he would leave the project.......... This is no excuse.
People who archive linux-scsi might be able to see the part of the discussion, that was in public. The discussion there happened somewhere around the middle of last year, if I remember correctly.
If someone other than Linus implemented it (I'm sure you could even find someone in the Linux community to do it for no monetary gain) YOU could provide those changes in your kernel. Guess what, this is called vendor value add if you've never heard it before.
As a nice result, if the usefullness of the feature in question does go into full bloom, most likely "that Linus guy" will leave stubborness and include the feature in his kernel.
This is the way Linux has always worked, and how it will continue to work. As an example it is very common for my Sparc development kernel sources to drift by up to 2MB of diffs from Linus's tree. Every once in a while I go through a negotiation process, what is worthwhile goes in, what is stupid I take out of my tree or implement in a better or more clean fashion to reach the same ends.
It is always, implement then show to maintainer, not piss and moan and do nothing if maintainer doesn't like the idea. You control most the negotiations if you have the code written and in use already.
---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><
|  |