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]
Date:	Tue, 30 Jan 2007 11:10:20 -0800
From:	Greg KH <greg@...ah.com>
To:	Roland Dreier <rdreier@...co.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Free Linux Driver Development!

On Tue, Jan 30, 2007 at 09:45:50AM -0800, Roland Dreier wrote:
>  > All that is needed is some kind of specification that describes how your
>  > device works, or the email address of an engineer that is willing to
>  > answer questions every once in a while.  A few sample devices might be
>  > good to have so that debugging doesn't have to be done by email, but if
>  > necessary, that can be done.
> 
>  > This driver will work with all[1] of the different
>  > CPU types supported by Linux, the largest number of CPU types supported
>  > by any operating system ever before in the history of computing.
> 
>  > As for support, the driver will be supported through email by the
>  > original developers, when they can help out, and by the "enterprise"
>  > Linux distributors as part of their service agreements with their
>  > customers.
> 
> I'm all for openness of device programming specs, but I think 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.

Why is that crazy, we do that already today with the majority of drivers
in Linux.

> Just look at the in-tree drivers: there are tons of them that don't
> work on big-endian platforms, or have 64-bit problems, or have no SMP
> support.  And that doesn't even count drivers that are so bitrotted
> they won't even build any more.

Like Jeff said, many of these are quite old.

> And there are plenty of documented devices that no one cares enough
> about to submit a driver for.

Any specific examples?  I have a long list of people who wish to write
new drivers but just don't know which hardware is not yet supported.

> In the real world, a vendor that wants to make sure a device is
> supported by Linux had better pay someone to write the driver and keep
> it working.  Of course, if the device is popular enough or simple
> enough, docs are all that's needed, but in many cases no one competent
> to write the driver is going to volunteer to do it.

That's not true at all.  We have a whole raft of drivers in the kernel
that are supported only by the community (like the whole USB stack for
example) that vendors rely on working properly.

And again, I have a whole list of people who are competent to write
drivers wanting to do so (myself included), yet do not have any new
devices with specs to do it.

thanks,

greg k-h
-
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