From: Pete Zaitcev <zaitcev@redhat.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Greg KH <greg@kroah.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
zaitcev@redhat.com
Subject: Re: Patch to add usbmon
Date: Tue, 1 Feb 2005 09:55:26 -0800 [thread overview]
Message-ID: <20050201095526.0ee2e0f4@localhost.localdomain> (raw)
In-Reply-To: <1107256383.9652.26.camel@pegasus>
On Tue, 01 Feb 2005 12:13:03 +0100, Marcel Holtmann <marcel@holtmann.org> wrote:
> By accident I removed the debugfs option from my kernel config and this
> makes usbmon totally useless. So I think the module approach is wrong
> from my point of view. Why not compile it always and if debugfs is
> available, then enable it when the usbcore gets loaded?
This may be a good idea, but I'm too lazy to think in trinary. Care to
send a patch?
> And btw don't you think that you split your code into too much separate
> files? I count less than 900 lines of code.
What does it hurt? I think the split was rather clean, along well defined
functional lines, with minimum dependencies. They may even be separate
modules later.
> However it works fine for me, but I can't find a document that describes
> the information (without looking at the code) you get, when running cat
> on a specific bus.
I'm sorry about that. I will add a file in Documentation/ .
> control urb endpoint 0x00 flags 0x00 buflen 3 actlen 0
> bRequestType 0x20 bRequest 0x00 wValue 0 wIndex 0 wLength 3
> pipe 0x80003900 flags 0x00 buffer f7f2e4e0 length 3 setup f64895a0 start 0 packets 0 interval 0
> data 36 fc 00
You are right, the current text format (0t) is not easily readable.
My plan calls for the parsing of control messages and things like SCSI
commands to be placed in user mode applications, like USBMon. This is how
tcpdump and Ethereal operate. I don't like to keep too much of this in
kernel. Do you think it's a wrong approach?
> [...] I think it makes sense to present the device number of that device.
When I read dumps, I mentally fetch the device number from the pipe.
Just use that for now, please.
But if you or someone else were to hack on something like usbdump(1),
it would be peachy, I think.
-- Pete
next prev parent reply other threads:[~2005-02-01 17:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-01 5:29 Patch to add usbmon Pete Zaitcev
2005-02-01 7:10 ` Greg KH
2005-02-01 8:32 ` Pete Zaitcev
2005-02-01 11:13 ` Marcel Holtmann
2005-02-01 17:55 ` Pete Zaitcev [this message]
2005-02-01 21:37 ` Marcel Holtmann
2005-02-02 5:59 ` Pete Zaitcev
2005-02-02 16:40 ` Marcel Holtmann
2005-02-02 18:54 ` Pete Zaitcev
2005-02-05 0:19 ` Marcel Holtmann
2005-02-02 6:25 ` Pete Zaitcev
2005-02-04 23:47 ` Greg KH
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=20050201095526.0ee2e0f4@localhost.localdomain \
--to=zaitcev@redhat.com \
--cc=greg@kroah.com \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox