lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 30 Dec 2008 17:40:26 -0800
From:	David Brownell <david-b@...bell.net>
To:	Sarah Sharp <sarah.a.sharp@...el.com>
Cc:	Julia Lawall <julia@...u.dk>, gregkh@...e.de,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] include/linux: Move definitions from usb.h to usb/ch9.h

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists