public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Dalecki <dalecki@evision-ventures.com>
To: Patrick Mochel <mochel@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: device model documentation 1/3
Date: Wed, 05 Jun 2002 11:08:35 +0200	[thread overview]
Message-ID: <3CFDD513.4030109@evision-ventures.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0206041115540.654-100000@geena.pdx.osdl.net>

Patrick Mochel wrote:
> On Tue, 4 Jun 2002, Patrick Mochel wrote:
> 
> 
>>>>	int	(*bind)		(struct device * dev, struct device_driver * drv);
>>>>};
>>>>
>>>
>>>Please - Why do you call it bind? Does it have something with
>>>netowrking to do? Please just name it attach. This way the old UNIX
>>>guys among us won't have to drag a too big
>>>"UNIX to Linux translation dictionary" around with them.
>>>As an "added bonus" you will stay consistent with -
>>>
>>>PCMCIA code base in kernel
>>>USB code base in kernel
>>>IDE code base (well recently)
>>
>>Ok, I can live with that.
> 
> 
> Actually, I take that back. attach is the wrong nomenclature as well for 
> the action. 'match' would be more correct.

That would be fine with me. At least this would not confuse at least me
about what's up with it. matchid would be even more obvious.
Perhaps "validate" could be used too, becouse the method is
not acting on equivalent objects.

> The entry point is the opportunity for the bus to compare a device ID with
> a list of IDs that a particular driver supports. It's a 'compare' or
> 'match' operation. At this point, the driver is not attaching to the
> device; it's only checking that's its ok to attach.
> 
> So, how about naming it 'match', and changing the 
> {driver,device}_{,un}bind() in drivers/base/core.c to 
> {driver,device}_{,un}attach() (since those are what is doing the 
> attachment)?

Fine with me. This would be not confusing.

> The entire process, though, I think is still best described as "Driver 
> Binding", as it is a common, modern term for what's happening.

Common or not on unix driver binding has already a meaning and
the term confused at least one person (me).

Also please think about the following: terms should always
be related to the object they act *on* and not the object they
are the *method of* - becouse this is already known by the
"method from" relation. Therefore validate or match is more
"obvious" then bind at the respecitve places. IMHO.


  parent reply	other threads:[~2002-06-05 10:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-04 16:25 device model documentation 1/3 Patrick Mochel
2002-06-04 15:45 ` Martin Dalecki
2002-06-04 16:53   ` Greg KH
2002-06-04 16:00     ` Martin Dalecki
2002-06-04 17:40   ` Patrick Mochel
2002-06-04 18:26     ` Patrick Mochel
2002-06-04 19:06       ` Adam Kropelin
2002-06-05  9:08       ` Martin Dalecki [this message]
2002-06-05  8:36     ` Martin Dalecki

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=3CFDD513.4030109@evision-ventures.com \
    --to=dalecki@evision-ventures.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@osdl.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