Re: [Bluez-devel] Questions about BlueZ in commercial use

[Marcel Holtmann <marcel@holtmann.org>]

Hi Nicholas,

> > the current USB subsystem (as of 2.6.7) is not as bad as you think.
> > Actually it is working very nice and even the hci_usb driver didn't
> > crash anymore. Anyhow the problem is not USB. We made all of them by
> > ourself :(
> 
> I think the problem is USB. It is too complicated for the least cost
> market. So many manufacturers built chips or firmware for USB devices
> which are not spec compliant. Additionaly there are so many bad 
> programmed driver.

I had a small chat with Oliver Neukum about some design issues of the
USB subsystem. And yes, some parts are too complex and some companies
are unable to read specifications and understand them the right way. The
problem is that you can't prevent this.

Even in the case of Bluetooth where the qualifications tests are very
complex and try to test every aspect of a bad implementation. Some
devices are broken, but they are still qualified and must work.

On the other side parts of the specifications are bad. I may remind you
of our discussion on who has to terminate the ACL link if no other
protocol or application is using it.

> I think this is a design failure, even if it only appears as bad driver
> implementations.

The Bluetooth USB (H:2) devices are a little bit complex. A design must
grow along the needs of the real USB devices. The USB guys are now aware
of it and you can expect changes within the 2.7 kernel lifetime.

> > I really like the Debian way of forking a stable version and only doing
> > security or bugfixes. The problem is that this needs a lot of man power
> > and costs a lot of time. I know what I am talking about, because I did
> > all the 2.4 kernel backports of the Bluetooth subsystem.
> 
> A company would need to do this for the version they use in production
> systems only. So it should be possible.

Yes thats right, but from my point a specific company fork won't drive
the community forwards. This actually depends of course on how the
company talks back to us.

> > If we got a number of companies that help sponsoring the BlueZ itself
> > and its official qualification I can think of such a fork. At that point
> > it makes sense to me and is worth the extra work.
> 
> I didn't thought of you maintaining such a stable fork. But like in the
> debian project, the developers who need this high quality standard, care
> for the branch themselves. Then you need to assure only, that all fixes you
> apply are documented and published, even if you fix them with a new feature
> that doesn't go into the stable tree.

We use Bitkeeper for the kernel trees and CVS for the BlueZ library and
utils. I think everything like this is quite well documented.

However this is not the first time I talked about a fork. One year ago
or so when WideRay starts to qualify there BlueZ based product we also
talked about the qualifcation needs. It will be necessary to fork a
qualified version of BlueZ and you need someone who maintains it. This
must not me, but this is a fork that I will support. For other forks you
better should convince me that its worth ;)

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel