linux-kernel - Re: Challenges with doing hardware bring up with Linux first

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: <AANLkTikOZbtyhsk0OBb4OdUi6qj-7k_hU-aW_Pkhfpq0@mail.gmail.com>
Date:	Thu, 18 Nov 2010 08:51:46 -0800
From:	"Luis R. Rodriguez" <lrodriguez@...eros.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
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>,
	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

On Thu, Nov 18, 2010 at 3:34 AM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> 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,

GPL-Compatible you mean, right. I mean we have ath9k_hw with
permissive licensed files.

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

Right, which is why we worked on the permissive license approach to
help OpenBSD back in the day with ath5k.

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

Not sure I got this last part can you clarify a bit ? One of the ideas
I had was to make the OS agnostic stuff be defined by the Linux APIs
and have the kmalloc() etc map to whatever OS call. While a good idea,
the biggest hurdle was the difference in arguments required, and any
new Linux API change would break the OS wrappers until updated
respectively.

  Luis
--
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/