Re: [Bluez-devel] BlueZ Qualification

[Max Krasnyansky <maxk@qualcomm.com>]

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