Re: Challenges with doing hardware bring up with Linux first

[Luis R. Rodriguez]

On Thu, Nov 18, 2010 at 3:34 AM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/