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

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



Le Mercredi 01 Août 2001 09:38, Mattias Ågren a écrit :
> > 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 ?

No, bt_unregister_rfcomm is called from rfcomm_receive_data in the DISC case 
(as before) but also when the dlci != 0. The change in bluetooth.c concerns 
only the "strange pid value check" that I have to figure out.

>
> 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