There was some discussion about Bluetooth qualification almost a year ago.
Has there been any news since that discussion?
Are there any products using the BlueZ stack that have been tested and
approved by the BQB (Bluetooth Qualification Body)?
To aid in certification are there ICS (implementation conformance
specifications/statements) for individual profiles supported by BlueZ?
Thanks,
-Daryl.
At 02:49 AM 2/28/2003, Halam Rose wrote:
>I want to get involved in BlueZ and am willing to devote some time and
>perhaps even money to it. My Linux experience is limited and personally I
>know the bottom end of the Bluetooth stack much better than the top.
>
>It seems I am in a good position to assist or coordinate the qualification
>of BlueZ.
Ok. Looks like we have a volunteer :). That would be perfectly ok with me.
>Now I don't relay know who you are and what your involvement with
>BlueZ is, please could you drop me a few lines of introduction. Also I'd
>like to know how having a qualified BlueZ would help you so I can focus on
>the value.
I guess I don't have to introduce myself ;-).
http://bluez.sourceforge.net/CREDITS will pretty much tell you who is who.
btw Folks, we're probably missing quite a few people there. If you find that
your name is missing please drop me a note.
Thanks
Max
At 01:38 AM 2/28/2003, Marcel Holtmann wrote:
>Hi,
>
>> Max, can you "coordinate the efforts" for qualification ?
>> Who is going to write the test report ?
>> Is Bluez going to be listed as official Bluetooth qualified stack ?
>> Who is your contact at 7layers ?
>
>I have had a nice talk about this topic with Prof. Dr.-Ing. J=F6rg Wollert
>from the FH Bochum at the Bluetooth Kongress in Germany. They have done
>some work with 7 Layers Germany and if you like I can try to coordinate
>the efforts to get a Bluetooth qualification for BlueZ.
It's certainly up to you Marcel (i.e. I don't mind). But you and I are the=20
primary developers. So ...
Max
At 01:01 AM 2/28/2003, David LIBAULT wrote:
>Max, can you "coordinate the efforts" for qualification ?
I probably could. But I don't want to because I won't be very effective at it.
Mostly because of lack of time. When I do get free time I'd rather
fix bugs and implement missing features.
So I'd prefer if somebody else will lead and coordinate the efforts.
>Who is going to write the test report ?
>Is Bluez going to be listed as official Bluetooth qualified stack ?
I don't know. That's what we need to discuss.
There are many questions (at least in my mind) like
- Does it make sense to have qualified stack in the official kernel ?
Like I mentioned before I don't want to add things that simply don't make
sense for general stack operation only because we want to pass qualification
(I'm talking mostly about kernel stuff here).
In which case a separate qualified kernel package with the same API as mainstream
kernel make sense.
- What happens when we make changes to the stack ? Have to qualify again ?
etc
Max
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Folks,
Let's move this discussion to the bluez-devel list.
Please remove bluez-users from your CC list when you reply.
(this one will be last CC).
Thanks
Max
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Le Vendredi 28 F=E9vrier 2003 11:49, Halam Rose a =E9crit :
> Hello.
>
> I run the Bluetooth lab at 7 Layers UK and contacted Max offering to do
> qualification work for BlueZ in some not-obviously-commercial way. A qui=
ck
> summery of who we are may help you understand where we are coming from.
>
> 7 Layers run numerous Bluetooth and GSM labs around the world, boast 4
> BQB's and also supply and support Bluetooth test labs for other
> organisations.
>
> 7 Layers UK are eagerly awaiting completion of our BQTF status (the audit
> was the hardest 2 days work I can remember...), our BQB is nearly 1 year
> old :o) We have a qualified RF and protocol test rig though some tests w=
e
> have done by 7 Layers in Germany.
>
> I want to get involved in BlueZ and am willing to devote some time and
> perhaps even money to it. My Linux experience is limited and personally =
I
> know the bottom end of the Bluetooth stack much better than the top.
>
> It seems I am in a good position to assist or coordinate the qualificatio=
n
> of BlueZ. Now I don't relay know who you are and what your involvement
> with BlueZ is, please could you drop me a few lines of introduction. Als=
o
> I'd like to know how having a qualified BlueZ would help you so I can foc=
us
> on the value.
I work for Inventel (go to http://www.inventel.com for more information). Basicall=
y=20
we design and manufacture wireless access points. We already have one produ=
ct=20
qualified (BlueDSL) althouth it doesn't use Bluez.
Our next generation product uses Bluez, and we have already started=20
qualification tests/reports regarding the bluetooth stack. The profiles we=20
need to qualify are=20
LAN Access Profile
PAN
It would be an interest for us to have Bluez officially qualified, as we=20
wouldn't have to redo this part of the Bluetooth qualification for everyone=
=20
of our products...=20
Do you plan to have Bluez listed as a qualified stack ?
What "tester side" are you using to do the qualification ?
We can help by providing you with a Bluetooth access point with everything=20
you need to run the scripts, modify the stack etc...
Although we only need to qualify the access point side of the profiles, you=
=20
can use this platform to do anything with bluez including other profiles=20
qualification etc...
Regards,
David.
>
> Best Wishes
>
> Halam
>
> --------------------------------------------
> Halam Rose
> Bluetooth Specialist
> 7 layers UK Ltd
>
> Don't miss the 7 layers
> Update-seminar on testing & qualification
> 9 April 2003
> London Heathrow
> more details: http://www.7layers.com/news-room/news-room-events-2003.html
>
> Tel: +44 (0)1763 262524
> Fax: +44 (0)1763 261177
> Mob: +44 (0)7876 560922
> [email protected]
> http://www.7layers-UK.com
>
> Melbourn Science Park
> Cambridge Road
> Melbourn
> Hertfordshire SG8 6HB
>
> --------------------------------------------
> The information contained in this message
> is confidential and should not be disclosed
> to any third party whether or not you are the
> intended addressee indicated in the message.
> Addressees of this email may exercise their
> rights under the 1988 Data Protection Act.
> --------------------------------------------
>
>
>
>
> -----Original Message-----
> From: Marcel Holtmann [mailto:[email protected]]
> Sent: 28 February 2003 09:39
> To: [email protected]
> Cc: Max Krasnyansky; Daryl Van Vorst; BlueZ Mailing List;
> [email protected]; BlueZ Mailing List
> Subject: Re: [Bluez-devel] BlueZ Qualification
>
>
> Hi,
>
> > Max, can you "coordinate the efforts" for qualification ?
> > Who is going to write the test report ?
> > Is Bluez going to be listed as official Bluetooth qualified stack ?
> > Who is your contact at 7layers ?
>
> I have had a nice talk about this topic with Prof. Dr.-Ing. J=F6rg Woller=
t
> from the FH Bochum at the Bluetooth Kongress in Germany. They have done
> some work with 7 Layers Germany and if you like I can try to coordinate
> the efforts to get a Bluetooth qualification for BlueZ.
>
> Regards
>
> Marcel
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hello.
I run the Bluetooth lab at 7 Layers UK and contacted Max offering to do
qualification work for BlueZ in some not-obviously-commercial way. A quick
summery of who we are may help you understand where we are coming from.
7 Layers run numerous Bluetooth and GSM labs around the world, boast 4 BQB's
and also supply and support Bluetooth test labs for other organisations.
7 Layers UK are eagerly awaiting completion of our BQTF status (the audit
was the hardest 2 days work I can remember...), our BQB is nearly 1 year
old :o) We have a qualified RF and protocol test rig though some tests we
have done by 7 Layers in Germany.
I want to get involved in BlueZ and am willing to devote some time and
perhaps even money to it. My Linux experience is limited and personally I
know the bottom end of the Bluetooth stack much better than the top.
It seems I am in a good position to assist or coordinate the qualification
of BlueZ. Now I don't relay know who you are and what your involvement with
BlueZ is, please could you drop me a few lines of introduction. Also I'd
like to know how having a qualified BlueZ would help you so I can focus on
the value.
Best Wishes
Halam
--------------------------------------------
Halam Rose
Bluetooth Specialist
7 layers UK Ltd
Don't miss the 7 layers
Update-seminar on testing & qualification
9 April 2003
London Heathrow
more details: http://www.7layers.com/news-room/news-room-events-2003.html
Tel: +44 (0)1763 262524
Fax: +44 (0)1763 261177
Mob: +44 (0)7876 560922
[email protected]
http://www.7layers-UK.com
Melbourn Science Park
Cambridge Road
Melbourn
Hertfordshire SG8 6HB
--------------------------------------------
The information contained in this message
is confidential and should not be disclosed
to any third party whether or not you are the
intended addressee indicated in the message.
Addressees of this email may exercise their
rights under the 1988 Data Protection Act.
--------------------------------------------
-----Original Message-----
From: Marcel Holtmann [mailto:[email protected]]
Sent: 28 February 2003 09:39
To: [email protected]
Cc: Max Krasnyansky; Daryl Van Vorst; BlueZ Mailing List;
[email protected]; BlueZ Mailing List
Subject: Re: [Bluez-devel] BlueZ Qualification
Hi,
> Max, can you "coordinate the efforts" for qualification ?
> Who is going to write the test report ?
> Is Bluez going to be listed as official Bluetooth qualified stack ?
> Who is your contact at 7layers ?
I have had a nice talk about this topic with Prof. Dr.-Ing. J?rg Wollert
from the FH Bochum at the Bluetooth Kongress in Germany. They have done
some work with 7 Layers Germany and if you like I can try to coordinate
the efforts to get a Bluetooth qualification for BlueZ.
Regards
Marcel
Hi,
> Max, can you "coordinate the efforts" for qualification ?
> Who is going to write the test report ?
> Is Bluez going to be listed as official Bluetooth qualified stack ?
> Who is your contact at 7layers ?
I have had a nice talk about this topic with Prof. Dr.-Ing. J=F6rg Wollert
from the FH Bochum at the Bluetooth Kongress in Germany. They have done
some work with 7 Layers Germany and if you like I can try to coordinate
the efforts to get a Bluetooth qualification for BlueZ.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Max, can you "coordinate the efforts" for qualification ?
Who is going to write the test report ?
Is Bluez going to be listed as official Bluetooth qualified stack ?
Who is your contact at 7layers ?
Le Jeudi 27 F=E9vrier 2003 22:09, Max Krasnyansky a =E9crit :
> At 04:27 PM 2/24/2003, Daryl Van Vorst wrote:
> >There was some discussion about Bluetooth qualification almost a year ag=
o.
> > Has there been any news since that discussion?
>
> Several people (from different companies) seem to be working on writing
> test scripts. But there is no centralized effort.
>
> >Are there any products using the BlueZ stack that have been tested and
> > approved by the BQB (Bluetooth Qualification Body) ?
>
> Not that I know of.
>
> >To aid in certification are there ICS (implementation conformance
> > specifications/statements) for individual profiles supported by BlueZ ?
>
> Not yet. A lot of people are interested but no one has made any moves so
> far.
>
> It's good that you brought this issue up again. Because "7 layers UK" (a
> BQB company) expressed some interest in carrying out qualification work o=
n
> BlueZ without charging any fees as part of their marketing.
> So it's a good time to unite the efforts. We should probably start some
> project where people could contribute test scripts and stuff.
>
> I'm pretty sure that Sony and Inventel have done some work on it.
> Any comments/suggestions/ideas from you guys ?
>
> Thanks
> Max
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 04:27 PM 2/24/2003, Daryl Van Vorst wrote:
>There was some discussion about Bluetooth qualification almost a year ago. Has there been any news since that discussion?
Several people (from different companies) seem to be working on writing test scripts.
But there is no centralized effort.
>Are there any products using the BlueZ stack that have been tested and approved by the BQB (Bluetooth Qualification Body) ?
Not that I know of.
>To aid in certification are there ICS (implementation conformance specifications/statements) for individual profiles
>supported by BlueZ ?
Not yet. A lot of people are interested but no one has made any moves so far.
It's good that you brought this issue up again. Because "7 layers UK" (a BQB company)
expressed some interest in carrying out qualification work on BlueZ without charging
any fees as part of their marketing.
So it's a good time to unite the efforts. We should probably start some project where
people could contribute test scripts and stuff.
I'm pretty sure that Sony and Inventel have done some work on it.
Any comments/suggestions/ideas from you guys ?
Thanks
Max
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 12:47 AM 3/7/2003, David LIBAULT wrote:
>This ACLsession program will help us do the L2CAP MTU negotiation test and
>we'll all see if fixing it in the main stream code is that much of a big
>deal, and what the 7layers BQB can reasonably accept.
>
>>
>> > 2) write a script for each test case
>>
>> Anybody willing to contribute that ?
>>
>
>Inventel can contribute with some test cases scripts using l2capsession.
>We'll do that if l2capsession "kind of way to do things" is retained. For the
>L2CAP tests (ACLsession) we have nothing yet.
>
>> It sounds like we need to create a module in CVS and start putting things
>> that we need together. Any suggestion for a name ? "qube" ?
Here you go.
I implemented aclsession and created one common build tree for
qualification utils.
QUBE - Qualification Utilities for BluEz
http://bluez.sourceforge.net/download/bluez-qube-0.1.tar.gz
(it has your l2session thing in there).
Max
At 12:47 AM 3/7/2003, David LIBAULT wrote:
>Le Jeudi 6 Mars 2003 23:06, Max Krasnyansky a =E9crit :
>> At 10:06 AM 3/3/2003, David LIBAULT wrote:
>> >> 2. Have own patches against the stable kernel for qualification
>> >
>> >IMHO, it is possible to have L2CAP qualified without messing up that mu=
ch
>> > the code, and without changing the behavior/performance when "the othe=
r
>> > side" is working properly.
>>
>> May be. But we don't seem to know that for sure. What about that L2CAP M=
TU
>> negotiation thing for example ?
>
>I propose that we take this issue as the first step to qualification.
Agreed.
>> >Next step : L2CAP qualification.
>> >
>> >The main issue is to have the tester side...
>> >
>> > 1) write a small user-mode program that can open and close an A=
CL
>> > channel, and send any kind of packet over this link
>>
>> Don't you guys have that already ? If not I'll write this one.
>> Do you have any specific features in mind ?
>
>I have sent to you a very small program (l2capsession.c). You can make it=20
>GPL. To make sure you have it, I have attached it to this message. This=20
>program uses as an input a very simple script file that tells what to send=
,=20
>to what address etc...
>
>BUT
>
>This is usable only for "over L2CAP" protocols like SDP, BNEP, RFCOMM etc.=
..
>To do L2CAP tests, we need the same type of application but that sends dat=
a=20
>directly over an ACL link. Is it a special type of socket that needs to be=
=20
>opened to do so ?
Yes raw HCI socket. I'll write that one.
>This ACLsession program will help us do the L2CAP MTU negotiation test and=
=20
>we'll all see if fixing it in the main stream code is that much of a big=20
>deal, and what the 7layers BQB can reasonably accept.
Ok.
>> > 2) write a script for each test case
>>
>> Anybody willing to contribute that ?
>>
>
>Inventel can contribute with some test cases scripts using l2capsession.=20
>We'll do that if l2capsession "kind of way to do things" is retained.=20
>For the L2CAP tests (ACLsession) we have nothing yet.
Sounds good.
>> It sounds like we need to create a module in CVS and start putting thing=
s
>> that we need together. Any suggestion for a name ? "qube" ?
Ok. I'll implement this ACL thing and add create cvs tree (including your l=
2session).
Max
=20
=20
Le Jeudi 6 Mars 2003 23:06, Max Krasnyansky a ?crit :
> At 10:06 AM 3/3/2003, David LIBAULT wrote:
> >> 2. Have own patches against the stable kernel for qualification
> >
> >IMHO, it is possible to have L2CAP qualified without messing up that much
> > the code, and without changing the behavior/performance when "the other
> > side" is working properly.
>
> May be. But we don't seem to know that for sure. What about that L2CAP MTU
> negotiation thing for example ?
I propose that we take this issue as the first step to qualification.
>
> >It anyway does not make sense to have one stack for qualification and one
> > stack for "real usage", as, in theory, only qualified bluetooth products
> > should be runing...
>
> Linux servers, workstations, laptops, etc are not "bluetooth products".
> Also we're not saying two stacks right. We're saying a separate package (or
> patch or whatever). And the only reason to have that package is if
> qualification support becomes ugly.
>
> >Bluez is one of the cleanest Bluetooth implementations, and is becoming
> > (or is already) a reference implementation. Lets qualify it !
>
> Sure. I'm with you.
>
> >> The same rules apply to the userspace utils and also to the userspace
> >> protocol implementations like SDP and OBEX.
> >>
> >> In general I think a qualified version of the BlueZ stack is a good
> >> idea, but this is also hard work and at this points comes the money
> >> problem in. The end user don't get any advantages of a qualified Linux
> >> Bluetooth (it only sounds great), but companies who plan to use BlueZ in
> >> their Bluetooth products will save a lot of time, money and knowledge if
> >> they don't have to qualify the complete stack again. If we really got
> >> BlueZ qualified and companies can take advantage of it I think that they
> >> should payback something to the OpenSource community. And at this point
> >> the idea of a non-profit organization which takes care of a qualified
> >> version of the BlueZ stack and represent the Linux fraction in the
> >> Bluetooth SIG comes to my mind.
> >
> >My interest as a company is to help having Bluez qualified. If once I have
> >suffered, for the qualification I have to pay someone again later there is
> >absolutely no interest in having Bluez qualified ! I just use Bluez as it
> > is and qualify it myself !
>
> Darn, no Volvo for me :(
>
> >I also think that having Bluez qualified is very small effort compared to
> > the one of developing a complete/robust/functional/performant stack. The
> > biggest effort has already been done by Maxim and other people, and it is
> > open source. Companies take more advantage from Bluez itself than from a
> > "qualified" Bluez. Qualification should be as the stack itself : open
> > source.
>
> I see another benefit of qualification. In order to get qualified we need a
> tool set that implements test cases and stuff. This toolset is pretty much
> a regression test suite which is always good to have.
>
> >> People that already have some experiences in qualification (and
> >> especially BlueZ) should start now sharing their results with us, so we
> >> can start planing the next step.
> >
> >Next step : L2CAP qualification.
> >
> >The main issue is to have the tester side...
> >
> > 1) write a small user-mode program that can open and close an ACL
> > channel, and send any kind of packet over this link
>
> Don't you guys have that already ? If not I'll write this one.
> Do you have any specific features in mind ?
I have sent to you a very small program (l2capsession.c). You can make it
GPL. To make sure you have it, I have attached it to this message. This
program uses as an input a very simple script file that tells what to send,
to what address etc...
BUT
This is usable only for "over L2CAP" protocols like SDP, BNEP, RFCOMM etc...
To do L2CAP tests, we need the same type of application but that sends data
directly over an ACL link. Is it a special type of socket that needs to be
opened to do so ?
This ACLsession program will help us do the L2CAP MTU negotiation test and
we'll all see if fixing it in the main stream code is that much of a big
deal, and what the 7layers BQB can reasonably accept.
>
> > 2) write a script for each test case
>
> Anybody willing to contribute that ?
>
Inventel can contribute with some test cases scripts using l2capsession.
We'll do that if l2capsession "kind of way to do things" is retained. For the
L2CAP tests (ACLsession) we have nothing yet.
> It sounds like we need to create a module in CVS and start putting things
> that we need together. Any suggestion for a name ? "qube" ?
>
> Max
At 08:35 PM 3/4/2003, Takashi Sasai wrote:
>I feel it's good to just confirm core functionarities (l2cap, sdp and gap for me).
That's one of the benefits of qualification effort that for example I as a developer
will get. And if helps companies that make devices based on Linux it's even better.
Max
At 10:06 AM 3/3/2003, David LIBAULT wrote:
>> 2. Have own patches against the stable kernel for qualification
>
>IMHO, it is possible to have L2CAP qualified without messing up that much the
>code, and without changing the behavior/performance when "the other side" is
>working properly.
May be. But we don't seem to know that for sure. What about that L2CAP MTU
negotiation thing for example ?
>It anyway does not make sense to have one stack for qualification and one stack
>for "real usage", as, in theory, only qualified bluetooth products should be
>runing...
Linux servers, workstations, laptops, etc are not "bluetooth products".
Also we're not saying two stacks right. We're saying a separate package (or patch or
whatever). And the only reason to have that package is if qualification
support becomes ugly.
>Bluez is one of the cleanest Bluetooth implementations, and is becoming (or is already)
>a reference implementation. Lets qualify it !
Sure. I'm with you.
>> The same rules apply to the userspace utils and also to the userspace
>> protocol implementations like SDP and OBEX.
>>
>> In general I think a qualified version of the BlueZ stack is a good
>> idea, but this is also hard work and at this points comes the money
>> problem in. The end user don't get any advantages of a qualified Linux
>> Bluetooth (it only sounds great), but companies who plan to use BlueZ in
>> their Bluetooth products will save a lot of time, money and knowledge if
>> they don't have to qualify the complete stack again. If we really got
>> BlueZ qualified and companies can take advantage of it I think that they
>> should payback something to the OpenSource community. And at this point
>> the idea of a non-profit organization which takes care of a qualified
>> version of the BlueZ stack and represent the Linux fraction in the
>> Bluetooth SIG comes to my mind.
>
>My interest as a company is to help having Bluez qualified. If once I have
>suffered, for the qualification I have to pay someone again later there is
>absolutely no interest in having Bluez qualified ! I just use Bluez as it is
>and qualify it myself !
Darn, no Volvo for me :(
>I also think that having Bluez qualified is very small effort compared to the
>one of developing a complete/robust/functional/performant stack. The biggest
>effort has already been done by Maxim and other people, and it is open
>source. Companies take more advantage from Bluez itself than from a
>"qualified" Bluez. Qualification should be as the stack itself : open source.
I see another benefit of qualification. In order to get qualified we need a tool
set that implements test cases and stuff. This toolset is pretty much a regression
test suite which is always good to have.
>> People that already have some experiences in qualification (and
>> especially BlueZ) should start now sharing their results with us, so we
>> can start planing the next step.
>
>Next step : L2CAP qualification.
>
>The main issue is to have the tester side...
>
> 1) write a small user-mode program that can open and close an ACL channel,
>and send any kind of packet over this link
Don't you guys have that already ? If not I'll write this one.
Do you have any specific features in mind ?
> 2) write a script for each test case
Anybody willing to contribute that ?
It sounds like we need to create a module in CVS and start putting things that
we need together. Any suggestion for a name ? "qube" ?
Max
At 07:48 AM 3/3/2003, Marcel Holtmann wrote:
>The BlueZ kernel modules are working perfect in conjunction with other
>devices and other stacks, but we have already seen that we need to add
>some quirks for passing the qualification and I agree completly with Max
>that is a bad idea to have things that don't makes sense, but are needed
>for a qualification.
That the biggest thing that concerns me about qualification. And that's where
separate package helps.
>We should start colleting these quirks and see how we handle them. At the moment
>I see two ways out of this problem:
>
>1. Include them into the kernel code and make them a compile option
That can be pretty ugly.
>2. Have own patches against the stable kernel for qualification
I guess by "separate package" I didn't necessarily mean tar.gz with
make install or whatever. It could be a patch.
>The same rules apply to the userspace utils and also to the userspace
>protocol implementations like SDP and OBEX.
For some reason I'm less concerned about ugliness in the user-space code ;-)
(must be because I'm a kernel guy). I'm just kidding of course.
>In general I think a qualified version of the BlueZ stack is a good
>idea, but this is also hard work and at this points comes the money
>problem in. The end user don't get any advantages of a qualified Linux
>Bluetooth (it only sounds great),
True. %99.9 percent of the Linux users couldn't care less whether Bluetooth
stack is qualified or not as long as it works correctly.
>but companies who plan to use BlueZ in their Bluetooth products will save a lot of time,
>money and knowledge if they don't have to qualify the complete stack again. If we really
>got BlueZ qualified and companies can take advantage of it I think that they should payback
>something to the OpenSource community.
Yeah, like buy a new Volvo SUV for me for example ;-)
>And at this point the idea of a non-profit organization which takes care of a qualified
>version of the BlueZ stack and represent the Linux fraction in the Bluetooth SIG comes to
>my mind.
I'm not sure about that. Might be a good idea.
Max
Hi,
> People that already have some experiences in qualification (and
> especially BlueZ) should start now sharing their results with us, so we
> can start planing the next step.
I checked a little ten months ago, but unfortunately I didn't need to
get qualification for now. However I can help and comment by
experiences personally.
Finally it seems that it's duty to sell products in order to get
interoperability and good quality. At least, any companies must do
testing for application profile using final products and get
quarification itself.
I don't know it's really useful, because codes will continue to change
and linux has various platforms, kernel version, CPU, even derivations
with some extensions. Can one quarification cover all of them?
I feel it's good to just confirm core functionarities (l2cap, sdp and
gap for me).
Regards,
Takashi
Le Lundi 3 Mars 2003 16:48, Marcel Holtmann a ?crit :
> Hi,
>
> > >Who is going to write the test report ?
> > >Is Bluez going to be listed as official Bluetooth qualified stack ?
> >
> > I don't know. That's what we need to discuss.
> > There are many questions (at least in my mind) like
> > - Does it make sense to have qualified stack in the official kernel ?
> > Like I mentioned before I don't want to add things that simply don't make
> > sense for general stack operation only because we want to pass
> > qualification (I'm talking mostly about kernel stuff here).
> > In which case a separate qualified kernel package with the same API as
> > mainstream kernel make sense.
> >
> > - What happens when we make changes to the stack ? Have to qualify again
> > ?
>
> the first thing here is that we must differ between the kernel modules
> and the userspace utitlities. Question is what make really sense to
> qualify and what kind of userspace programs need to be qualified? I
> think for the beginning we should concentrate only on HCI and L2CAP and
> we should go along with stable releases of the 2.4 kernel. And the best
> Kernel to start with is for me the not yet released 2.4.21. Sticking to
> an external Kernel package is very ugly because it needs to be
> maintained and this is a job that can not be done by any of us at the
> moment and in general it does not make sense to double the work.
>
> Getting a qualification for all new 2.4 kernel should be easy, because
> we mostly don't change things in the core layers and bugfixes didn't
> need to be qualified again if I am right. If we do a big change or add
> new features we have to qualify again, so we should automate as most
> things as we can to make this easy and fast. I think that the time
> between the 2.4 kernel releases is a good gap and it will grow bigger
> after the 2.6 comes out and we should completly forget about to qualify
> a 2.6 in the first six month. The userspace component looks mostly the
> same. Most big changes are done for SDP and PAN in the last months.
>
> The BlueZ kernel modules are working perfect in conjunction with other
> devices and other stacks, but we have already seen that we need to add
> some quirks for passing the qualification and I agree completly with Max
> that is a bad idea to have things that don't makes sense, but are needed
> for a qualification. We should start colleting these quirks and see how
> we handle them. At the moment I see two ways out of this problem:
>
> 1. Include them into the kernel code and make them a compile option
>
> 2. Have own patches against the stable kernel for qualification
IMHO, it is possible to have L2CAP qualified without messing up that much the
code, and without changing the behavior/performance when "the other side" is
working properly. It anyway does not make sense to have one stack for
qualification and one stack for "real usage", as, in theory, only qualified
bluetooth products should be runing... Bluez is one of the cleanest Bluetooth
implementations, and is becoming (or is already) a reference implementation.
Lets qualify it !
>
> The same rules apply to the userspace utils and also to the userspace
> protocol implementations like SDP and OBEX.
>
> In general I think a qualified version of the BlueZ stack is a good
> idea, but this is also hard work and at this points comes the money
> problem in. The end user don't get any advantages of a qualified Linux
> Bluetooth (it only sounds great), but companies who plan to use BlueZ in
> their Bluetooth products will save a lot of time, money and knowledge if
> they don't have to qualify the complete stack again. If we really got
> BlueZ qualified and companies can take advantage of it I think that they
> should payback something to the OpenSource community. And at this point
> the idea of a non-profit organization which takes care of a qualified
> version of the BlueZ stack and represent the Linux fraction in the
> Bluetooth SIG comes to my mind.
My interest as a company is to help having Bluez qualified. If once I have
suffered, for the qualification I have to pay someone again later there is
absolutely no interest in having Bluez qualified ! I just use Bluez as it is
and qualify it myself !
I also think that having Bluez qualified is very small effort compared to the
one of developing a complete/robust/functional/performant stack. The biggest
effort has already been done by Maxim and other people, and it is open
source. Companies take more advantage from Bluez itself than from a
"qualified" Bluez. Qualification should be as the stack itself : open source.
>
> People that already have some experiences in qualification (and
> especially BlueZ) should start now sharing their results with us, so we
> can start planing the next step.
Next step : L2CAP qualification.
The main issue is to have the tester side...
1) write a small user-mode program that can open and close an ACL channel,
and send any kind of packet over this link
2) write a script for each test case
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
> >Now I don't relay know who you are and what your involvement with
> >BlueZ is, please could you drop me a few lines of introduction. Also I'd
> >like to know how having a qualified BlueZ would help you so I can focus on
> >the value.
> I guess I don't have to introduce myself ;-).
I think the same apply to me ;)
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
> >Who is going to write the test report ?
> >Is Bluez going to be listed as official Bluetooth qualified stack ?
> I don't know. That's what we need to discuss.
> There are many questions (at least in my mind) like
> - Does it make sense to have qualified stack in the official kernel ?
> Like I mentioned before I don't want to add things that simply don't make
> sense for general stack operation only because we want to pass qualification
> (I'm talking mostly about kernel stuff here).
> In which case a separate qualified kernel package with the same API as mainstream
> kernel make sense.
>
> - What happens when we make changes to the stack ? Have to qualify again ?
the first thing here is that we must differ between the kernel modules
and the userspace utitlities. Question is what make really sense to
qualify and what kind of userspace programs need to be qualified? I
think for the beginning we should concentrate only on HCI and L2CAP and
we should go along with stable releases of the 2.4 kernel. And the best
Kernel to start with is for me the not yet released 2.4.21. Sticking to
an external Kernel package is very ugly because it needs to be
maintained and this is a job that can not be done by any of us at the
moment and in general it does not make sense to double the work.
Getting a qualification for all new 2.4 kernel should be easy, because
we mostly don't change things in the core layers and bugfixes didn't
need to be qualified again if I am right. If we do a big change or add
new features we have to qualify again, so we should automate as most
things as we can to make this easy and fast. I think that the time
between the 2.4 kernel releases is a good gap and it will grow bigger
after the 2.6 comes out and we should completly forget about to qualify
a 2.6 in the first six month. The userspace component looks mostly the
same. Most big changes are done for SDP and PAN in the last months.
The BlueZ kernel modules are working perfect in conjunction with other
devices and other stacks, but we have already seen that we need to add
some quirks for passing the qualification and I agree completly with Max
that is a bad idea to have things that don't makes sense, but are needed
for a qualification. We should start colleting these quirks and see how
we handle them. At the moment I see two ways out of this problem:
1. Include them into the kernel code and make them a compile option
2. Have own patches against the stable kernel for qualification
The same rules apply to the userspace utils and also to the userspace
protocol implementations like SDP and OBEX.
In general I think a qualified version of the BlueZ stack is a good
idea, but this is also hard work and at this points comes the money
problem in. The end user don't get any advantages of a qualified Linux
Bluetooth (it only sounds great), but companies who plan to use BlueZ in
their Bluetooth products will save a lot of time, money and knowledge if
they don't have to qualify the complete stack again. If we really got
BlueZ qualified and companies can take advantage of it I think that they
should payback something to the OpenSource community. And at this point
the idea of a non-profit organization which takes care of a qualified
version of the BlueZ stack and represent the Linux fraction in the
Bluetooth SIG comes to my mind.
People that already have some experiences in qualification (and
especially BlueZ) should start now sharing their results with us, so we
can start planing the next step.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel