[<prev] [next>] [day] [month] [year] [list]
Message-ID: <AANLkTikh5vAYIMMIbyMTfnh_SKr7AlOC9yZipHzzNhlW@mail.gmail.com>
Date: Mon, 19 Jul 2010 11:54:43 -0700
From: "Luis R. Rodriguez" <mcgrof@...il.com>
To: Patrick McManus <mcmanus@...ksong.com>
Cc: Kevin Hayes <kevin@...eros.com>,
Marcel Holtmann <marcel@...tmann.org>,
Johannes Berg <johannes@...solutions.net>,
"John W. Linville" <linville@...driver.com>,
Jouni Malinen <Jouni.Malinen@...eros.com>,
Sujith <Sujith.Manoharan@...eros.com>,
linux-kernel@...r.kernel.org, Dan Tian <Dan.Tian@...eros.com>
Subject: Re: Existing netlink kernel <--> kernel communication
On Mon, Jul 19, 2010 at 9:07 AM, Patrick McManus <mcmanus@...ksong.com> wrote:
> Hi Luis,
>
> I'm following up to a linux kernel post of yours back in December:
>
> http://marc.info/?l=linux-kernel&m=125053428528207&w=3
>
> Basically, I have the same interest - an internal netlink client to the
> qdisc interfaces.. I was wondering if you made any progress on the topic
> you could share? It seems maddening that netlink is promoted as an
> intra-kernel mechanism but it is non-obvious how to write a client..
The reason we at Atheros were considering it was a possible way to
communicate between two different subsystems, in our case Bluetooth
and 802.11. While it is technically possible to use netlink for such
purposes it introduces a layer of complexity which can be avoided by
just using direct exported routines, and by coordinating between the
two subsystems you need communication with.
So, the real question I think is why do you need a rigid API ? If
there is a good need, perhaps its a good idea, but so far I guess no
one simply has come up with one.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists