Date: Sat, 30 Sep 1995 21:36:09 -0700 From: David Greenman <davidg@Root.COM> To: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> Cc: paul@netcraft.co.uk, CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/i386/isa wd.c Message-ID: <199510010436.VAA00135@corbin.Root.COM> In-Reply-To: Your message of "Sat, 30 Sep 95 11:53:20 PDT." <199509301853.LAA01936@GndRsh.aac.dev.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>IMHO, a grave mistake is being made here if the ATAPI support is going >into the 2.1 RELEASE is any form. Jordan claims that this will make >1000's of PC users happy. I claim it will create 800 bug reports from >the 80% of those 1000 user for whom it shall fail, and put a lot of egg >on the face of the 2.1 release. > >Ultimately this is David and Jordans decision to make though, and if >this is there decision I hope they are prepared to handle this side >effect. I appreciate the concerns that you and Paul have raised. Don't think I haven't thought about this a great deal during the past month or so. In fact I have and have come to the conclusion that even though there may be some post-release pain (although I honestly think this will be minimal) when having to deal with people who have IDE CDROM drives that don't work with the driver, the benefits of being able to support the other 90% of the people for which the driver works just fine far outway this...again, IMO. The situation for us is a little different than it would be for a commercial software house regarding new stuff. For commercial vendors, they would rather have a very crippled system than have to fix problems after a release has gone out. Philosophically, in an environment such as ours where software is contributed freely, integrated and redistributed for free, we have an obligation to get the code into the hands of people even when some fringe parts of it aren't 100%. If we had the attitude that everything in the distribution had to work 100% for 100% of the people, we'd have very little to distribute - we'd have to chop out about 50% of our code, and we'd be left with something that was nothing more than an intellectual curiosity that few people would want and noone could use. I'm not kidding - we'd have to remove about half of the device drivers (even your ix driver, Rod, has several serious bugs, but I wouldn't dream of not including in the release. [I plan to look into this soon, BTW.]). In my opinion as one of the two release engineers, the solution to satisfying the most number of people and maximizing our success is to provide as much functionality as possible and document the cases where it is known that the code isn't "100%". Of course, caution must be exercised in the core portions of the system that will affect everyone, and if this means that a feature must be #ifdef'd out or even completely eliminated in the release, then that's what I'll do (...but see below). >I can also attest that the -current version of the wd driver now seems >to have rather serious problems with my pre ATA-1 spec disk drives, >(Seagate ST-157A) that started about the time the ATAPI support went >in. I did no debugging on it, I simply pulled the drives and threw >them on the shelf as obsolete hardware. That problem has already been fixed in -current (knock on wood?). In fact it was the resolution of this problem that has delayed the integration of the driver into 2.1-stable. I believe it has been resolved, but if not, this commit I just made to the driver adds complete assurance that the non-ATAPI case is identical to the original wd driver. I would not have included the ATAPI changes if it weren't possible to completely seggregate them. ATAPI support will NOT be turned on in the standard (GENERIC) kernel. We will, however, turn it on in an alternate kernel so that installation from IDE CDROM drives is supported. Let me conclude in saying that I'm really not interested in arguing this point. I have too much to do and arguing about release decisions isn't helping the situation. If you have some constructive input about how the problems can be solved in the driver, then by all means please do discuss these with Serge or any other interested parties. -DG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510010436.VAA00135>