public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Hendrik Sattler <post@hendrik-sattler.de>
Cc: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] SDP services cannot be unregistered
Date: Thu, 20 Dec 2007 16:08:52 +0100	[thread overview]
Message-ID: <1198163332.8050.250.camel@aeonflux> (raw)
In-Reply-To: <20071220102046.7h0duacmskwgkc8g@v1539.ncsrv.de>

Hi Hendrik,

> > first of all you are using the unregister function wrongly. You have to
> > give it the exact record structure you gave the register function. So
> > when you allocate a new record, then the unregister has no idea what to
> > do with it.
> 
> bt_sdp_obexpush() does create a new record structure but with the  
> exact same parameters (actually no variable parameters at all). The  
> resulting records should fully match, at least I assume that. The  
> record ID is then stored in the session_t value, I assume.
> Or are pointer addresses matched, too?

doesn't work like that. The magic is the record->handle and nothing
else. However that might change. So the safest way is to have a static
variable for the record that stores it for the lifetime of the daemon.

> > Why it doesn't cleanup after program termination is unclear to me. That
> > should actually work. You might wanna investigate on that one.
> 
> Before this came up, I did not unregister or close at all and  
> everything was fine when the program was killed (SDP record was gone).
> Can you give me a hint where this is actually processed, bluez-libs or  
> bluez-utils?

It is processed in bluez-utils/sdpd/, but be aware of that this code is
really tricky. I am about to actually remove it at some point. Not sure
when and how though.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2007-12-20 15:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-19 22:41 [Bluez-devel] SDP services cannot be unregistered Hendrik Sattler
2007-12-19 23:34 ` Marcel Holtmann
     [not found]   ` <200712200229.40589.post@hendrik-sattler.de>
2007-12-20  2:09     ` Marcel Holtmann
2007-12-20  9:20       ` Hendrik Sattler
2007-12-20 15:08         ` Marcel Holtmann [this message]
2007-12-20 21:40       ` Hendrik Sattler
2007-12-20 23:12         ` Marcel Holtmann
2007-12-20  9:59   ` [Bluez-devel] Multi-device : maximizing the number of concurrent ourgoing RFCOMM connections Olivier Le Pogam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1198163332.8050.250.camel@aeonflux \
    --to=marcel@holtmann.org \
    --cc=bluez-devel@lists.sourceforge.net \
    --cc=post@hendrik-sattler.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox