Challenges with doing hardware bring up with Linux first

Challenges with doing hardware bring up with Linux first

[Luis R. Rodriguez]

I'd like to see hardware bring up at companies being done with Linux.
>From what I see its what is typically done anyway since it seems like
the easiest platform to hack on but often times its done with closed
source / proprietary Linux drivers though. I'd prefer if this was done
with targeted upstream Linux drivers first. There are a few challenges
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.

There are two reasons why we have proprietary drivers today. One is
old tradition put forward by companies who have no software quality
control other than simply testing the damn driver and where no real
software engineering analysis is being done on the software. This has
allowed companies to write sloppy quick drivers for hardware for years
but this has also created a few important trends in driver development
practices which prevents doing hardware bring up on Linux first. The
biggest trend I see is that of sharing code between Operating Systems.
If a company can use the same driver code to build a Windows, Mac OS X
and Linux driver they'd do it. Sometimes though Operating System
vendors may push back though at an architectural level though and may
require hardware manufacturers to use more of their own OS stacks for
generic purposes. One case is the 802.11 stack. Modern Windows 7 and
Apple OS X driver have their own 802.11 stacks and Linux is no
different. This means you share less and less code as more code
becomes generic between drivers and Operating System vendors smarten
up and put some of this code in a form other companies can use in a
generic fashion. This ultimately makes the maintainable driver smaller
and smaller.

The amount of code sharing between different Operating Systems then at
least for 802.11 drivers becomes smaller and smaller. Some Operating
System vendors though do not have any 802.11 stack at all, so you
still need one for those companies. Maintaining these drivers then
becomes more and more of a challenge. Linux however is still very
attractive as a platform for doing hardware bring up though and it is
used today for that purposes but since you typically have no software
code quality oversight over proprietary drivers and since its easier
to do that those drivers typically get written first, even if hardware
bring up will be done on Linux first as the base OS. The proper
upstream drivers then typically then gets done as a secondary step
where the code gets a good amount of churn and review for upstream
considerations, the software this process produces ends up
highlighting the benefits of the good software engineering practices
we have in place today on Linux. These software practices are seen as
a higher burden though, a blocker for fast delivery of software and
fast hardware bring up.

This is of course all subjective but my take is that doing hardware
bring up first on Linux will push companies to start highly
prioritizing driver architecture design even more carefully. I am not
saying this is done done today, its just that the freedoms granted by
other Operating System vendors tends to produce lower quality and IMHO
completely unmaintainable drivers in the long run. The challenge
though is how you can still compete with the speed required by
hardware teams for hardware bring up pace and with the goals to help
share as much code between different Operating Systems supported. This
is a broad topic but I'd like to ask for ideas how we can help
companies better architect drivers so that the flexibility of Linux
upstream pushes companies to actually do proper upstream drivers first
but also help companies so that they can envision a good way to also
get their other OS drivers complete.

I think Atheros' approach and commitment to upstream is a perfect
example of how a company can change for the better. It however is
still faced with the above dilemmas. My own mental picture to help
resolve this is to push for permissive licensed software for code you
want to share between Linux and other Operating Systems, and
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
Windows and OS X / etc would be the next step, under a permissive
license. The other steps I believe would be important would be to also
work with other companies on a common permissive licensed 802.11 stack
where other Operating System vendors have no 802.11 stack. And of
course, a shared common OS agnostic set of APIs which can be shared by
companies. None of this would be used by Linux, of course though. For
Atheros then it would be:


           some common OS wrapper crap
                              |
                              |
                              v
                  Atheros HAL code
                   ^                          ^
                  /                            \
    some common OS        no OS de-wrapper (see note A)
    de-wrapper scripts              \
                /                                \
              v                                 v
ath9k_hw                                   common driver for OSes
         |                                                       |
                        \
         |                                                       |
                            \
         v                                                      v
                              \
 Other Linux driver stuff
                       \
   (ath9k, ath9k_common,                  common 802.11 stack
solution for OSes with their own 802.11 stack
    ath, mac80211, cfg80211)                        |
                                                                       |
                                                                       v
                                  solution for OSes with no 802.11 stack

A. Technically from our experience we see that not alot of OS calls
actually are needed in hardware code so this may be small fortunately

Can Linux help in any way? What if we used staging for a common driver
architecture for different OSes? Most of those staging drivers already
have some sort of OS agnostic cruft, why not try to help hardware
vendors by providing them with a common OS agnostic solution they can
share? Is this not out turf? If its not, are we perfectly OK in being
second citizens so long as the driver eventually gets done on proper
upstream Linux ? I'm not OK with it and hence my e-mail. I'm looking
for ideas and thoughts on this. Please no trolls, would really just
like some constructive discussions on this. As I see it maybe we can
move some of this OS agnostic crap into staging, and then use spatch
to write tools to de-unwrap crap to Linux specific stuff and help
maintain it. What this does is it moves OS agnostic crap out as a
community effort to help aid proper development and porting for Linux.
Since we'd maintain the crap / scripts / de-wrappers, we'd likely be
able to get drivers quicker and can have a framework to help companies
who still [1] need to support other Operating Systems.

[1] ;)

  Luis

Re: Challenges with doing hardware bring up with Linux first

[Theodore Tso]

Luis,

I'm having a little trouble understanding what it is your proposing.

I *think* you are suggesting that

a)  Some portion of the "OS agnostic crap" be relicensed under a BSD or Apache-style license.   And I think what you are suggesting would fall in that camp is the parts of the Linux 802.11 stack?

b)  That the "OS agnostic crap" be moved into staging.

Can we ignore where the code lives for now?   I think (b) doesn't make any sense at all.

And as far as (b) is concerned, I think what you are suggesting isn't so much about the code, but trying to somehow encourage, via the carrot of making ti easy to push vendors into agreeing that the Linux 802.11 wireless API should be considered the OS independent interface layer that random vendors creating 802.11 drivers can interface against.

And to make that easy, you want to relicense the 802.11 stack under a BSD/Apache license so that it makes life easy for people who are creating drivers for Windows XP.   Do I have that right?

Assuming I understand the motivations of your proposal and what it is you were proposing in the first place, might another course of action which might prove as efficient, if not more so in the long term, is for some volunteer (perhaps at Atheros) to create some freely licensed new code that creates a glue layer between the Linux interfaces that wireless drivers use to plug into Linux's 802.11 layer, and to the 802.11 layer for Windows 7 and Mac OS X.    Furthermore, to make this glue layer GPL with the exception clauses that allows the glue code to link into Windows 7 and Mac OS X.

