[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20070406235339.GA4177@sortiz.org>
Date: Sat, 7 Apr 2007 02:53:39 +0300
From: Samuel Ortiz <samuel@...tiz.org>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org, irda-users@...ts.sourceforge.net
Subject: Re: [PATCH 1/4] [net-2.6.22] IrDA: IrLAP raw mode
On Fri, Mar 16, 2007 at 08:34:51PM -0700, David Miller wrote:
> From: Samuel Ortiz <samuel@...tiz.org>
> Date: Sat, 17 Mar 2007 03:57:29 +0200
>
> > This patch allows us to bypass the IrDA stack down to the IrLAP level.
> > Sending and receiving frames is done through a character device.
> > This is useful for e.g. doing real IrDA sniffing, testing external IrDA
> > stacks and for Lirc (once I will add the framing disabling switch).
> >
> > Signed-off-by: Samuel Ortiz <samuel@...tiz.org>
>
> I understand the idea, but I fail to see any reason this should not be
> done with sockets.
>
> Everywhere else we provide this kind of functionality it is either
> with netlink (nf_queue etc.) or raw sockets of some kind
> (AF_INET/SOCK_RAW, AF_PACKET, etc.)
>
> Therefore IRDA should really provide this facility in some similar
> manner.
I definitely agree here. Actually, you can already sniff IrDA packets through
an AF_PACKET socket, that's what irdadump does. My patch was useless, forget
about it...
I have a question though: On top of the regular IrDA sniffing done with a
simple AF_PACKET socket, I also would like to be able to disable TX at the
IrLAP level (typically, this would allow an IrDA device to listen to all
the packets from an IrDA link without being noticed by the other devices).
I was thinking of adding a protocol private ioctl (as in SIOCPROTOPRIVATE) to
let userspace toggle an IrLAP flag (one per IrLAP instance) that would
disable a specific IrDA device TX path.
Would that be an acceptable solution, or would you rather see a netlink socket
for that purpose ?
Cheers,
Samuel.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists