lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45BFC1DA.7040807@garzik.org>
Date:	Tue, 30 Jan 2007 17:08:26 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	Roland Dreier <rdreier@...co.com>
CC:	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org
Subject: Re: Free Linux Driver Development!

Roland Dreier wrote:
>  > > 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.

That's your point??  I thought your point was (quoting your words)

> it's a
> bit disingenous to suggest that all a company has to do to get a
> driver written and supported is throw some documentation over the
> wall.  And it's crazy to suggest that the driver will work on every
> platform and be supported by enterprise distros.

To repeat -- that's how most Linux drivers have been written, 
/particularly/ the ones used most by users of enterprise distros.


>  > > OK, but why isn't your army of volunteers fixing them?
>  > 
>  > Because nobody has hardware for them?
> 
> Greg said hardware wasn't necessary...

I did not say "no developers [...]"

I said "nobody"


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

Mikael took care of it already.  And its supported by enterprise distros.


> I guess Nvidia ADMA is pretty much
> done now.

Yep.  Without docs, even.  And its supported by enterprise distros.


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

How so?  They appear to be working with wireless devs to get their 
driver into the tree.


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

Yes, large chunks of legacy ISA drivers, m68k drivers, and similar 
situations where the userbase has dwindled to a handful over a decade.

	Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