What this provides for is a wonderful leverage for hardware vendors.   If they provide GPL'ed code for their core hardware drivers that link against the Linux 802.11 layer, at one fell swoop they also get Windows 7 and Mac OS X drivers for free!   Better yet, it doesn't require getting permission from the Linux world, since what is necessary is the existence of new glue code that allows the hardware dependent code that previously was Linux specific, and which now allows it to plug into the glue code which then allows it to become hardware independent code for Windows 7 and Mac OS X.

-- Ted

Re: Challenges with doing hardware bring up with Linux first

[Alan Cox]

> 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

Re: Challenges with doing hardware bring up with Linux first

[Greg KH]

On Thu, Nov 18, 2010 at 12:46:37AM -0800, Luis R. Rodriguez wrote:
> Can Linux help in any way? What if we used staging for a common driver
> architecture for different OSes? Most of those staging drivers already
> have some sort of OS agnostic cruft, why not try to help hardware
> vendors by providing them with a common OS agnostic solution they can
> share? Is this not out turf? If its not, are we perfectly OK in being
> second citizens so long as the driver eventually gets done on proper
> upstream Linux ? I'm not OK with it and hence my e-mail. I'm looking
> for ideas and thoughts on this. Please no trolls, would really just
> like some constructive discussions on this. As I see it maybe we can
> move some of this OS agnostic crap into staging, and then use spatch
> to write tools to de-unwrap crap to Linux specific stuff and help
> maintain it. What this does is it moves OS agnostic crap out as a
> community effort to help aid proper development and porting for Linux.
> Since we'd maintain the crap / scripts / de-wrappers, we'd likely be
> able to get drivers quicker and can have a framework to help companies
> who still [1] need to support other Operating Systems.

No, staging is for gettingn code into, or out of, the kernel tree, not
for anything else.

I have allowed it to be used to hold drivers in that are not
"acceptable", while another driver was written by others from scratch to
work properly on that hardware, and then the original one is dropped.
That's ok, as there is a time-limit on how long the code lives in the
staging tree.

But to try to use it to create a multi-os solution, no, that's not what
staging is for.

Also, please review the past multi-os driver initiatives that have
sprung up over the years (about 1 every 10 years it seems).  Please
learn from the past as to why those have failed every single time, and
why we don't want to even try to do that again.

thanks,

greg k-h

Re: Challenges with doing hardware bring up with Linux first

[Luis R. Rodriguez]

On Thu, Nov 18, 2010 at 3:11 AM, Theodore Tso <tytso@mit.edu> wrote:
> Luis,
>
> I'm having a little trouble understanding what it is your proposing.

I'm both, explaining why some companies tend to have a hard time
working directly upstream and using 802.11 as an example, and trying
to find ways to help change old habits to help companies work
upstream, even if that means for non 802.11 drivers, but by using
802.11 landscape as an example case study. My goal is to show a clear
path for vendors to work with proper Linux upstream first for bring
up, that is the long term goal I am trying to envision but at the same
time trying to address the other goals companies have to keep
supporting the other OSes and help the ecosystem by coming up with
ways to help guide companies or share more code for the other OSes,
not just for 802.11 but for other subsystems.

> I *think* you are suggesting that
>
> a)  Some portion of the "OS agnostic crap" be relicensed under a BSD or Apache-style license.

Well this is certainly possible, question is if we can gain from
sharing a common OS agnostic API, stuff it into staging and encourage
other vendors to consider using it for staging drivers. For a proper
port we could use spatch patches to then remove the OS agnostic crap
and start skinning the driver. Today in staging we'd do this step by
step by porting over each typedef or struct the vendor used, or we
just re-write the driver.

> And I think what you are suggesting would fall in that camp is the parts of the Linux 802.11 stack?
>
> b)  That the "OS agnostic crap" be moved into staging.
>
> Can we ignore where the code lives for now?   I think (b) doesn't make any sense at all.

But its OK for each staging driver to have their own OS shim stuff.
drivers/staging/ath6kl/os/linux/
Seems a bit at odds to be OK with this but not with a common OS shim
in staging for different drivers.

> And as far as (b) is concerned, I think what you are suggesting isn't so much about the code,
> but trying to somehow encourage, via the carrot of making it easy to push vendors into
> agreeing that the Linux 802.11 wireless API should be considered the OS independent
> interface layer that random vendors creating 802.11 drivers can interface against.

After Broadcom started hacking upstream and seeing TI start to work
upstream I actually believe for 802.11 we're pretty much set on
getting most if not all vendors on board with upstream today :) but I
was using 802.11 as an example of the challenges faced by companies
and old habits held, and hoping to find rational suggestions to
encourage either doing upstream first or helping die out the old
habits with better replacements which can suit us and the community /
vendors.

Sure - for 802.11 a shim wrapper against mac80211 would be ideal for
sure, but we'd then still need a common permissive licensed 802.11
stack for vendors to use, and an OS shim.

> And to make that easy, you want to relicense the 802.11 stack under a BSD/Apache license so
> that it makes life easy for people who are creating drivers for Windows XP.   Do I have that right?

I don't want to change the license of our 802.11 stack but am stating
that if a good 802.11 stack existed which was permissive licensed that
vendors would pick it. Its why a lot of vendors ended up picking
net80211 to base their own 802.11 stacks out of. Sure, if mac80211 was
permissive licensed we can likely get more traction with development
by considering using it as the common 802.11 stack for other OSes that
do not have their own 802.11 stack as well but that doesn't
necessarily have to be the answer. Since a common 802.11 stack is used
and will be used by vendors for years to come I wondered if it made
sense to stuff one for vendors into staging so that they can use for
this purpose. Earlier (not now with ath6kl and brcm80211) 802.11
staging drivers all implemented their own 802.11 stack, so why not
encourage using something more common and shared between vendors. This
is surely not our job as upstream Linux developers, but just pointing
out that these stacks will exist and be maintained for years to come.
I wonder what other type of similar situations there are with other
subsystems.

> Assuming I understand the motivations of your proposal and what it is you were proposing
> in the first place, might another course of action which might prove as efficient, if not more
> so in the long term, is for some volunteer (perhaps at Atheros) to create some freely licensed
> new code that creates a glue layer between the Linux interfaces that wireless drivers use to
> plug into Linux's 802.11 layer, and to the 802.11 layer for Windows 7 and Mac OS X.

Right, this is along with my thinking but I'll note that our ath9k
driver is completely independent and the only code shared today would
be the hardware code, stuff that goes into the ath9k_hw module. But
sure, other things like OS wrappers to help drivers work with
different OSes could potentially be released, if not seen as
competitive advantage. Getting a wrapper to be created for the
different OS 802.11 stacks would certainly help as well but that would
be a bit of a challenge as we'd need to hope for at least some
similarity between 802.11 stacks.

>  Furthermore, to make this glue layer GPL with the exception clauses that allows the glue code to link into Windows 7 and Mac OS X.

For that matter just make it ISC / permissive licensed as this is GPL
Compatible.

> What this provides for is a wonderful leverage for hardware vendors.   If they provide GPL'ed
> code for their core hardware drivers that link against the Linux 802.11 layer, at one fell swoop
> they also get Windows 7 and Mac OS X drivers for free!

Yes, indeed ! That would be ideal indeed, but we'd need then an 802.11
stack which is also permissive licensed and then make APIs for that
802.11 stack to match mac80211's or cfg80211's or bridges between
then. Because ultimately you will still need some 802.11 stack for
some OSes that don't have one.

>  Better yet, it doesn't require getting permission from the Linux world, since what is necessary is the existence
> of new glue code that allows the hardware dependent code that previously was Linux specific, and which now'
> allows it to plug into the glue code which then allows it to become hardware independent code for
> Windows 7 and Mac OS X.

Sure, that can likely work if the APIs don't change as often or we can
find some common ground.

  Luis

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

Re: Challenges with doing hardware bring up with Linux first

[Luis R. Rodriguez]

On Thu, Nov 18, 2010 at 8:45 AM, Greg KH <greg@kroah.com> wrote:
> On Thu, Nov 18, 2010 at 12:46:37AM -0800, Luis R. Rodriguez wrote:
>> Can Linux help in any way? What if we used staging for a common driver
>> architecture for different OSes? Most of those staging drivers already
>> have some sort of OS agnostic cruft, why not try to help hardware
>> vendors by providing them with a common OS agnostic solution they can
>> share? Is this not out turf? If its not, are we perfectly OK in being
>> second citizens so long as the driver eventually gets done on proper
>> upstream Linux ? I'm not OK with it and hence my e-mail. I'm looking
>> for ideas and thoughts on this. Please no trolls, would really just
>> like some constructive discussions on this. As I see it maybe we can
>> move some of this OS agnostic crap into staging, and then use spatch
>> to write tools to de-unwrap crap to Linux specific stuff and help
>> maintain it. What this does is it moves OS agnostic crap out as a
>> community effort to help aid proper development and porting for Linux.
>> Since we'd maintain the crap / scripts / de-wrappers, we'd likely be
>> able to get drivers quicker and can have a framework to help companies
>> who still [1] need to support other Operating Systems.
>
> No, staging is for gettingn code into, or out of, the kernel tree, not
> for anything else.
>
> I have allowed it to be used to hold drivers in that are not
> "acceptable", while another driver was written by others from scratch to
> work properly on that hardware, and then the original one is dropped.
> That's ok, as there is a time-limit on how long the code lives in the
> staging tree.
>
> But to try to use it to create a multi-os solution, no, that's not what
> staging is for.

OK thanks!

> Also, please review the past multi-os driver initiatives that have
> sprung up over the years (about 1 every 10 years it seems).  Please
> learn from the past as to why those have failed every single time, and
> why we don't want to even try to do that again.

:-) thanks, just testing waters to see what's possible and what
direction to focus more on.

  Luis

Re: Challenges with doing hardware bring up with Linux first

[Stephen Hemminger]

On Thu, 18 Nov 2010 08:53:22 -0800
"Luis R. Rodriguez" <lrodriguez@atheros.com> wrote:

> On Thu, Nov 18, 2010 at 8:45 AM, Greg KH <greg@kroah.com> wrote:
> > On Thu, Nov 18, 2010 at 12:46:37AM -0800, Luis R. Rodriguez wrote:
> >> Can Linux help in any way? What if we used staging for a common driver
> >> architecture for different OSes? Most of those staging drivers already
> >> have some sort of OS agnostic cruft, why not try to help hardware
> >> vendors by providing them with a common OS agnostic solution they can
> >> share? Is this not out turf? If its not, are we perfectly OK in being
> >> second citizens so long as the driver eventually gets done on proper
> >> upstream Linux ? I'm not OK with it and hence my e-mail. I'm looking
> >> for ideas and thoughts on this. Please no trolls, would really just
> >> like some constructive discussions on this. As I see it maybe we can
> >> move some of this OS agnostic crap into staging, and then use spatch
> >> to write tools to de-unwrap crap to Linux specific stuff and help
> >> maintain it. What this does is it moves OS agnostic crap out as a
> >> community effort to help aid proper development and porting for Linux.
> >> Since we'd maintain the crap / scripts / de-wrappers, we'd likely be
> >> able to get drivers quicker and can have a framework to help companies
> >> who still [1] need to support other Operating Systems.
> >
> > No, staging is for gettingn code into, or out of, the kernel tree, not
> > for anything else.
> >
> > I have allowed it to be used to hold drivers in that are not
> > "acceptable", while another driver was written by others from scratch to
> > work properly on that hardware, and then the original one is dropped.
> > That's ok, as there is a time-limit on how long the code lives in the
> > staging tree.
> >
> > But to try to use it to create a multi-os solution, no, that's not what
> > staging is for.
> 
> OK thanks!
> 
> > Also, please review the past multi-os driver initiatives that have
> > sprung up over the years (about 1 every 10 years it seems).  Please
> > learn from the past as to why those have failed every single time, and
> > why we don't want to even try to do that again.
> 
> :-) thanks, just testing waters to see what's possible and what
> direction to focus more on.
> 
>   Luis

If you go back to the Mythical Man Month you will find:
 "Plan on doing it twice; you are going to anyway"

Therefore I wouldn't worry about whether the first development version
is upstream.

-- 

Re: Challenges with doing hardware bring up with Linux first

[Adrian Chadd]

On 19 November 2010 00:53, Luis R. Rodriguez <lrodriguez@atheros.com> wrote:

>> Also, please review the past multi-os driver initiatives that have
>> sprung up over the years (about 1 every 10 years it seems).  Please
>> learn from the past as to why those have failed every single time, and
>> why we don't want to even try to do that again.
>
> :-) thanks, just testing waters to see what's possible and what
> direction to focus more on.

Being involved atm in the "re-multi-OS'ing" of ath code (ie, merging
some ath9k bits and pieces back into FreeBSD's HAL), I really
appreciate how the bulk of the hardware-fiddling bits are OS agnostic.
There's some messiness surrounding the 802.11 stack flags (which the
FreeBSD HAL "indirects" via HAL flags, hiding away some of the
net80211 internals) but a lot of the net80211 stuff is still tightly
integrated with the HAL. There's some platform specific stuff in
hardware twiddling functions (eg "am I a 40mhz channel? Am i a 2ghz
channel") but so far it's been straightforward to translate the
macros.

Now that I've just begun testing (what seems like!) functioning 11n
TX/RX in my HAL, I plan on starting to merge in more ath9k related
driver code in. I'll provide some more feedback to the ath9k-devel
list as I do this. I'm hoping that large chunks of the hardware
related code (eg AR9002 calibration) can be thrown in with very minor
changes.

But so far, I have this to say:

* decoupling the hardware twiddling stuff from OS/802.11 stack
specific stuff is helpful;
* some of the base types are different (eg integer type layout, bool,
etc), but that's relatively straightforward to merge over;
* keeping the bits that need locking in "higher level" files (ie,
separate from hardware twiddling as much as possible) is also helpful.
* trying to make the actual interface related code (eg "if_ath.c" in
FreeBSD; it's been broken out in ath9k) platform agnostic is likely
very difficult and a path to the parent posters "fail."



Adrian

Re: Challenges with doing hardware bring up with Linux first

[Luis R. Rodriguez]

On Sat, Nov 20, 2010 at 4:32 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 19 November 2010 00:53, Luis R. Rodriguez <lrodriguez@atheros.com> wrote:
>
>>> Also, please review the past multi-os driver initiatives that have
>>> sprung up over the years (about 1 every 10 years it seems).  Please
>>> learn from the past as to why those have failed every single time, and
>>> why we don't want to even try to do that again.
>>
>> :-) thanks, just testing waters to see what's possible and what
>> direction to focus more on.
>
> Being involved atm in the "re-multi-OS'ing" of ath code (ie, merging
> some ath9k bits and pieces back into FreeBSD's HAL), I really
> appreciate how the bulk of the hardware-fiddling bits are OS agnostic.
> There's some messiness surrounding the 802.11 stack flags (which the
> FreeBSD HAL "indirects" via HAL flags, hiding away some of the
> net80211 internals) but a lot of the net80211 stuff is still tightly
> integrated with the HAL. There's some platform specific stuff in
> hardware twiddling functions (eg "am I a 40mhz channel? Am i a 2ghz
> channel") but so far it's been straightforward to translate the
> macros.
>
> Now that I've just begun testing (what seems like!) functioning 11n
> TX/RX in my HAL, I plan on starting to merge in more ath9k related
> driver code in. I'll provide some more feedback to the ath9k-devel
> list as I do this. I'm hoping that large chunks of the hardware
> related code (eg AR9002 calibration) can be thrown in with very minor
> changes.
>
> But so far, I have this to say:
>
> * decoupling the hardware twiddling stuff from OS/802.11 stack
> specific stuff is helpful;

ath9k_hw mostly is 802.11 stack independent except band enum usage,
and maybe one other variable we stuffed in there to help clean out
code more.

> * some of the base types are different (eg integer type layout, bool,
> etc), but that's relatively straightforward to merge over;

OK

> * keeping the bits that need locking in "higher level" files (ie,
> separate from hardware twiddling as much as possible) is also helpful.

We do this already.

> * trying to make the actual interface related code (eg "if_ath.c" in
> FreeBSD; it's been broken out in ath9k) platform agnostic is likely
> very difficult and a path to the parent posters "fail."

Agreed. Thanks for your feedback.

  Luis

Re: Challenges with doing hardware bring up with Linux first

[Adrian Chadd]

On 21 November 2010 13:53, Luis R. Rodriguez <lrodriguez@atheros.com> wrote:

>> * decoupling the hardware twiddling stuff from OS/802.11 stack
>> specific stuff is helpful;
>
> ath9k_hw mostly is 802.11 stack independent except band enum usage,
> and maybe one other variable we stuffed in there to help clean out
> code more.

Yup, I saw that.


> Agreed. Thanks for your feedback.

No worries. You'll get more feedback when I come to actually trying to
port the AR9003 hwops code over.
As I said, I'll have a bit of a practice run soon with some of the
kite/merlin calibration stuff that isn't yet in FreeBSD.


Adrian

Re: Challenges with doing hardware bring up with Linux first

[Ted Ts'o]

On Thu, Nov 18, 2010 at 08:46:11AM -0800, Luis R. Rodriguez wrote:
> > What this provides for is a wonderful leverage for hardware
> > vendors.   If they provide GPL'ed code for their core hardware
> > drivers that link against the Linux 802.11 layer, at one fell
> > swoop they also get Windows 7 and Mac OS X drivers for free!
> 
> Yes, indeed ! That would be ideal indeed, but we'd need then an 802.11
> stack which is also permissive licensed and then make APIs for that
> 802.11 stack to match mac80211's or cfg80211's or bridges between
> then. Because ultimately you will still need some 802.11 stack for
> some OSes that don't have one.

I wonder how much this is true.  Yes, at the moment we still need to
worry about those OS's that don't have one; but how much longer will
hardware vendors need to support Windows XP?  If Linux, Windows 7, and
Mac OS X all have an 802.11 stack, what other OS's do the hardware
vendors need to support?

						- Ted

Re: Challenges with doing hardware bring up with Linux first

[Greg KH]

On Sun, Nov 21, 2010 at 08:02:36AM -0500, Ted Ts'o wrote:
> On Thu, Nov 18, 2010 at 08:46:11AM -0800, Luis R. Rodriguez wrote:
> > > What this provides for is a wonderful leverage for hardware
> > > vendors. ? If they provide GPL'ed code for their core hardware
> > > drivers that link against the Linux 802.11 layer, at one fell
> > > swoop they also get Windows 7 and Mac OS X drivers for free!
> > 
> > Yes, indeed ! That would be ideal indeed, but we'd need then an 802.11
> > stack which is also permissive licensed and then make APIs for that
> > 802.11 stack to match mac80211's or cfg80211's or bridges between
> > then. Because ultimately you will still need some 802.11 stack for
> > some OSes that don't have one.
> 
> I wonder how much this is true.  Yes, at the moment we still need to
> worry about those OS's that don't have one; but how much longer will
> hardware vendors need to support Windows XP?  If Linux, Windows 7, and
> Mac OS X all have an 802.11 stack, what other OS's do the hardware
> vendors need to support?

After visiting with a number of hardware companies that make wireless
chips, they mentioned that they still need to support, and they still
get new design wins for both eCos and vxworks, as well as some even
more obscure embedded operating systems that their customers use.

So unfortunatly, I don't see the ability for some of these vendors to
drop their own internal wifi stacks any year soon, if they still wish to
sell into some very large markets.

sorry,

greg k-h

Re: Challenges with doing hardware bring up with Linux first

[Luis R. Rodriguez]

On Sun, Nov 21, 2010 at 9:29 AM, Greg KH <greg@kroah.com> wrote:
> On Sun, Nov 21, 2010 at 08:02:36AM -0500, Ted Ts'o wrote:
>> On Thu, Nov 18, 2010 at 08:46:11AM -0800, Luis R. Rodriguez wrote:
>> > > What this provides for is a wonderful leverage for hardware
>> > > vendors. ? If they provide GPL'ed code for their core hardware
>> > > drivers that link against the Linux 802.11 layer, at one fell
>> > > swoop they also get Windows 7 and Mac OS X drivers for free!
>> >
>> > Yes, indeed ! That would be ideal indeed, but we'd need then an 802.11
>> > stack which is also permissive licensed and then make APIs for that
>> > 802.11 stack to match mac80211's or cfg80211's or bridges between
>> > then. Because ultimately you will still need some 802.11 stack for
>> > some OSes that don't have one.
>>
>> I wonder how much this is true.  Yes, at the moment we still need to
>> worry about those OS's that don't have one; but how much longer will
>> hardware vendors need to support Windows XP?  If Linux, Windows 7, and
>> Mac OS X all have an 802.11 stack, what other OS's do the hardware
>> vendors need to support?
>
> After visiting with a number of hardware companies that make wireless
> chips, they mentioned that they still need to support, and they still
> get new design wins for both eCos and vxworks, as well as some even
> more obscure embedded operating systems that their customers use.
>
> So unfortunatly, I don't see the ability for some of these vendors to
> drop their own internal wifi stacks any year soon, if they still wish to
> sell into some very large markets.
>
> sorry,

Right -- which is why ideally I think it'd be nice to have an open
permissive stack people shared. My preference would be to just pick up
what FreeBSD has and stick to it as it would then also take care of
FreeBSD. But companies would have to really want to do this and want
to share code.

  Luis

Re: Challenges with doing hardware bring up with Linux first

[Alan Cox]

> Right -- which is why ideally I think it'd be nice to have an open
> permissive stack people shared. My preference would be to just pick up

Which we know in practice they won't. They'll sit on fixes (often
security fixes) and tweak and add private copies of features. In turn the
Linux one could then only keep up by adding features itself - which would
have to be GPL to stop the same abuse continuing.

It's a nice idea but the corporations exist to make money and adding
proprietary custom stack add-ons is clearly a good move on their part to
do that.

Alan

Re: Challenges with doing hardware bring up with Linux first

[Ted Ts'o]

On Sun, Nov 21, 2010 at 08:31:24PM +0000, Alan Cox wrote:
> 
> Which we know in practice they won't. They'll sit on fixes (often
> security fixes) and tweak and add private copies of features. In turn the
> Linux one could then only keep up by adding features itself - which would
> have to be GPL to stop the same abuse continuing.
> 
> It's a nice idea but the corporations exist to make money and adding
> proprietary custom stack add-ons is clearly a good move on their part to
> do that.

Hence my recommendation that if someone is going to do the work to
create a 802.11 layer that has shims that work on multiple operating
systems, it be GPL with explicit exceptions to allow said layer to
work on legacy operating systems like QNX, et. al.  That way it forces
the hardware specific code to be released under the GPL --- if they
want to take advantage of the "write onces, work on multiple operating
systems" feature.

If someone is going to go through all of this work to make it possible
--- particularly if it's at a company such as Luis's employer, or any
other wifi chipset provider --- why should it allow their competitors
to do closed source drivers?  Better to structure the driver licensing
such that (a) there is benefit for companies to make a Linux driver by
using this common stack, and (b) but in exchange, it forces them to
make a driver which is guaranteed to be usable by Linux by virtual of
the fact that (1) the native interface is Linux's wireless stack, and
(2) the license forces them to GPL their driver. 

    		       	       	   - Ted

Re: Challenges with doing hardware bring up with Linux first

[Luis R. Rodriguez]

On Sun, Nov 21, 2010 at 12:31 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Right -- which is why ideally I think it'd be nice to have an open
>> permissive stack people shared. My preference would be to just pick up
>
> Which we know in practice they won't. They'll sit on fixes (often
> security fixes) and tweak and add private copies of features. In turn the
> Linux one could then only keep up by adding features itself - which would
> have to be GPL to stop the same abuse continuing.
>
> It's a nice idea but the corporations exist to make money and adding
> proprietary custom stack add-ons is clearly a good move on their part to
> do that.

I agree completely with you. Its up to companies to decide whether or
not they want to do that and ultimately traditionally companies have
preferred not to. I actually think there is more to it than not
wanting though... As I see it without people upstream working for some
of these companies its really hard for them to get these ideas and
actually believe in the possibility of it and the benefits. I'm
voicing this publicly to our own managers and lkml because I'd like to
see that companies get the message because realistically I really
don't expect anything like this has been *seriously* considered
before. When I ask people about it, I often hear people say they think
it'd be nice, but that's about it. Nothing more. No push, no action.
Its to the industry's best interest IMHO. Even if a common 802.11
stack was shared, if it was permissive licensed companies could still
go on and hack their own proprietary crap on top if they so wish, so
that would still be an option.

My point with all this thread is this: companies tend to not think out
of the proprietary box they have been put in by old driver development
habits, and driver development should not be so hard and tedious. They
should start considering working on more open solutions even for
proprietary operating systems, under a permissive license. I suspect
this will help out with resources considerations, bug fix propagation
and coordination between supporting different Operating Systems. We
also stand to gain from this on Linux too, after all a driver bug fix
for hardware sensitive code will need to be propagated to other OSes
anyway.

I can surely ignore the other OSes and their IMHO their terrible
software practices but I can't because although it only affects Linux
in a tedious way I think we can do better and strive for that. If
sharing an 802.11 stack seems like a pipe dream oh well, at least I
think we should consider opening up the code for the other OSes and
let communities help with that crap for our company. Let it evolve
naturally. The benefits of FOSS cannot just only benefit Linux.

  Luis

Re: Challenges with doing hardware bring up with Linux first

[Gábor Stefanik]

On Sun, Nov 21, 2010 at 10:44 PM, Ted Ts'o <tytso@mit.edu> wrote:
> On Sun, Nov 21, 2010 at 08:31:24PM +0000, Alan Cox wrote:
>>
>> Which we know in practice they won't. They'll sit on fixes (often
>> security fixes) and tweak and add private copies of features. In turn the
>> Linux one could then only keep up by adding features itself - which would
>> have to be GPL to stop the same abuse continuing.
>>
>> It's a nice idea but the corporations exist to make money and adding
>> proprietary custom stack add-ons is clearly a good move on their part to
>> do that.
>
> Hence my recommendation that if someone is going to do the work to
> create a 802.11 layer that has shims that work on multiple operating
> systems, it be GPL with explicit exceptions to allow said layer to
> work on legacy operating systems like QNX, et. al.  That way it forces
> the hardware specific code to be released under the GPL --- if they
> want to take advantage of the "write onces, work on multiple operating
> systems" feature.
>
> If someone is going to go through all of this work to make it possible
> --- particularly if it's at a company such as Luis's employer, or any
> other wifi chipset provider --- why should it allow their competitors
> to do closed source drivers?  Better to structure the driver licensing
> such that (a) there is benefit for companies to make a Linux driver by
> using this common stack, and (b) but in exchange, it forces them to
> make a driver which is guaranteed to be usable by Linux by virtual of
> the fact that (1) the native interface is Linux's wireless stack, and
> (2) the license forces them to GPL their driver.

By forcing the driver to be GPL, you automatically exclude Windows
from the list of platforms supported by such a cross-OS driver, as the
Windows NDIS headers are AFAIK under a GPL-incompatible license, so no
GPL driver can be written for Windows.

>
>                                   - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: Challenges with doing hardware bring up with Linux first

[Luis R. Rodriguez]

On Sun, Nov 21, 2010 at 1:44 PM, Ted Ts'o <tytso@mit.edu> wrote:
> On Sun, Nov 21, 2010 at 08:31:24PM +0000, Alan Cox wrote:
>>
>> Which we know in practice they won't. They'll sit on fixes (often
>> security fixes) and tweak and add private copies of features. In turn the
>> Linux one could then only keep up by adding features itself - which would
>> have to be GPL to stop the same abuse continuing.
>>
>> It's a nice idea but the corporations exist to make money and adding
>> proprietary custom stack add-ons is clearly a good move on their part to
>> do that.
>
> Hence my recommendation that if someone is going to do the work to
> create a 802.11 layer that has shims that work on multiple operating
> systems, it be GPL with explicit exceptions to allow said layer to
> work on legacy operating systems like QNX, et. al.  That way it forces
> the hardware specific code to be released under the GPL --- if they
> want to take advantage of the "write onces, work on multiple operating
> systems" feature.
>
> If someone is going to go through all of this work to make it possible
> --- particularly if it's at a company such as Luis's employer, or any
> other wifi chipset provider --- why should it allow their competitors
> to do closed source drivers?  Better to structure the driver licensing
> such that (a) there is benefit for companies to make a Linux driver by
> using this common stack, and (b) but in exchange, it forces them to
> make a driver which is guaranteed to be usable by Linux by virtual of
> the fact that (1) the native interface is Linux's wireless stack, and
> (2) the license forces them to GPL their driver.

Great points indeed however the GPL code cannot be used by the BSDs,
well it can but they don't wan it. So the only thing we can have is a
completely permissive licensed solution.

 Luis

Re: Challenges with doing hardware bring up with Linux first

[Luis R. Rodriguez]

2010/11/21 Gábor Stefanik <netrolller.3d@gmail.com>:
> On Sun, Nov 21, 2010 at 10:44 PM, Ted Ts'o <tytso@mit.edu> wrote:
>> On Sun, Nov 21, 2010 at 08:31:24PM +0000, Alan Cox wrote:
>>>
>>> Which we know in practice they won't. They'll sit on fixes (often
>>> security fixes) and tweak and add private copies of features. In turn the
>>> Linux one could then only keep up by adding features itself - which would
>>> have to be GPL to stop the same abuse continuing.
>>>
>>> It's a nice idea but the corporations exist to make money and adding
>>> proprietary custom stack add-ons is clearly a good move on their part to
>>> do that.
>>
>> Hence my recommendation that if someone is going to do the work to
>> create a 802.11 layer that has shims that work on multiple operating
>> systems, it be GPL with explicit exceptions to allow said layer to
>> work on legacy operating systems like QNX, et. al.  That way it forces
>> the hardware specific code to be released under the GPL --- if they
>> want to take advantage of the "write onces, work on multiple operating
>> systems" feature.
>>
>> If someone is going to go through all of this work to make it possible
>> --- particularly if it's at a company such as Luis's employer, or any
>> other wifi chipset provider --- why should it allow their competitors
>> to do closed source drivers?  Better to structure the driver licensing
>> such that (a) there is benefit for companies to make a Linux driver by
>> using this common stack, and (b) but in exchange, it forces them to
>> make a driver which is guaranteed to be usable by Linux by virtual of
>> the fact that (1) the native interface is Linux's wireless stack, and
>> (2) the license forces them to GPL their driver.
>
> By forcing the driver to be GPL, you automatically exclude Windows
> from the list of platforms supported by such a cross-OS driver, as the
> Windows NDIS headers are AFAIK under a GPL-incompatible license, so no
> GPL driver can be written for Windows.

I've actually have been told GPL drivers for windows are possible with
some hard work. I have yet to investigate further on what that "hard
work" means. But yes, that is a good example.

  Luis

Re: Challenges with doing hardware bring up with Linux first

[Luis R. Rodriguez]

On Sun, Nov 21, 2010 at 1:47 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Sun, Nov 21, 2010 at 12:31 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>> Right -- which is why ideally I think it'd be nice to have an open
>>> permissive stack people shared. My preference would be to just pick up
>>
>> Which we know in practice they won't. They'll sit on fixes (often
>> security fixes) and tweak and add private copies of features. In turn the
>> Linux one could then only keep up by adding features itself - which would
>> have to be GPL to stop the same abuse continuing.
>>
>> It's a nice idea but the corporations exist to make money and adding
>> proprietary custom stack add-ons is clearly a good move on their part to
>> do that.
>
> I agree completely with you. Its up to companies to decide whether or
> not they want to do that and ultimately traditionally companies have
> preferred not to. I actually think there is more to it than not
> wanting though... As I see it without people upstream working for some
> of these companies its really hard for them to get these ideas and
> actually believe in the possibility of it and the benefits. I'm
> voicing this publicly to our own managers and lkml because I'd like to
> see that companies get the message because realistically I really
> don't expect anything like this has been *seriously* considered
> before. When I ask people about it, I often hear people say they think
> it'd be nice, but that's about it. Nothing more. No push, no action.
> Its to the industry's best interest IMHO. Even if a common 802.11
> stack was shared, if it was permissive licensed companies could still
> go on and hack their own proprietary crap on top if they so wish, so
> that would still be an option.
>
> My point with all this thread is this: companies tend to not think out
> of the proprietary box they have been put in by old driver development
> habits, and driver development should not be so hard and tedious. They
> should start considering working on more open solutions even for
> proprietary operating systems, under a permissive license. I suspect
> this will help out with resources considerations, bug fix propagation
> and coordination between supporting different Operating Systems. We
> also stand to gain from this on Linux too, after all a driver bug fix
> for hardware sensitive code will need to be propagated to other OSes
> anyway.
>
> I can surely ignore the other OSes and their IMHO their terrible
> software practices but I can't because although it only affects Linux
> in a tedious way I think we can do better and strive for that. If
> sharing an 802.11 stack seems like a pipe dream oh well, at least I
> think we should consider opening up the code for the other OSes and
> let communities help with that crap for our company. Let it evolve
> naturally. The benefits of FOSS cannot just only benefit Linux.

Maybe what we need is a BSD guy at Atheros :)

  Luis

Re: Challenges with doing hardware bring up with Linux first

[Ted Ts'o]

On Sun, Nov 21, 2010 at 10:47:53PM +0100, Gábor Stefanik wrote:
> 
> By forcing the driver to be GPL, you automatically exclude Windows
> from the list of platforms supported by such a cross-OS driver, as the
> Windows NDIS headers are AFAIK under a GPL-incompatible license, so no
> GPL driver can be written for Windows.

I said GPL "with exceptions".  The exceptions would allow linking with
the necessary glue code (also licensed under GPL "with exceptions")
that allow linkage with legacy operating systems --- including
Windows.

OK, the BSD's won't like it.  Tough.  If someone were to make all of
this code available under those terms, they can either decide to suck
it up and use the code, or use the fact that the hardware dependent
portion of the driver is GPL'ed, which means it won't be supplied in
object-file only form, ala Nvidia, but in source code form, so that if
the BSD's want to use the GPL'ed source code as hardware documentation
so they can write their own docmentation, at least they have the
option/freedom to do so.

That at least would be my recommendation of what anyone doing these
Linux 802.11 compatible stack and shim code for legacy operating
systems do.  If we're going to do the work, we might as well set up
the licensing to force companies to do the right thing --- because if
we don't force companies to do the right thing, in all likelihood
there will be a race to the bottom where they won't.  And even if you
think companies will be altruistic, why not make sure the license is
such that the non-altruistic companies, or the clueless companies are
forced by their lawyers to do the right thing?

Even if Broadcom has reformed (and I don't competely believe it yet),
why should we be completely confident that they won't backslide?

      	      	     	    	   	 - Ted

Re: Challenges with doing hardware bring up with Linux first

[Greg KH]

On Sun, Nov 21, 2010 at 01:50:30PM -0800, Luis R. Rodriguez wrote:
> > By forcing the driver to be GPL, you automatically exclude Windows
> > from the list of platforms supported by such a cross-OS driver, as the
> > Windows NDIS headers are AFAIK under a GPL-incompatible license, so no
> > GPL driver can be written for Windows.
> 
> I've actually have been told GPL drivers for windows are possible with
> some hard work. I have yet to investigate further on what that "hard
> work" means. But yes, that is a good example.

The "hard work" means you can not use the Windows DDK at all.  People
have worked to reimplement the header files needed for this into mingw,
but it really restricts you and forces you to write "native" drivers for
Windows, not being able to take advantage of their driver model code at
all.

Oracle did a bunch of work for this in the past to port some of their
Linux kernel work to Windows, ask Andy Grover if you have questions
about it.

hope this helps,

greg k-h

Re: Challenges with doing hardware bring up with Linux first

[Pavel Machek]

Hi!

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

GPL-compatible is not right word. It has to be either GPL, or so
permissive that anyone is allowed to turn it into GPL.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Challenges with doing hardware bring up with Linux first

[Luis R. Rodriguez]

On Tue, Nov 30, 2010 at 11:26 AM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> >> 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.
>
> GPL-compatible is not right word. It has to be either GPL, or so
> permissive that anyone is allowed to turn it into GPL.

Oh?

  Luis

Re: Challenges with doing hardware bring up with Linux first

[Luis R. Rodriguez]

On Tue, Nov 30, 2010 at 11:30 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Tue, Nov 30, 2010 at 11:26 AM, Pavel Machek <pavel@ucw.cz> wrote:
>> Hi!
>>
>>> >> 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.
>>
>> GPL-compatible is not right word. It has to be either GPL, or so
>> permissive that anyone is allowed to turn it into GPL.
>
> Oh?

I actually was just thinking of getting rid of all the silly
MODULE_LICENSE() crap we have that is for GPL-Compatible licenses and
just adding:

MODULE_LICENSE("GPL-Compatible");

and be done with it. All the other stuff just confuses people.

  Luis

Re: Challenges with doing hardware bring up with Linux first

[Pavel Machek]

On Tue 2010-11-30 11:30:18, Luis R. Rodriguez wrote:
> On Tue, Nov 30, 2010 at 11:26 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> >> >> 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.
> >
> > GPL-compatible is not right word. It has to be either GPL, or so
> > permissive that anyone is allowed to turn it into GPL.
> 
> Oh?

Kernel is GPL. Dual BSD/GPL is ok. Just BSD... I don't think so.

/*
 * Copyright (c) 2008 Atheros Communications Inc.
 *
 * Permission to use, copy, modify, and/or distribute this software
for any
 * purpose with or without fee is hereby granted, provided that the
above
 * copyright notice and this permission notice appear in all copies.
 *

...but I need permission to relicense it under GPL, and I'm not sure I
have it.
							Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Challenges with doing hardware bring up with Linux first

[Luis R. Rodriguez]

On Tue, Nov 30, 2010 at 12:00 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Tue 2010-11-30 11:30:18, Luis R. Rodriguez wrote:
>> On Tue, Nov 30, 2010 at 11:26 AM, Pavel Machek <pavel@ucw.cz> wrote:
>> > Hi!
>> >
>> >> >> 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.
>> >
>> > GPL-compatible is not right word. It has to be either GPL, or so
>> > permissive that anyone is allowed to turn it into GPL.
>>
>> Oh?
>
> Kernel is GPL. Dual BSD/GPL is ok. Just BSD... I don't think so.
>
> /*
>  * Copyright (c) 2008 Atheros Communications Inc.
>  *
>  * Permission to use, copy, modify, and/or distribute this software
> for any
>  * purpose with or without fee is hereby granted, provided that the
> above
>  * copyright notice and this permission notice appear in all copies.
>  *
>
> ...but I need permission to relicense it under GPL, and I'm not sure I
> have it.

Got it, OK let me clarify that for you then. Yes. That is what makes
it GPL-Compatible. We droped the Dual GPL/BSD practice and picked up
the ISC license to help OpenBSD when we took Reyk's HAL from OpenBSD.
The ISC license is just a simpler BSD license due the Berne Convention
which makes one of the clauses implicit (respecting copyright between
countries). Its just a very simple permissive license.

 Luis

Re: Challenges with doing hardware bring up with Linux first

[david]

On Tue, 30 Nov 2010, Pavel Machek wrote:

> On Tue 2010-11-30 11:30:18, Luis R. Rodriguez wrote:
>> On Tue, Nov 30, 2010 at 11:26 AM, Pavel Machek <pavel@ucw.cz> wrote:
>>> Hi!
>>>
>>>>>> 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.
>>>
>>> GPL-compatible is not right word. It has to be either GPL, or so
>>> permissive that anyone is allowed to turn it into GPL.
>>
>> Oh?
>
> Kernel is GPL. Dual BSD/GPL is ok. Just BSD... I don't think so.
>
> /*
> * Copyright (c) 2008 Atheros Communications Inc.
> *
> * Permission to use, copy, modify, and/or distribute this software
> for any
> * purpose with or without fee is hereby granted, provided that the
> above
> * copyright notice and this permission notice appear in all copies.
> *
>
> ...but I need permission to relicense it under GPL, and I'm not sure I
> have it.
> 							Pavel

unless it's the old 4-clause BSD license (with the advertising clause, 
which almost nobody used anymore), the BSD code can be relicensed as 
anything (including proprietary), as long as the notices in the file are 
maintained.

it doesn't take more explicit permission to re-license something as GPL 
than it does to make it closed-source.

However,
   there are quite a few files in the kernel that are BSD licensed, when 
combined with other GPL code, the only way you can re-distribute the 
result is under the GPL, so it is effectivly 'converted' when you compile, 
but by leaving the file BSD, improvements to it can be shared back with 
the original authors and put into their main codebase, so it's actually 
more polite to leave the license as-is for this file.

David Lang

Re: Challenges with doing hardware bring up with Linux first

[Bradley M. Kuhn]

I assume someone started cc'ing me on this thread to get my opinion as a
non-lawyer GPL geek.

david@lang.hm wrote:
> However, there are quite a few files in the kernel that are BSD
> licensed, when combined with other GPL code, the only way you can
> re-distribute the result is under the GPL, so it is effectivly
> 'converted' when you compile, but by leaving the file BSD,
> improvements to it can be shared back with the original authors and
> put into their main codebase, so it's actually more polite to leave
> the license as-is for this file.

FWIW, I agree more or less completely with the above.  I think the
implications are the same for ISC as well, as Luis points out elsewhere
in the thread.
-- 
   -- bkuhn

Re: Challenges with doing hardware bring up with Linux first

[Pavel Machek]

Hi!

> > Which we know in practice they won't. They'll sit on fixes (often
> > security fixes) and tweak and add private copies of features. In turn the
> > Linux one could then only keep up by adding features itself - which would
> > have to be GPL to stop the same abuse continuing.
> > 
> > It's a nice idea but the corporations exist to make money and adding
> > proprietary custom stack add-ons is clearly a good move on their part to
> > do that.
> 
> Hence my recommendation that if someone is going to do the work to
> create a 802.11 layer that has shims that work on multiple operating
> systems, it be GPL with explicit exceptions to allow said layer to
> work on legacy operating systems like QNX, et. al.  That way it forces

Is the exception even neccessary? GPL has explicit permission to link
against non-GPL 'system' and 'compiler' libraries --which seems to be
exactly this.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Challenges with doing hardware bring up with Linux first

[Enrico Weigelt]

* Gábor Stefanik <netrolller.3d@gmail.com> wrote:

> By forcing the driver to be GPL, you automatically exclude Windows
> from the list of platforms supported by such a cross-OS driver, as the
> Windows NDIS headers are AFAIK under a GPL-incompatible license, so no
> GPL driver can be written for Windows.

Which kind of license do these headers enforce ?
Obviously they allow proprietary licenses, do they exclude 
open ones ?


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------