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-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
