[lkml]   [2010]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Challenges with doing hardware bring up with Linux first
On Thu, Nov 18, 2010 at 3:34 AM, Alan Cox <> 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


 \ /
  Last update: 2010-11-18 17:55    [W:0.096 / U:7.148 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site