[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] Connection management problem : modifications + bug corrected



uh oh, didn't see that the code wasn't _in_ bt_disconnect_ind... 
my mistake !. See why a diff is better ? ;)
/Mattias

> -----Original Message-----
> From: Mattias Ågren [mailto:mattias@xxxxxxx.com]
> Sent: den 1 augusti 2001 09:39
> To: 'david LIBAULT'
> Cc: bluetooth-dev@xxxxxxx.com
> Subject: RE: [bluetooth-dev] Connection management problem :
> modifications + bug corrected
> 
> 
> 
> > 
> > Le Mardi 31 Juillet 2001 16:49, Mattias Ågren a écrit :
> > > Hi,
> > > can you please make a 'cvs diff -udw rfcomm.c' instead ?
> > > It is easier to see your changes.
> > >
> > > > bt_disconnect_ind(CREATE_RFCOMM_ID(rfcomm->line,
> > > > 							
>    tmp_dlci));
> > > > //dli
> > > > #ifdef __KERNEL__
> > > > 			bt_unregister_rfcomm(rfcomm->line);
> > > > #endif
> > > > 		}
> > > > 		D_CTRL(FNC"DISC, sending back UA\n");
> > > >
> > > > 		break;
> > >
> > > Isn't it nicer if rfcomm.c handles the call for 
> > bt_unregister_rfcomm ?
> > 
> > What do you mean ? bt_unregister_rfcomm is in bluetooth.c it 
> > is called in 
> > rfcomm.c (your design)...
> > 
> 
> Yes, bt_unregister_rfcomm is called in rfcomm.c as it is now, but your
> proposal was too put the bt_unregister_rfcomm call in 
> bt_disconnect_ind,
> right ?
> 
> By the way, we will change the bt_register/unregister so that 
> it will be
> general for any layer, not only rfcomm...  it will be something like
> 
> bt_register_ch(line, protocol type, prototocol specific 
> struct) / bt_unregister_ch(...).
> 
> Comments ?
> 
> Still, I would be great with a diff of your code to see what you
> wanted to change.
> 
> brgds
> Mattias
> -
> To unsubscribe from this list: send the line "unsubscribe 
> bluetooth-dev" in
> the body of a message to majordomo@xxxxxxx.com
> 
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com