Two things:
- mbus can be NULL (in case of bus removal while reader is reading)
- Remove a useless assignment
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
diff -urp -X dontdiff linux-2.6.23-rc3-gregkh/drivers/usb/mon/mon_main.c
linux-2.6.23-rc3-gregkh-pipe/drivers/usb/mon/mon_main.c
--- lin
Setup packet must be visible in virtual space. There's absolutely no
good reason to implement any kind of zero-copy transfer of 8 bytes, and
the documentation in usb.h is explicit about it. So, drop DMA remapping.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
diff -urp -X dontdiff linux-2.6.23-
This is a set of small updates to Alan's work to make the code more to
my liking. Mostly premature optimizations, but also direction of control
transfers in the binary interface was always out.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
diff -urp -X dontdiff linux-2.6.23-rc3-gregkh/drivers/u
Add a class which allows for an easier integration with udev.
This code was originally written by Paolo Abeni, and arrived to my tree
as a part of big patch to add binary API on December 18. As I understand,
Paolo always meant the class to be a part of the whole thing. This is his
udev rule to go
On Thu, Apr 12, 2007 at 11:16:47PM -0700, Pete Zaitcev wrote:
> Add a class which allows for an easier integration with udev.
>
> Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
>
> ---
>
> Greg:
>
> This patch falls back onto device_create with NULL parent, because
> of bus0. Obviously, no rea
On Fri, 13 Apr 2007 09:27:59 +0200, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> p.s. BTW I saw your submission for 'usbmon: bus zero' and
> and 'usbmon: Add class for binary interface'.
>
> I don't want to seam rude, but I hoped to get a 'Signed-off-by' in one
> of them...
Reply to them and sign
Hello,
On Tue, 2007-04-10 at 23:42 -0700, Pete Zaitcev wrote:
> > - char flag_setup;
> > + char flag_hdr;
>
> I don't think this is fully compatible.
Why ?!? 'flag_hdr' is zero in exactly the same situation of old api. It
can assume more values that are interpreted by old code as signal of
s
Add a class which allows for an easier integration with udev.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
---
Greg:
This patch falls back onto device_create with NULL parent, because
of bus0. Obviously, no real USB bus corresponds to it. I thought it
not as pretty to have all the real class
Add the "bus zero" feature to the usbmon. If a user process specifies bus
with number zero, it receives events from all buses. This is useful when
we wish to see initial enumeration when a bus is created, typically after
a modprobe. Until now, an application had to loop until a new bus could
be ope
On Wed, 28 Mar 2007 10:33:23 +0200, [EMAIL PROTECTED] wrote:
> on 27/03/07 20:25 Pete Zaitcev wrote:
> > [ISO packet descriptor]
> > My current patch (see below) puts them
> > into data
> There is a potential issue with the byte ordering, from an application point
> of view. With the current upst
hello,
I just noticed that the patch I posted in the previous message was
broken due to line wrapping, so I re-post it.
Some more details about the patch: the urb information are split across
multiple events. For example, for Control transfer, the 'S' event carry
the setup header, and the 'C' ev
on 27/03/07 20:25 Pete Zaitcev wrote:
> [ISO packet descriptor]
> My current patch (see below) puts them
> into data
It's a quite big patch :-) It seams to be the merge of extended text api,
sysfs integration, bus 0 implementation and binary api extension, but I
think that at least the extended te
On Tue, 27 Mar 2007 08:54:32 +0200, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> I was wondering about making available the text extended information
> through the binary interface, without breaking current API. Some
> helper/dummy events could be generated for each isochronous transfer URB
> with num
hello,
I spend a few time in the last days using latest usbmon patch (with bus
0 interface). So far I did not notice any issue. My knowledge of the
module removal process is far from complete, so I can't perform any
formal correctness test for rmmod.
I used a linux-2.6.21-rc4 tree with the mon_e
On Wed, 2007-03-07 at 10:10 -0800, Pete Zaitcev wrote:
> Anyway, please look at the patch which I sent and see if you find any
> races, especially on rmmod and reader exits.
I'm sorry for the long delay in answering your mail. The last few days
where pretty busy and I've no better hope for next :-
On Wed, 07 Mar 2007 08:47:37 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> > #2 - The setting and testing of the monitoring flag was completely
> > ignored by the patch.
>
> Am I missing something or the 'monitored' flag is used to double check
> the usbmon structures consistence ?!? In an ide
On Mon, 2007-03-05 at 15:58 -0800, Pete Zaitcev wrote:
> I'm afraid that I have to take back some of the superlatives that
> I attached to this patch previously.
Yeep. I was wondering about submitting a CV to RH or something :-)
> #2 - The setting and testing of the monitoring flag was complete
On Wed, 28 Feb 2007 10:03:11 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> This patch create the bus0 to the usbmon interface. Bus0 provides events
> for all attached USB buses to any kind of reader (text, binary).
I'm afraid that I have to take back some of the superlatives that
I attached to
On Thu, 2007-03-01 at 19:48 -0800, Pete Zaitcev wrote:
> > @@ -441,7 +441,7 @@ static void mon_bin_event(struct mon_rea
> > /* We use the fact that usb_pipein() returns 0x80 */
> > ep->epnum = usb_pipeendpoint(urb->pipe) | usb_pipein(urb->pipe);
> > ep->devnum = usb_pipedevice(urb->pipe
On Wed, 28 Feb 2007 10:03:11 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> This patch create the bus0 to the usbmon interface. Bus0 provides events
> for all attached USB buses to any kind of reader (text, binary).
Looks very good indeed, although I disagree with your coding style
as usual :-)
On Wed, 28 Feb 2007 09:13:27 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> This patch adds a class which allows for an easier integration with
> udev.
You're really aggressive with wrapping, aren't you :)
> Signed-off-by: Paolo Abeni <[EMAIL PROTECTED]>
> Signed-off-by: Pete Zaitcev <[EMAIL PR
On 2/26/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 26 Feb 2007, Greg KH wrote:
>
> > On Mon, Feb 26, 2007 at 05:14:38PM -0500, Jon Smirl wrote:
> > > On 2/26/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> > > >> Another way to control this would be to put all of the USB Host IDs
> > > >> into
This patch create the bus0 to the usbmon interface. Bus0 provides events
for all attached USB buses to any kind of reader (text, binary).
Signed-off-by: Paolo Abeni <[EMAIL PROTECTED]>
---
This is test implementation to collect comments and suggestion on the
subject. The patch is against linux
This patch adds a class which allows for an easier integration with
udev.
Signed-off-by: Paolo Abeni <[EMAIL PROTECTED]>
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
---
The patch is against linux 2.6.21-rc1.
I just changed the struct device creation, using the ubus->controller as
the paren
On Tue, 2007-02-27 at 13:47 -0500, Jon Smirl wrote:
> I'm not too keen on using an ASCII 'S' in the setup field to tell
> whether setup[8] is in use or not. Am I correct in thinking that
> setup[8] is always active on an URB submission and never active on a
> completion or error?
Well, not exactl
On Tue, 27 Feb 2007 15:12:22 -0500, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
> I'm writing code to undo all of this in Wireshark and turn it back
> into a standard USB packet stream. [...]
Please keep in mind that USB is not Ethernet, so not everything encoded
in the transferred data. Those debuggi
On 2/27/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> On Tue, 27 Feb 2007 13:47:41 -0500, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
>
> > This is the structure being returned:
> >[...]
>
> You are confusing the usbmon's API with the "packet format" which
> Paolo manufactured for Wireshark's internal c
On Tue, 27 Feb 2007 13:47:41 -0500, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
> This is the structure being returned:
>[...]
You are confusing the usbmon's API with the "packet format" which
Paolo manufactured for Wireshark's internal consumption. In his case,
he has to present some kind of stream o
This is the structure being returned:
struct usbmon_packet {
u64 id; /* 0: URB ID - from submission to callback */
unsigned char type; /* 8: Same as text; extensible. */
unsigned char xfer_type; /*ISO (0), Intr, Control, Bulk (3) */
unsigne
On Tue, Feb 27, 2007 at 01:44:42PM +0100, Paolo Abeni wrote:
> This patch adds a class which allows for an easier integration with
> udev.
>
> Signed-off-by: Paolo Abeni <[EMAIL PROTECTED]>
> Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
>
> ---
>
> I just changed the struct device creation,
On Tue, 27 Feb 2007 13:44:42 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> This patch adds a class which allows for an easier integration with
> udev.
>
> Signed-off-by: Paolo Abeni <[EMAIL PROTECTED]>
> Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
No, please hold it. You have two patches s
On 2/26/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 26 Feb 2007, Jon Smirl wrote:
> > I'd vote for getting rid of the text mode interface to usbmon and
> > replace it with a tiny app which decodes the binary interface. You
> > could then give the app a device or class ID and it would filter
On 2/27/07, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-02-26 at 21:29 -0500, Jon Smirl wrote:
> > I'm looking at the request/response record of a get descriptor zero.
> >
> > [...]
> >
> > Response has eight bytes of leading zeros which correspond to the
> > eight bytes of the request.
>
This patch adds a class which allows for an easier integration with
udev.
Signed-off-by: Paolo Abeni <[EMAIL PROTECTED]>
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
---
I just changed the struct device creation, using the ubus->controller for
the parent device, as suggested by Greg. Otherwi
On Mon, 2007-02-26 at 21:29 -0500, Jon Smirl wrote:
> I'm looking at the request/response record of a get descriptor zero.
>
> [...]
>
> Response has eight bytes of leading zeros which correspond to the
> eight bytes of the request.
I'm sorry to see I wasn't able to explain the issue. The usb s
On Mon, 26 Feb 2007, Jon Smirl wrote:
> > Remember too that it's possible to hotplug USB buses. There are USB
> > controllers on PCcards.
>
> If CONFIG_HOTPLUG is on the new _init PCI ID table in USB core won't
> be discarded. Hotplug will work the same way it works currently. You
> don't need t
On Mon, 26 Feb 2007, Greg KH wrote:
> On Mon, Feb 26, 2007 at 05:14:38PM -0500, Jon Smirl wrote:
> > On 2/26/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> > >> Another way to control this would be to put all of the USB Host IDs
> > >> into a single module (usbcore), and then that module would load i
On Mon, 26 Feb 2007, Jon Smirl wrote:
> On 2/26/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > But why in the world would we care? These busses can come and go in any
> > number of varied and different ways. If you try to rely on a bus id
> > then you are going to be wrong eventually.
>
> The probl
I'm looking at the request/response record of a get descriptor zero.
This is the correct request
80 06 00 03 00 00 ff 00
Response
00 00 00 00 00 00 00 00 04 03 09 04
Response has eight bytes of leading zeros which correspond to the
eight bytes of the request.
I think response should either look
On 2/26/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> On Mon, 26 Feb 2007 18:32:06 -0500, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
> > On 2/26/07, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > > But why in the world would we care? These busses can come and go in any
> > > number of varied and different w
On Sat, Feb 24, 2007 at 07:06:43PM -0800, Pete Zaitcev wrote:
> This patch adds a class which allows for an easier integration with udev.
>
> Signed-off-by: Paolo Abeni <[EMAIL PROTECTED]>
> Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
>
> ---
>
> Paolo, I touched up two places:
> - class_cr
On Mon, 26 Feb 2007 18:32:06 -0500, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
> On 2/26/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > But why in the world would we care? These busses can come and go in any
> > number of varied and different ways. If you try to rely on a bus id
> > then you are going t
On 2/26/07, Greg KH <[EMAIL PROTECTED]> wrote:
> But why in the world would we care? These busses can come and go in any
> number of varied and different ways. If you try to rely on a bus id
> then you are going to be wrong eventually.
The problem is that usbmon is bus number oriented. When I bo
On Mon, Feb 26, 2007 at 05:14:38PM -0500, Jon Smirl wrote:
> On 2/26/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> >> Another way to control this would be to put all of the USB Host IDs
> >> into a single module (usbcore), and then that module would load in
> >> ehci, uhci, etc.
> >
> >That would wor
On 2/26/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> > Another way to control this would be to put all of the USB Host IDs
> > into a single module (usbcore), and then that module would load in
> > ehci, uhci, etc.
>
> That would work. But it would be a lot of effort for not much advantage.
It's n
On Mon, 26 Feb 2007, Jon Smirl wrote:
> > You could remove this indeterminism by explicitly loading ehci-hcd and
> > uhci-hcd (that is the preferred order) in a system start-up script before
> > udev. In FC6, for example, the modules are loaded from an initramfs
> > script.
>
> In think the usb
On 2/26/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 26 Feb 2007, Jon Smirl wrote:
>
> > My instability seems to come from a race between EHCI and UHCI. I have
> > one EHCI and four UHCI host controllers (ICH5).
> >
> > I usually get this at boot:
> > bus 1 UHCI-A
> > bus 2 UHCI-B
> > bus 3
On Mon, 26 Feb 2007, Jon Smirl wrote:
> My instability seems to come from a race between EHCI and UHCI. I have
> one EHCI and four UHCI host controllers (ICH5).
>
> I usually get this at boot:
> bus 1 UHCI-A
> bus 2 UHCI-B
> bus 3 UHCI-C
> bus 4 UHCI-D
> bus 5 EHCI
>
> But occasionally I get thi
On 2/25/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Sat, 24 Feb 2007, Jon Smirl wrote:
>
> > On 2/24/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> > > Also, Jon was hitting some problems with tcpdump and Paolo's libpcap,
> > > so let's keep one more revision stable to help them to figure this ou
On Sun, 25 Feb 2007, Jon Smirl wrote:
> I seem to be in an unstable race between the ehci and uhci buses for
> assigning bus #1.
That shouldn't happen unless you have enabled the config option for
for parallel PCI probing. If you have, you might as well turn it off --
it has caused a number of
On 2/25/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Sat, 24 Feb 2007, Jon Smirl wrote:
>
> > On 2/24/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> > > Also, Jon was hitting some problems with tcpdump and Paolo's libpcap,
> > > so let's keep one more revision stable to help them to figure this ou
On 2/25/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> On Sat, 24 Feb 2007 22:55:28 -0500, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
>
> > For example, as far as I can tell there is no info in the capture
> > packet stream describing the attached devices unless I so something
> > like "lsusb -v" while
On Sat, 24 Feb 2007 22:55:28 -0500, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
> For example, as far as I can tell there is no info in the capture
> packet stream describing the attached devices unless I so something
> like "lsusb -v" while data is being captured. [...]
True, the intent was that the
On Sat, 24 Feb 2007, Jon Smirl wrote:
> On 2/24/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> > Also, Jon was hitting some problems with tcpdump and Paolo's libpcap,
> > so let's keep one more revision stable to help them to figure this out
> > and bring libpcap into shape. They may yet find a ker
On 2/24/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> Also, Jon was hitting some problems with tcpdump and Paolo's libpcap,
> so let's keep one more revision stable to help them to figure this out
> and bring libpcap into shape. They may yet find a kernel bug too.
I wish the bus numbers were stabl
This patch adds a new text API, codenamed '1u', which captures more URB
fields than old '1t' interface did. Also the '1u' text API is compatible
with the future "bus zero" extension.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
Acked-by: Alan Stern <[EMAIL PROTECTED]>
---
Alan "acked this", I
This patch adds a class which allows for an easier integration with udev.
Signed-off-by: Paolo Abeni <[EMAIL PROTECTED]>
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
---
Paolo, I touched up two places:
- class_create returns ERR_PTR on error, not NULL
- I prefer a LIFO order of construction
On Thu, 8 Feb 2007, Pete Zaitcev wrote:
> On Thu, 08 Feb 2007 17:11:04 +0100, "Clemens Ladisch" <[EMAIL PROTECTED]>
> wrote:
>
> > The driver uses 8 packets per URB by default. It is possible to select
> > a higher value with a module option; the maximum value is 20 (but this
> > is just a #def
On Thu, 08 Feb 2007 17:11:04 +0100, "Clemens Ladisch" <[EMAIL PROTECTED]> wrote:
> The driver uses 8 packets per URB by default. It is possible to select
> a higher value with a module option; the maximum value is 20 (but this
> is just a #define).
>
> In high speed mode, everything is multiplie
On Thu, 8 Feb 2007 09:55:31 -0500 (EST), "Alan Stern"
<[EMAIL PROTECTED]> said:
> On Wed, 7 Feb 2007, Pete Zaitcev wrote:
>
> > Alan, do you happen to know how much usb_iso_packet_descriptor thingies
> > we allocate typically? One? Three? Tens? A hundred? In usbfs we allow 128.
> > If we routinely
Alan Stern wrote:
> On Wed, 7 Feb 2007, Pete Zaitcev wrote:
> > Alan, do you happen to know how much usb_iso_packet_descriptor thingies
> > we allocate typically? One? Three? Tens? A hundred? In usbfs we allow 128.
> > If we routinely get lots of them per URB then I need to rethink the line
> > for
On Wed, 7 Feb 2007, Pete Zaitcev wrote:
> Alan, do you happen to know how much usb_iso_packet_descriptor thingies
> we allocate typically? One? Three? Tens? A hundred? In usbfs we allow 128.
> If we routinely get lots of them per URB then I need to rethink the line
> format and all other things. I
Alan, do you happen to know how much usb_iso_packet_descriptor thingies
we allocate typically? One? Three? Tens? A hundred? In usbfs we allow 128.
If we routinely get lots of them per URB then I need to rethink the line
format and all other things. It's a big can of worms.
Yours,
-- Pete
On Thu, 11 Jan 2007 10:04:26 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> The issue rises because in the pcap code I don't modify the event header
> (and I can't, at least when I use memory mapped access to usbmon). So
> the event header is written in pcap files in host byte order.
But in suc
On Wed, 2007-01-10 at 10:56 -0800, Pete Zaitcev wrote:
> > I'm sorry to have came to this a little too late...
>
> Yeah, that's the main issue. We could have defined the status
> to be structured and have a guaranteed alignment earlier, if anyone
> cared back then.
>
> How much of a problem is it
On Wed, 10 Jan 2007 10:25:54 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> I have an issue related to the new usbmon binary API.
> AFAIK the header added from the kernel to each event is in host byte
> order, except for the setup header part, which is in little endian byte
> order. All the rema
hello,
I have an issue related to the new usbmon binary API.
AFAIK the header added from the kernel to each event is in host byte
order, except for the setup header part, which is in little endian byte
order. All the remaining data is little endian, too.
Shouldn't be reasonable to update the cod
On Wed, 2006-12-20 at 13:40 -0800, Pete Zaitcev wrote:
> But what is usbmon0 for? We do not have it implemented yet, so there's
> no reason to advertise it in the class. Or is there?
Actually no. I think/hope that usbmon0 will be the device for sniffing
from all USB buses. I added the class_device
On Wed, 20 Dec 2006, Pete Zaitcev wrote:
> On Wed, 20 Dec 2006 10:04:01 -0500 (EST), Alan Stern <[EMAIL PROTECTED]>
> wrote:
>
> > > Assuming x86 32, -115 = -EINPROGRESS, that means URB still pending, no
> > > results yet
> >
> > All successful Submission ('S') lines will contain this code.
>
On Mon, 18 Dec 2006 22:42:25 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> I have modified the usbmon patch as described in my previous mail. Now a
> new device class is created: "usbmon". This class hold the sysfs entry
> for usbmon devices. This entries are created dynamically when the usb
> b
On Wed, 20 Dec 2006 10:04:01 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> > Assuming x86 32, -115 = -EINPROGRESS, that means URB still pending, no
> > results yet
>
> All successful Submission ('S') lines will contain this code.
>
> > > e.g. status code "-2"
> >
> > -2 = -ENOENT, speci
On Wed, 20 Dec 2006, Thomas Sailer wrote:
> On Wed, 2006-12-20 at 10:55 +1100, Aras Vaichas wrote:
>
> > I'm at a loss to understand the status code. Can someone point me to where I
> > can decode this?
>
> With the help of /usr/include/asm/errno.h, you can translate the error
> numbers to error
On Wed, 20 Dec 2006 10:55:24 +1100, Aras Vaichas <[EMAIL PROTECTED]> wrote:
> Also, does usbmon show absolutely *everything* that goes in/out of the USB
> port? My software is duplicating *exactly* what I'm seeing on usbmon when I
> run
> the third party software, yet my software doesn't work the
On Wed, 2006-12-20 at 10:55 +1100, Aras Vaichas wrote:
> I'm at a loss to understand the status code. Can someone point me to where I
> can decode this?
With the help of /usr/include/asm/errno.h, you can translate the error
numbers to error names.
Documentation/usb/error-codes.txt then documents
Hi, I'm currently using usbmon to try and control a USBTMC (supposedly)
compliant oscilloscope.
I'm at a loss to understand the status code. Can someone point me to where I
can decode this?
Output from:
# cat /sys/kernel/debug/usbmon/1t
e.g. status code "-115"
c2cd3bc0 534825333 S Bo:084:06 -115
On Mon, 18 Dec 2006 22:31:27 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> The general trend in USB is to treat the direction as part of the
> endpoint's identification. For instance, we say that a device can have up
> to 32 endpoints (16 IN and 16 OUT). And ep1-out (0x01) is definitely
>
On Mon, 18 Dec 2006, Pete Zaitcev wrote:
> On Mon, 18 Dec 2006 23:02:36 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
>
> > The code for interfacing with the new binary API has not been merged yet
> > into libpcap. If this really matters, I suppose it can be changed...
>
> Thanks. I wrote everyt
On Mon, 18 Dec 2006 23:02:36 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> The code for interfacing with the new binary API has not been merged yet
> into libpcap. If this really matters, I suppose it can be changed...
Thanks. I wrote everything (ok, just 3 lines of patch twice, plus docs),
but
On Sun, 2006-12-17 at 12:47 -0800, Pete Zaitcev wrote:
> On Sat, 16 Dec 2006 12:07:16 -0500 (EST), Alan Stern <[EMAIL PROTECTED]>
> wrote:
> > The 0x80-for-IN usually goes with the endpoint number; why have you moved
> > it into the endpoint type byte?
>
[...]
>
> Changing it now will affect Pa
hello,
I have modified the usbmon patch as described in my previous mail. Now a
new device class is created: "usbmon". This class hold the sysfs entry
for usbmon devices. This entries are created dynamically when the usb
buses are registered, and destroyed accordingly. The whole thing
integrate ni
Hello,
On Wed, 2006-12-13 at 11:13 +0100, Marcel Holtmann wrote:
> the usbmon devices need a subsystem entry. The best way to me seems to
> attach them to the USB bus where all host controllers are already
> listed.
Here I'm walking on thin ice, because the sysfs thing looks a bit
obscure to me.
On Sat, 16 Dec 2006 12:07:16 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> > +struct usbmon_packet {
> > + u64 id; /* 0: URB ID - from submission to callback */
> > + unsigned char type; /* 8: Same as text; extensible. */
> > + unsigned char xfer_type; /*ISO,
On Fri, 15 Dec 2006, Pete Zaitcev wrote:
> It turned out easier than I expected. All that was necessary was to
> add #include . Does this work for everyone? If yes, I'm
> sending it to Greg.
Two very minor comments...
> +struct usbmon_packet {
> + u64 id; /* 0: URB ID - from
On Tue, 12 Dec 2006 21:25:18 +0100, Marcel Holtmann <[EMAIL PROTECTED]> wrote:
> do you have an updated patch that applies cleanly against the latest
> tree from Linus?
It turned out easier than I expected. All that was necessary was to
add #include . Does this work for everyone? If yes, I'm
send
On Tue, 12 Dec 2006 09:35:59 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> The pcap patch to use the new API has been reworked and now it works
> also with the mmap access. (it forward the kernel header to the
> application). The pcap patch can be found here:
>
> http://thread.gmane.org/gmane.n
Hi Paolo,
> > Can you send me your udev rule or a note however
> > you create the /dev/usbmonN?
>
> I create the device file with this script:
>
> #!/bin/sh
> mkdir /dev/usbmon
> mknod /dev/usbmon/1 c 253 1
> mknod /dev/usbmon/2 c 253 2
> mknod /dev/usbmon/3 c 253 3
> mknod /dev/usbmon/4 c 253 4
On Tue, 2006-12-12 at 11:47 -0800, Pete Zaitcev wrote:
> Can you send me your udev rule or a note however
> you create the /dev/usbmonN?
I create the device file with this script:
#!/bin/sh
mkdir /dev/usbmon
mknod /dev/usbmon/1 c 253 1
mknod /dev/usbmon/2 c 253 2
mknod /dev/usbmon/3 c 253 3
mknod
On Tue, 12 Dec 2006 21:25:18 +0100, Marcel Holtmann <[EMAIL PROTECTED]> wrote:
> > Yes, there is. I was distracted by something shiny and also I've
> > got a final on Friday... I wanted to clean the thing a little too,
> > and write a passable doc.
>
> do you have an updated patch that applies cl
Hi Pete,
> > I would like to know the current usbmon status. Is there any chance to
> > get the patch into a future kernel release ?!?
>
> Yes, there is. I was distracted by something shiny and also I've
> got a final on Friday... I wanted to clean the thing a little too,
> and write a passable d
On Tue, 12 Dec 2006 09:35:59 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> I would like to know the current usbmon status. Is there any chance to
> get the patch into a future kernel release ?!?
Yes, there is. I was distracted by something shiny and also I've
got a final on Friday... I wanted t
Hello,
I would like to know the current usbmon status. Is there any chance to
get the patch into a future kernel release ?!?
The pcap patch to use the new API has been reworked and now it works
also with the mmap access. (it forward the kernel header to the
application). The pcap patch can be fou
On Mon, 2006-12-04 at 10:05 -0800, Pete Zaitcev wrote:
> What is libpcap going
> to do in case of other protocols exposing packets with mmap, like
> Infiniband?
AFAIK there is no usage of memory mapped access into current libpcap
tree. A kind of fork of libpcap, which use the mmap interface for pa
On Mon, 04 Dec 2006 18:12:48 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> The issue rises because libpcap substitutes the usbmon event header
> provided by the kernel with a different header that is more "kernel
> agnostic". This substitution is not a strict libpcap requirement, but
> given the
Dear Paolo:
Just to make sure we're on the same page, I'm waiting for your approval
before sending this to Greg. My own tests seem to work more or less,
although I do not use mmap yet: that part is simply your code, only
with the change for offset>=limit over offset>limit.
Yours,
-- Pete
P.S. Do
On Fri, 24 Nov 2006 09:52:46 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> Before returning the mutex 'fetch_lock' is hold, shouldn't it be
> released ?!?
Thanks, I fixed this by factoring the waiting. I am getting sloppy
with the haste, sorry.
-- Pete
---
Hello,
I think there is a possible issue in the mon_get_event and mon_read
functions:
On Tue, 2006-11-21 at 22:56 -0800, Pete Zaitcev wrote:
[...]
> + mutex_lock(&rp->fetch_lock);
> +
> + add_wait_queue(&rp->b_wait, &waita);
> + set_current_state(TASK_INTERRUPTIBLE);
> +
> + spin_
On Thu, 23 Nov 2006 04:37:59 -0500, Ben Gamari <[EMAIL PROTECTED]> wrote:
> Isn't copy_from_buf supposed to return "an error code, not an offset"?
> Look at line 232 (return off;). I think it should probably return
> 0. Addiionally, I don't think that the while loop in mon_bin_read
> (line 636)
Isn't copy_from_buf supposed to return "an error code, not an offset"?
Look at line 232 (return off;). I think it should probably return
0. Addiionally, I don't think that the while loop in mon_bin_read
(line 636) is supposed to be negated. I have also merged the patch
with 2.6.19-rc6. Most of t
On Thu, 23 Nov 2006 09:06:41 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-11-22 at 16:46 -0800, Pete Zaitcev wrote:
> > I'm thinking if I should add a "force O_NONBLOCK" flag somehow,
> > in case someone wants to flush all events. If you find an application
> > which can make an in
On Thu, 23 Nov 2006 11:32:26 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> Is there any thought toward implementing some sort of packet-filtering
> capability?
I think it wouldn't be a bad idea, especially since we (I and Paolo) were
unable to create a zero-copy path. But I just don't hav
1 - 100 of 151 matches
Mail list logo
