John, Marcel,
we are reviewing possibilities of working on Bluetooth 3.0. With
Bluetooth 3.0 you essentially will switch to transmitting large data
over your 802.11 device instead of the BT device. One of the first
questions we need to address first is how we would go about
coordinating development between wireless-testing and
bluetooth-testing. First I'll note that I know squat of bluetooth so
bare with me if I'm not being 100% accurate here. From what I gather
on the mac80211 side the biggest piece will be the PAL implementation
which should translate HCI commands to respective 802.11 frames where
needed. It seems this would likely be the first thing tackled. Prior
to working on 802.11 though we realize that at some point we'll need
to synchronize the 802.11 and Bluetooth trees though so work done on
wireless-testing for a PAL is reasonable but then the
bluetooth-testing won't have the respective updates.
Using linux-next is one possibility but using linux-next proves a pain
due to the fact that every single update on breaks updates, so the
only way to update is:
git fetch
git reset --hard origin
Wanted to get your feedback on what you think would be the best
approach to take for focus on development for Bluetooth 3.0 support.
Hoping there is a better solution than using linux-next.
Luis
Hi John,
> > Wanted to get your feedback on what you think would be the best
> > approach to take for focus on development for Bluetooth 3.0 support.
> > Hoping there is a better solution than using linux-next.
>
> I'm sure Marcel and Johannes are way ahead of us on this. :-)
>
> I think you covered the basics, but you did leave-out the possibility
> of using net-next-2.6 for bleeding-edge development of bluetooth 3.
> Since both Marcel and I feed Dave's tree and Dave endeavours to
> keep the history of that tree stable then this would seem like your
> best bet.
if we reach the point where any kind of coordination is needed between
your and my tree, I would just merge into wireless-next-2.6 tree instead
of net-next-2.6. That should solve most issues around this anyway. And
in case it doesn't we will always need manual interaction on one side.
So I wouldn't try to overthink this right now.
The only tricky part I see is wireless-testing since bluetooth-testing
is not immutable right now. And I don't have any intention to make it
that way.
Regards
Marcel
Hi John,
> In any case, I was under the impression that at least the initial
> parts of the 802.11 AMP implementation could happen independently
> from any bluetooth stack changes...?
yes, we should be able to test the AMP pieces without a Bluetooth stack
implementing the AMP manager. Especially since there will be FullMAC
WiFi devices that implement the AMP inside firmware.
Regards
Marcel
John W. Linville wrote:
>
> In any case, I was under the impression that at least the initial
> parts of the 802.11 AMP implementation could happen independently
> from any bluetooth stack changes...?
You should be able to do (almost) all of the AMP PAL development and
testing without a Bluetooth stack.
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
On Thu, Feb 11, 2010 at 12:10:24PM -0800, Luis R. Rodriguez wrote:
> we are reviewing possibilities of working on Bluetooth 3.0. With
> Bluetooth 3.0 you essentially will switch to transmitting large data
> over your 802.11 device instead of the BT device. One of the first
> questions we need to address first is how we would go about
> coordinating development between wireless-testing and
> bluetooth-testing. First I'll note that I know squat of bluetooth so
> bare with me if I'm not being 100% accurate here. From what I gather
> on the mac80211 side the biggest piece will be the PAL implementation
> which should translate HCI commands to respective 802.11 frames where
> needed. It seems this would likely be the first thing tackled. Prior
> to working on 802.11 though we realize that at some point we'll need
> to synchronize the 802.11 and Bluetooth trees though so work done on
> wireless-testing for a PAL is reasonable but then the
> bluetooth-testing won't have the respective updates.
>
> Using linux-next is one possibility but using linux-next proves a pain
> due to the fact that every single update on breaks updates, so the
> only way to update is:
>
> git fetch
> git reset --hard origin
>
> Wanted to get your feedback on what you think would be the best
> approach to take for focus on development for Bluetooth 3.0 support.
> Hoping there is a better solution than using linux-next.
I'm sure Marcel and Johannes are way ahead of us on this. :-)
I think you covered the basics, but you did leave-out the possibility
of using net-next-2.6 for bleeding-edge development of bluetooth 3.
Since both Marcel and I feed Dave's tree and Dave endeavours to
keep the history of that tree stable then this would seem like your
best bet.
In any case, I was under the impression that at least the initial
parts of the 802.11 AMP implementation could happen independently
from any bluetooth stack changes...?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.