public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Sarah Sharp <sarah.a.sharp@intel.com>
Cc: Julia Lawall <julia@diku.dk>,
	gregkh@suse.de, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] include/linux: Move definitions from usb.h to usb/ch9.h
Date: Tue, 30 Dec 2008 17:40:26 -0800	[thread overview]
Message-ID: <200812301740.26432.david-b@pacbell.net> (raw)
In-Reply-To: <20081230233727.GA12819@gamba.jf.intel.com>

On Tuesday 30 December 2008, Sarah Sharp wrote:
> I thought the include/linux/usb/ch9.h was supposed to include values that are
> defined in various USB specifications (starting with the protocol "chapter 9"
> from the USB 1.1 bus specification).

And not getting too far from "chapter 9" ... there are
a few things from the "common class spec", and constants
defining classes, but they're needed to interpret a lot
of descriptors.


> The constants (masks) used by these 
> functions aren't part of the standards,

They are too!  Bitfields and the values in those bitfields
are part of the endpoint descriptor definitions.

In protocol specs, data format definitions don't usually
define symbolic accessors for fields, or for individual
message structures.  Those are part of a programming
language/environment binding.

This distinction is a Good Thing ... names used in assembly
might use Hungarian Notation to make up for the complete
lack of type checking; names in C would normally leave
type checking to the compiler; names in LISP would use
embedded "-" instead of embedded "_" or embedded "$" for
separators; and so on.  No single set of names can work
everywhere; and even if it could, it would fight against
coding conventions in many organizations.


> so why move these functions to 
> include/linux/usb/ch9.h?  Was it confusing to find these functions, or do you
> have an overall plan for these changes?

You missed earlier mail on the topic.  The basic issue is
that those symbols can (and should!) be used for peripheral
side support as well as host side support ... which means
they should never have been put into a host-only header.

- Dave


  reply	other threads:[~2008-12-31  1:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-29 21:48 [PATCH] include/linux: Move definitions from usb.h to usb/ch9.h Julia Lawall
2008-12-30  0:25 ` David Brownell
2008-12-30 23:39 ` Sarah Sharp
2008-12-31  1:40   ` David Brownell [this message]
2009-01-02  2:01     ` Sarah Sharp

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=200812301740.26432.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=gregkh@suse.de \
    --cc=julia@diku.dk \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=sarah.a.sharp@intel.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