public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com>
To: Ulisses Furquim <ulisses@profusion.mobi>
Cc: Mat Martineau <mathewm@codeaurora.org>,
	Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	Marcel Holtmann <marcel@holtmann.org>,
	Peter Krystad <pkrystad@codeaurora.org>,
	linux-bluetooth@vger.kernel.org
Subject: Re: Getting L2CAP ERTM support into better upstream state
Date: Thu, 9 Feb 2012 12:53:23 +0200	[thread overview]
Message-ID: <20120209105321.GA22374@aemeltch-MOBL1> (raw)
In-Reply-To: <CAA37ikb5n0PmR7FAZ2-HDRRoKaMEL=_nniuN9Yzm1pCjUk1kPw@mail.gmail.com>

Hi all,

On Wed, Feb 08, 2012 at 11:01:16PM -0200, Ulisses Furquim wrote:
...
> >> Marcel mentioned the separation of L2CAP channel and socket. That is a
> >> work in progress by Andrei and judging by what you said, Marcel, you
> >> want that merged before we change ERTM, is that it?
> >
> > Andrei and Marcel, let's figure out this order now.  It doesn't make sense
> > for one of us to have a bunch of changes staged, only to have major
> > merge/rebase conflicts when another far-reaching patch set gets merged.
> 
> I'd say we add your changes and then Andrei's when he's ready with
> them. Right now I have the feeling your changes are more mature and
> can be easily merged.

I believe that those mentioned state changes should not affect lock
separation patches.

Locking is done when receiving data packet in l2cap_data_channel and the
changes shall come to functions surrounded by those locks. The same with
sending packet functionality.

...
> > Thanks for the feedback, everyone.  Please let me know if you have
> > preferences for how to structure this patch set.  I'll work on the issues
> > mentioned in this thread and start splitting up the changes.
> 
> We need to hear from Marcel and Padovan if they agree with us. I do
> think you can introduce new stuff with small commits and then have one
> commit to add the bulk of it with the module option to enable it. Then
> we test that and make it default later.

Thanks Mat for work you have done. I am generally agree with Ulisses about
small logical commits (better if they compile without warnings). But if
there are changes that might be applied as is (like the patch Luiz has
sent concerning tx_window) that would be even better.

Best regards 
Andrei Emeltchenko 

  reply	other threads:[~2012-02-09 10:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-08  5:27 Getting L2CAP ERTM support into better upstream state Marcel Holtmann
2012-02-08  9:09 ` Andrei Emeltchenko
2012-02-08  9:32   ` Luiz Augusto von Dentz
2012-02-08 11:16     ` Ulisses Furquim
2012-02-08 22:33       ` Mat Martineau
2012-02-09  1:01         ` Ulisses Furquim
2012-02-09 10:53           ` Andrei Emeltchenko [this message]
2012-02-10 12:54           ` Gustavo Padovan
2012-02-10 13:49             ` Ulisses Furquim
2012-02-10 16:54               ` Mat Martineau
2012-02-09  7:13         ` Marcel Holtmann

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=20120209105321.GA22374@aemeltch-MOBL1 \
    --to=andrei.emeltchenko.news@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=mathewm@codeaurora.org \
    --cc=pkrystad@codeaurora.org \
    --cc=ulisses@profusion.mobi \
    /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