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:	Thu, 18 Nov 2010 11:34:41 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	"Luis R. Rodriguez" <lrodriguez@...eros.com>
Cc:	linux-kernel@...r.kernel.org,
	linux-wireless <linux-wireless@...r.kernel.org>,
	Greg KH <greg@...ah.com>, David Miller <davem@...emloft.net>,
	"John W. Linville" <linville@...driver.com>,
	Stephen Hemminger <shemminger@...tta.com>,
	"Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@...el.com>,
	Charles Marker <Charles.Marker@...eros.com>,
	Jouni Malinen <Jouni.Malinen@...eros.com>,
	Kevin Hayes <kevin@...eros.com>,
	Zhifeng Cai <zhifeng.cai@...eros.com>,
	"Luis R. Rodriguez" <mcgrof@...il.com>,
	Don Breslin <Don.Breslin@...eros.com>,
	Doug Dahlby <Doug.Dahlby@...eros.com>,
	Julia Lawall <julia@...u.dk>
Subject: Re: Challenges with doing hardware bring up with Linux first

> I'd like to see hardware bring up at companies being done with Linux.

I know several companies where it is sometimes used.

> with this though. For starters hardware teams typically want to get
> hardware brought up as fast as possible to be able to sell chipsets.
> Its always a race. Proper Linux upstream support will get there but
> depending on the company this may mean this gets done after the
> proprietary driver approach is done first or simply until you have a
> big enough customer to justify it.

I've seen the kind of code written to "get it up as fast as possible" and
also to do validation. It's the sort of code that has to be written
anyway, and which contains a multitude of fascinating stuff which doesn't
ever want to go near upstream.

> everything else can be independent code. For ath9k in particular this
> means we keep ath9k_hw shared between our Operating Systems and that's
> it. In addition to this I believe opening up the common drivers for

The Linux copy needs to be GPL, but if you own every line of it then you
can relicense it. In fact we have examples of big bits of code that are
not Linux only - eg the ACPI stack which are managed in a non entirely
unrelated way.

> Can Linux help in any way? What if we used staging for a common driver
> architecture for different OSes? 

It's generally gone pear shaped in the past, although tools like spatch
are more modern than many of those attempts.

There is another way to do it which is instead of writing a glue layer
for Linux write to the general Linux interfaces which have the virtue of
being very simple for the most part, and keep the glue layer for the
other obscure environments where you are doing the stack ?

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