linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Diego Elio Pettenò" <flameeyes@flameeyes.com>
To: "Greg KH" <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, "Pete Zaitcev" <zaitcev@redhat.com>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Kris Katterjohn" <katterjohn@gmail.com>
Subject: Re: [PATCH v2] usbmon: expose the usbmon structures and constants as an UAPI header.
Date: Mon, 06 Jul 2020 14:10:14 +0100	[thread overview]
Message-ID: <4b2de0b6-5410-4e64-b432-23458e09a97e@www.fastmail.com> (raw)
In-Reply-To: <20200706124943.GA2270456@kroah.com>

On Mon, Jul 6, 2020, at 13:49, Greg KH wrote:
> > -The overall architecture of the API is about the same as the one above,
> > -only the events are delivered in binary format. Each event is sent in
> > -the following structure (its name is made up, so that we can refer to it)::
[snip]
> > +The overall architecture of the API is about the same as the one above, only the
> 
> Why change that line?

The original text says that the structure had a made up name — since there was no exposed structures to match. Now there is, it's no longer made up.

> 
> > +events are delivered in binary format. The structures and constants are defined
> > +in linux/usb/mon.h.
> 
> Not your new uapi file location?

That is the new uapi header — that'd be the location on the installed system, updated with the location within the repository instead.

> __u64, right?  Same for the rest of this file...

Ack.

> Why drop this?  If you want to clean up the documentation, wonderful,
> but again, don't do that in the same patch.

Okay split that one line change to a separate change. I really should try to sit down and improve the docs overall, but that's a much bigger undertaking.

> is size_t a value we can pass across user/kernel boundry?  Are you sure
> this isn't __kernel_size_t?

No I'm not sure and I was pondering myself. I'll trust your instinct because you know this much better than me.

But… I'm not sure how to use that from an uapi header? The __kernel_size_t does not appear to be defined by including linux/types.h. There's only three users of it in include/uapi/ and the only one that does not appear to re-define it as a typedef is include/uapi/linux/uio.h, but using the same include doesn't seem to work for me.

So I expect I'll need a v3 for this one ;)

  reply	other threads:[~2020-07-06 13:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-05 15:02 [PATCH] usbmon: expose the usbmon structures and constants as an UAPI header Diego Elio Pettenò
2020-07-06  3:51 ` Pete Zaitcev
2020-07-06  8:32   ` Diego Elio Pettenò
2020-07-06 15:01     ` Pete Zaitcev
2020-07-06  5:46 ` kernel test robot
2020-07-06 10:30 ` Greg KH
2020-07-06 12:21   ` Diego Elio Pettenò
2020-07-06 12:15 ` [PATCH v2] " Diego Elio Pettenò
2020-07-06 12:49   ` Greg KH
2020-07-06 13:10     ` Diego Elio Pettenò [this message]
2020-07-06 16:15     ` Pete Zaitcev
2020-07-06 13:10 ` [PATCH v3 1/2] Remove documentation line that adds nothing and sounds condescending Diego Elio Pettenò
2020-07-06 13:10   ` [PATCH v3 2/2] usbmon: expose the usbmon structures and constants as an UAPI header Diego Elio Pettenò
2020-07-06 16:35     ` Greg KH
2020-07-06 16:34   ` [PATCH v3 1/2] Remove documentation line that adds nothing and sounds condescending Greg KH
2020-07-06 22:44 ` [PATCH v4 " Diego Elio Pettenò
2020-07-06 22:44   ` [PATCH v4 2/2] usbmon: expose the usbmon structures and constants as an UAPI header Diego Elio Pettenò
2020-07-09 16:04     ` Greg KH
2020-07-11 13:14     ` kernel test robot
2020-07-09 16:03   ` [PATCH v4 1/2] Remove documentation line that adds nothing and sounds condescending 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=4b2de0b6-5410-4e64-b432-23458e09a97e@www.fastmail.com \
    --to=flameeyes@flameeyes.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=katterjohn@gmail.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=zaitcev@redhat.com \
    /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;
as well as URLs for NNTP newsgroup(s).