Hi Nami, 2011/6/21 Li, Nami <nami@xxxxxxxxxxxxxxxx>: > Hi, Luiz > > -----Original Message----- > From: Luiz Augusto von Dentz [mailto:luiz.dentz@xxxxxxxxx] > Sent: 2011年6月21日 17:48 > To: Li, Nami > Cc: linux-bluetooth@xxxxxxxxxxxxxxx > Subject: Re: [PATCH obexd] Fix crash introduced by f5279bfcedd669bc5d4e88cc1c59807c92226dfb > > Hi Nami, > > 2011/6/21 Li, Nami <nami@xxxxxxxxxxxxxxxx>: >> Hi, >> >> -----Original Message----- >> From: linux-bluetooth-owner@xxxxxxxxxxxxxxx >> [mailto:linux-bluetooth-owner@xxxxxxxxxxxxxxx] On Behalf Of Luiz >> Augusto von Dentz >> Sent: 2011年6月21日 16:38 >> To: linux-bluetooth@xxxxxxxxxxxxxxx >> Subject: [PATCH obexd] Fix crash introduced by >> f5279bfcedd669bc5d4e88cc1c59807c92226dfb >> >> From: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx> >> >> The callback function actually needs the bluetooth_service structure not obex_service_driver. >> --- >> plugins/bluetooth.c | 11 +++++++++-- >> 1 files changed, 9 insertions(+), 2 deletions(-) >> >> diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c index >> fe508f4..1037b24 100644 >> --- a/plugins/bluetooth.c >> +++ b/plugins/bluetooth.c >> @@ -459,10 +459,11 @@ static int request_service_authorization(struct >> bluetooth_service *service, >> >> static void confirm_event(GIOChannel *io, void *user_data) { >> - struct bluetooth_service *service = user_data; >> + struct bluetooth_service *service; >> GError *err = NULL; >> char address[18]; >> uint8_t channel; >> + struct obex_service_driver *driver = user_data; >> >> bt_io_get(io, BT_IO_RFCOMM, &err, >> BT_IO_OPT_DEST, address, @@ -477,7 +478,13 @@ >> static void confirm_event(GIOChannel *io, void *user_data) >> info("bluetooth: New connection from: %s, channel %u", address, >> channel); >> >> - if (service->driver->service != OBEX_OPP) { >> + service = find_service(driver, 0); >> >> Will it be better to write as "service = find_service(driver, channel);" ? >> Or if you choose not to use channel, I think you could omit channel >> variable and omit bt_io_get(BT_IO_OPT_CHANNEL, &channel); > >>I only leave the channel there for logging, as for the find_service it is really useless to use the channel if we are going to support L2CAP in future, so in theory this should work regardless of the transport. > > > Yeah, it`s better when support L2CAP. If the channel is only use for logging, can we delete it? > There are only two functions calling find_service, one in your commit , another in register_record function: > service = find_service(driver, 0); > Seems the channel parameter is useless. > And considering OBEX over L2CAP, should we modify find_service to > static struct bluetooth_service *find_service(struct obex_service_driver *driver) > just delete uint8_t channel parameter. > If ok, you or me can upload a patch for this issue. Yep, I gonna send a new version that just remove it since we no longer need it after this changes -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
