All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suraj <suraj@Atheros.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Suraj Sumangala <Suraj.Sumangala@Atheros.com>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	Jothikumar Mothilal <Jothikumar.Mothilal@Atheros.com>
Subject: Re: [RFC v2] Bluetooth: Provide access to reassembled Rx packets
Date: Tue, 27 Jul 2010 10:18:13 +0530	[thread overview]
Message-ID: <4C4E650D.4080806@Atheros.com> (raw)
In-Reply-To: <1280184169.2621.63.camel@localhost.localdomain>

Hi Marcel,

On 7/27/2010 4:12 AM, Marcel Holtmann wrote:

> So first of all, lets make something perfectly clear. All Bluetooth
> drivers are _transport_ drivers. They don't need to know what they are
> transporting. And in addition you should not look into the packets that
> you are sending or receiving. The Bluetooth core does that HCI packet
> parsing.
>
> This is how I want it and how this is going to stay. Everything else is
> an insane approach and cost every single driver overhead. In addition
> the lifetime rules of SKBs become more and more complicated. That is a
> pretty bad thing. It will result in excessive memory usage and will
> cause problems.

I understand the point that you are making. But If I am not mistaken, 
HCI transport driver is the only part of the system that could be vendor 
specific ( HCI ATH3K, HCI LL etc). So a vendor specific command or event 
makes more sense to a transport driver than anybody else.

Is there anyway this requirement can be sufficed without causing the 
issues you have mentioned above?
>
> Regards
>
> Marcel
>
>

Regards
Suraj

  parent reply	other threads:[~2010-07-27  4:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-26  6:34 [RFC v2] Bluetooth: Provide access to reassembled Rx packets Suraj Sumangala
2010-07-26 15:13 ` Marcel Holtmann
2010-07-26 18:23   ` Suraj
2010-07-26 22:42     ` Marcel Holtmann
2010-07-27  2:23       ` Suraj
2010-07-27  4:48       ` Suraj [this message]
2010-07-27  5:14         ` Marcel Holtmann
2010-07-27 15:36           ` Suraj

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=4C4E650D.4080806@Atheros.com \
    --to=suraj@atheros.com \
    --cc=Jothikumar.Mothilal@Atheros.com \
    --cc=Suraj.Sumangala@Atheros.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.