From: Johannes Erdfelt <johannes@erdfelt.com>
To: David Brownell <david-b@pacbell.net>
Cc: Linus Torvalds <torvalds@transmeta.com>,
linux-usb-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] Re: [BK PATCH] USB device support for 2.5.8 (take 2)
Date: Wed, 17 Apr 2002 16:07:59 -0400 [thread overview]
Message-ID: <20020417160759.G17779@sventech.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0204171043260.17271-100000@home.transmeta.com> <07d501c1e644$ee62c6e0$6800000a@brownell.org>
On Wed, Apr 17, 2002, David Brownell <david-b@pacbell.net> wrote:
> > Note that the relevance of the USB spec to most people is exactly 0%.
>
> But to USB developers, if it's not 100% they're in major trouble!
> They're the folk who will be using this terminology/API the most.
>
> The challenge here is to come up with something that doesn't
> needlessly confuse the major communities of interest ... such
> as by redefining terms that are already in use.
I agree. While the relevance of the USB spec to most people is exactly
0%, the relevance to the USB portion of the kernel is almost exactly 0%
as well. I'd much rather cater to the USB developers since they're the
people who will be looking at those names, not anyone else.
Nonetheless, the current naming is a bit confusing.
> > Since we're talking about the other end of a "host" driver, "client" makes
> > sense - in computers, I've always seen "client" as the reverse of the
> > "host", but maybe that's just me.
>
> Another overloaded word. I've always seen it as the requestor,
> in all contexts (restaurants, stores, networking ... :) and in USB
> it's the "host" that requests.
Hmm, good point.
> > What were the other suggestions?
>
> Of the two I saw coming by this morning ("target" from Larry,
> and "gadget" from Stephen) I confess I liked "target" best.
> It captures the initating/responding roles quite well.
I agree too.
> I don't recall many other suggestions that were forthcoming.
>
> But I'll also toss out "firmware", which is often used in such
> contexts: firmware revision for a network adapter, and so on.
> "USB firmware" is not likely to be expected on the host side.
> "USB target firmware", and so on.
This can also be used too, although I typically picture smaller
controllers when it comes to firmware, whereas software runs on more
general purpose controllers, like the ones people would find running
embedded devices and thusly this software.
Anyway, my opinion is that "target" is the best term to use.
JE
next prev parent reply other threads:[~2002-04-17 20:08 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-16 22:54 [BK PATCH] USB device support for 2.5.8 Greg KH
2002-04-16 22:58 ` Greg KH
2002-04-17 2:51 ` [BK PATCH] USB device support for 2.5.8 (take 2) Greg KH
2002-04-17 2:53 ` Greg KH
2002-04-17 4:35 ` Linus Torvalds
2002-04-17 3:52 ` Greg KH
2002-04-17 5:08 ` Linus Torvalds
2002-04-17 13:44 ` Greg KH
2002-04-17 16:00 ` [linux-usb-devel] " David Brownell
2002-04-17 17:57 ` Linus Torvalds
2002-04-17 18:08 ` Larry McVoy
2002-04-17 18:59 ` Linus Torvalds
2002-04-17 18:14 ` Greg KH
2002-04-17 18:17 ` Greg KH
2002-04-19 5:37 ` George J Karabin
2002-04-19 5:46 ` [linux-usb-devel] Re: [BK PATCH] USB device support for 2.5.8(take 2) Oliver Neukum
2002-04-19 6:11 ` George J Karabin
2002-04-19 11:06 ` [linux-usb-devel] Re: [BK PATCH] USB device support for2.5.8(take2) Oliver.Neukum
2002-04-19 16:22 ` George J Karabin
2002-04-17 18:41 ` [linux-usb-devel] Re: [BK PATCH] USB device support for 2.5.8 (take 2) Stephen J. Gowdy
2002-04-17 18:31 ` Greg KH
2002-04-17 18:44 ` [linux-usb-devel] Re: [BK PATCH] USB device support for 2.5.8 arjan
2002-04-17 19:02 ` [linux-usb-devel] Re: [BK PATCH] USB device support for 2.5.8 (take 2) Oliver Xymoron
2002-04-17 19:20 ` David Brownell
2002-04-17 20:07 ` Johannes Erdfelt [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-04-17 19:58 Adam_Kessler
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=20020417160759.G17779@sventech.com \
--to=johannes@erdfelt.com \
--cc=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=torvalds@transmeta.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