> > Well, we can disagree about the majority of drivers. My feeling is > > that most of the drivers that are really used by lots of people get > > support beyond just a dump of docs -- in fact often vendors are > > maintaining them, eg e1000, tg3, cciss, etc., to pick some running on > > the boxes I have around here. > > Check your history... tg3 was written by me and DaveM, and only after > years was it picked up by the vendor as their official Linux > driver. You have picked an excellent counter-example to your own > argument.
OK, fair enough, I forgot about tg3. But on the other hand, you wrote it without docs, actually _in spite of_ Broadcom, right? Which I think makes my point that documentation is neither necessary nor sufficient for a good Linux driver. Documentation helps, but if no one competent cares about the device then the driver won't get written. On the other hand, if the device is important enough, the driver will get written without documentation or vendor support. > > OK, but why isn't your army of volunteers fixing them? > > Because nobody has hardware for them? Greg said hardware wasn't necessary... > > And I seem to recall there's more SATA chipset documentation than Jeff > > Garzik has time to implement support for. > > I seriously doubt you can come up with even a single concrete example here. Sorry, I thought you said there was interesting stuff to do with the Promise documentation you got. I guess Nvidia ADMA is pretty much done now. > What experience? AFAICS, pretty much all modern hardware in use > outside of ATI/NVIDIA graphics is supported by Linux. Sure, popular hardware support is pretty good. But there are still pretty serious gaps, for example Ralink wireless drivers are still not upstream even with the vendor trying to help (and I think Ralink wireless is a good example of how we can't really keep the promises Greg is making). And there's plenty of stuff in-tree with lots of users that's in pretty dire shape, like ISDN (and the fact that we still CONFIG_ISDN_I4L). OK, it's not "modern" but Greg is also promising that we'll keep everything up-to-date with any upstream kernel changes, and there's obviously large chunks of the driver tree where that doesn't happen. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/