> > 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.
-
