Hi Andrei,
On Thu, Jan 26, 2012 at 7:00 AM, Emeltchenko Andrei
<Andrei.Emeltchenko.news@xxxxxxxxx> wrote:
> Hi Ulisses,
>
> On Thu, Jan 26, 2012 at 01:04:06AM -0200, Ulisses Furquim wrote:
>> > From: Andrei Emeltchenko <andrei.emeltchenko@xxxxxxxxx>
>> >
>> > 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 me
> 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<-------------------
> | if (sk)
> | lock_sock(sk)
> | ...
> | if(sk)
> | release_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 polish
> 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,
--
Ulisses Furquim
ProFUSION embedded systems
http://profusion.mobi
Mobile: +55 19 9250 0942
Skype: ulissesffs
--
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
