From: Dmitry Torokhov <dtor_core@ameritech.net>
To: Greg KH <greg@kroah.com>
Cc: ambx1@neo.rr.com, linux-kernel@vger.kernel.org,
Tejun Heo <tj@home-tj.org>,
Patrick Mochel <mochel@digitalimplant.org>
Subject: Re: [RFC] [PATCH] driver core: allow userspace to unbind drivers from devices.
Date: Wed, 17 Nov 2004 02:07:14 -0500 [thread overview]
Message-ID: <200411170207.14745.dtor_core@ameritech.net> (raw)
In-Reply-To: <20041116201726.GA11069@kroah.com>
On Tuesday 16 November 2004 03:17 pm, Greg KH wrote:
> > 2.) I don't like having an "unbind" file.
>
> Why?
I do not like interfaces accepting and encouraging writing garbage data. What
value sould be written into "unbind"? Yes, any junk.
>
> > This implies that we will have at least three seperate files controlling
> > driver binding when we really need only one or two at the most. Consider
> > "bind", "unbind", and the link to the driver that is bound.
>
> No. Consider the fact that the "unbind" file will not be present if the
> device is not bound to anything. Once it is bound, the unbind file will
> be created, and the symlink will be created. The symlink matches other
> parts of sysfs. By trying to put the name of the driver in a file, that
> makes userspace work a lot harder to try to figure out exactly what
> driver is bound (consider the fact that I can have both a pci and a usb
> driver with the same name in sysfs, and that's legal.)
But not 2 drivers with the same name on the same bus so I don't think this
is a valid argument. Anyway, we already have this symlink.
>
> So, when a device is not bound to a driver, there will be no symlink, or
> a "unbind" file, only a "bind" file. Really there is only 1 "control"
> type file present at any single point in time.
Does that imply that I can not rebind device while it is bound to a driver?
("bind" would be missing it seems). And what about all other flavors of that
operation - rescan, reconnect? Do we want to have separate attributes for
them as well?
--
Dmitry
next prev parent reply other threads:[~2004-11-17 7:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-09 22:37 [RFC] [PATCH] driver core: allow userspace to unbind drivers from devices Greg KH
2004-11-09 23:36 ` Dmitry Torokhov
2004-11-10 0:33 ` Greg KH
2004-11-10 3:49 ` Dmitry Torokhov
2004-11-16 5:54 ` Greg KH
2004-11-16 20:43 ` Dmitry Torokhov
2004-11-16 23:08 ` Greg KH
2004-11-17 7:00 ` Dmitry Torokhov
2004-11-17 17:55 ` Greg KH
2004-11-16 6:13 ` Adam Belay
2004-11-16 6:37 ` Dmitry Torokhov
2004-11-16 7:04 ` Adam Belay
2004-11-16 20:22 ` Greg KH
2004-11-16 21:09 ` Dmitry Torokhov
2004-11-16 20:17 ` Greg KH
2004-11-17 7:07 ` Dmitry Torokhov [this message]
2004-11-17 17:53 ` Greg KH
2004-11-17 19:01 ` Dmitry Torokhov
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=200411170207.14745.dtor_core@ameritech.net \
--to=dtor_core@ameritech.net \
--cc=ambx1@neo.rr.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
--cc=tj@home-tj.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.