From: Ulisses Furquim <ulisses@profusion.mobi>
To: Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com>,
Ulisses Furquim <ulisses@profusion.mobi>,
marcel@holtmann.org, linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH] Bluetooth: Change chan_ready param from sk to chan
Date: Thu, 26 Jan 2012 20:30:08 -0200 [thread overview]
Message-ID: <CAA37ikY8v2Rtg7_E1doCaYSMsOATukQOqMbcse9Z3j4a2qKPBA@mail.gmail.com> (raw)
In-Reply-To: <20120126090028.GA3300@aemeltch-MOBL1>
Hi Andrei,
On Thu, Jan 26, 2012 at 7:00 AM, Emeltchenko Andrei
<Andrei.Emeltchenko.news@gmail.com> wrote:
> Hi Ulisses,
>
> On Thu, Jan 26, 2012 at 01:04:06AM -0200, Ulisses Furquim wrote:
>> > From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
>> >
>> > Change is needed to remove dependency on sk when possible
>> > before introducing l2cap channel lock.
>>
>> What's the overall idea? We used to rely on sk lock for mutual
>> exclusion, right? (please correct me if I'm wrong) I'm seeing some
>> patches from you to change from sk to chan but introducing another
>> lock might shake things a bit so that's why I'm asking for the big
>> picture, if you have thought this through already.
>
> Basically it is known that current implementation of some higher level
> protocols like RFCOMM using kernel sockets is not the right way and shall
> be changed at some point.
>
> I've implemented basic A2MP protocol as a kernel socket and Marcel gave m=
e
> suggestion to move from sockets to internal L2CAP functions.
>
> I've done this and since everything is locked with sk and obviously we do
> not have socket I have to use following constructions:
>
> <------8<-------------------
> | =A0if (sk)
> | =A0 =A0 =A0 =A0 =A0lock_sock(sk)
> | =A0...
> | =A0if(sk)
> | =A0 =A0 =A0 =A0 =A0release_sock(sk)
> |
> <------8<-------------------
>
> which does not look nice and might be racy. Then comes idea to change
> socket lock for L2CAP protocol to e.g. l2cap_channel_{lock,unlock}.
Will you completely change one lock for the other?
> I have code which works but some parts looks like hacks so I try to polis=
h
> it a bit and send as RFC. Please give me comments if you think this might
> be done other way.
Ok, let's see your patch series on that. I haven't thought about it
and seeing your proposal might be good.
Best regards,
--=20
Ulisses Furquim
ProFUSION embedded systems
http://profusion.mobi
Mobile: +55 19 9250 0942
Skype: ulissesffs
prev parent reply other threads:[~2012-01-26 22:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-25 14:09 [PATCH] Bluetooth: Change chan_ready param from sk to chan Emeltchenko Andrei
2012-01-26 3:04 ` Ulisses Furquim
2012-01-26 9:00 ` Emeltchenko Andrei
2012-01-26 22:30 ` Ulisses Furquim [this message]
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=CAA37ikY8v2Rtg7_E1doCaYSMsOATukQOqMbcse9Z3j4a2qKPBA@mail.gmail.com \
--to=ulisses@profusion.mobi \
--cc=Andrei.Emeltchenko.news@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=marcel@holtmann.org \
/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;
as well as URLs for NNTP newsgroup(s).