[BK 1/6] 2.5.x Bluetooth subsystem update. Core.

[BK 1/6] 2.5.x Bluetooth subsystem update. Core.

[Maksim (Max) Krasnyanskiy]

Hi Linus,

Here is the set of patches to sync up 2.5.x Bluetooth subsytem with
2.4.x and add latest fixes and features.

You can either pull all of them from:
	bk://linux-bt.bkbits.net/bt-2.5

Or apply them indivdually. Patches are pretty big and therefor not
inlined.

Patch #1:
   
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or
higher.
# This patch includes the following deltas:
#	           ChangeSet	1.597   -> 1.598  
#	net/bluetooth/hci_event.c	1.1     -> 1.2    
#	 net/bluetooth/lib.c	1.3     -> 1.4    
#	net/bluetooth/af_bluetooth.c	1.4     -> 1.5    
#	 net/bluetooth/sco.c	1.2     -> 1.3    
#	net/bluetooth/hci_core.c	1.6     -> 1.7    
#	include/net/bluetooth/bluetooth.h	1.4     -> 1.5    
#	include/net/bluetooth/hci_core.h	1.3     -> 1.4    
#	net/bluetooth/hci_sock.c	1.5     -> 1.6    
#	net/bluetooth/l2cap.c	1.6     -> 1.7    
#	include/net/bluetooth/hci.h	1.3     -> 1.4    
#	net/bluetooth/hci_conn.c	1.1     -> 1.2    
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/10/04	root@viper.(none)	1.598
# Sync up Bluetooth core with 2.4.x.
# SMP locking fixes. 
# Support for Hotplug.
# Support for L2CAP connectionless channels (SOCK_DGRAM).
# HCI filter handling fixes.
# Other minor fixes and cleanups.
# --------------------------------------------

http://bluez.sourceforge.net/patches/bt-2.5-core.gz

Max

Re: [BK 1/6] 2.5.x Bluetooth subsystem update. Core.

[Linus Torvalds]

On 5 Oct 2002, Maksim (Max)  Krasnyanskiy wrote:
> 
> You can either pull all of them from:
> 	bk://linux-bt.bkbits.net/bt-2.5

Ok, pulled. But _please_ do this the regular way next time. There's even a 
script to help you do it in linux/Documentation/BK-usage/bk-mak-sum, which 
does it all for you for BK patches.

(many people end up doing their own thing, you don't have to use that
particular script, of course. But the important thing I want is that the
_email_ should contain enough information to make a good first pass
judgement on what the patch does, and in particular it is important for me
to see what a "bk pull" will actually change.)

That's why the "diffstat" is important to me if I do a BK pull - and why I 
want to see the patches as plaintext if I apply stuff to generic files.. 

So:
 - if you use BK (which is great - your tree looked fine and the only real 
   problem was that I had to verify it separately by hand first), please 
   send one email for the "bk pull", and include a diffstat for the whole 
   thing in that one email.

 - if you use patches, please send them as clear-text in the email itself, 
   and don't think that I want to go fetch them separately from some other 
   site.

For optimal exposure, do both - this is what Greg KH does for USB stuff
(he sends the BK email to me and to the kernel list, and sends individual
patches to the kernel list only). Which really helps the people who don't
want to use BK for some reason.

			Linus