Challenges with doing hardware bring up with Linux first

Challenges with doing hardware bring up with Linux first

Post by Theodore T » Fri, 19 Nov 2010 20:20:02


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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Challenges with doing hardware bring up with Linux first

Post by Luis R. Ro » Sat, 20 Nov 2010 01:50:02

n Thu, Nov 18, 2010 at 3:11 AM, Theodore Tso < XXXX@XXXXX.COM > wrote:

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.


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.


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.


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.


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.


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
 
 
 

Challenges with doing hardware bring up with Linux first

Post by Luis R. Ro » Sat, 20 Nov 2010 02:00:02


OK thanks!


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

Luis
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Challenges with doing hardware bring up with Linux first

Post by Stephen He » Sat, 20 Nov 2010 02:30:02

On Thu, 18 Nov 2010 08:53:22 -0800





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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Challenges with doing hardware bring up with Linux first

Post by Adrian Cha » Mon, 22 Nov 2010 09:40:01


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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Challenges with doing hardware bring up with Linux first

Post by Luis R. Ro » Mon, 22 Nov 2010 15:00:02


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.


OK


We do this already.


Agreed. Thanks for your feedback.

Luis
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Challenges with doing hardware bring up with Linux first

Post by Luis R. Ro » Mon, 22 Nov 2010 15:00:02


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.


OK


We do this already.


Agreed. Thanks for your feedback.

Luis
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Challenges with doing hardware bring up with Linux first

Post by Luis R. Ro » Mon, 22 Nov 2010 15:00:02


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.


OK


We do this already.


Agreed. Thanks for your feedback.

Luis
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Challenges with doing hardware bring up with Linux first

Post by Luis R. Ro » Mon, 22 Nov 2010 15:00:02


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.


OK


We do this already.


Agreed. Thanks for your feedback.

Luis
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Challenges with doing hardware bring up with Linux first

Post by Luis R. Ro » Mon, 22 Nov 2010 15:00:02


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.


OK


We do this already.


Agreed. Thanks for your feedback.

Luis
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Challenges with doing hardware bring up with Linux first

Post by Ted Ts' » Mon, 22 Nov 2010 22:10:02


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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Challenges with doing hardware bring up with Linux first

Post by Luis R. Ro » Tue, 23 Nov 2010 05:00:02


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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Challenges with doing hardware bring up with Linux first

Post by Gor Stefan » Tue, 23 Nov 2010 06:50:02


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.

> --
> To unsubscribe from this list: send the line "unsubscribe lin>x-wireless" in
> the body of a message to majordomo@>ger.kernel.org
> More majordomo info at ttp://vger.kernel.org/majo>domo-info.html
>



--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Challenges with doing hardware bring up with Linux first

Post by Luis R. Ro » Tue, 23 Nov 2010 07:00:01


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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

Challenges with doing hardware bring up with Linux first

Post by Luis R. Ro » Tue, 23 Nov 2010 07:00:02

2010/11/21 Gbor Stefanik < XXXX@XXXXX.COM >:



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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/