public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Dmitry Torokhov <dtor_core@ameritech.net>
Cc: linux-kernel@vger.kernel.org, Patrick Mochel <mochel@digitalimplant.org>
Subject: Re: [RFC] bind and unbind drivers from userspace through sysfs
Date: Wed, 29 Jun 2005 16:47:55 -0700	[thread overview]
Message-ID: <20050629234755.GA19599@kroah.com> (raw)
In-Reply-To: <200506242322.57535.dtor_core@ameritech.net>

On Fri, Jun 24, 2005 at 11:22:57PM -0500, Dmitry Torokhov wrote:
> On Friday 24 June 2005 00:12, Greg KH wrote:
> > Now that we have the internal infrastructure of the driver model
> > reworked so the locks aren't so global and imposing, it's possible to
> > bind and unbind drivers from devices from userspace with only a very
> > tiny ammount of code.
> > 
> > In reply to this email, are two patches, one that adds bind and one that
> > adds unbind functionality.  I've added these to my trees and should show
> > up in the next -mm releases.  Comments appreciated.
> > 
> > Oh, and yes, we still need a way to add new device ids to drivers from
> > sysfs, like PCI currently has.  I'll be working on that next.
> >
> 
> I think this is an overkill if you can do manual bind/unbind.

No, this is needed.  You can only bind a device to a driver that will
accept it.  As we can not add new device ids to all drivers yet (only
PCI supports that), this isn't as useful as it could be.  I'll be moving
that PCI code into the driver core, so that all busses that want to
support this (adding new device ids on the fly), can.

> > Even so, with these two patches, people should be able to do things that
> > they have been wanting to do for a while (like take over the what driver
> > to what device logic in userspace, as I know some distro installers
> > really want to do.)
> > 
> 
> I think bind/unbind should be bus's methods and attributes should be
> created only if bus supports such operations. Some buses either have
> or may need additional locking considerations and will not particularly
> like driver core getting in the middle of things.

Examples of such?  Yes, a bus that isn't really expecting this to
happen, as it has some odd locking logic in the
registering/unregistering of a new driver for it, might have issues.
But I'd say that this is the bus's fault, not the driver core's fault.

Becides, you can just have the bus fail such a bind/unbind attempt, if
you really want to do that.

Anyway, I've tested this with PCI and USB devices, and they both work
just fine, and those are the busses that the majority of people want
this functionality for.

> Btw, do we really need separate attributes for bind/unbind?

Overloading a single file would be messier.  The overhead for an
additional attribute per driver is quite small (I move the unbind
attribute to the driver, as it makes more sense there as Pat mentioned.)

thanks,

greg k-h

  reply	other threads:[~2005-06-29 23:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-24  5:12 [RFC] bind and unbind drivers from userspace through sysfs Greg KH
2005-06-24  5:14 ` [PATCH] driver core: Add the ability to unbind drivers to devices from userspace Greg KH
2005-06-24  5:15   ` [PATCH] driver core: Add the ability to bind " Greg KH
2005-06-24 15:57   ` [PATCH] driver core: Add the ability to unbind " Patrick Mochel
2005-06-25  3:27     ` Greg KH
2005-06-25  4:16       ` Dmitry Torokhov
2005-06-25  9:39         ` Michael Tokarev
2005-06-25  3:05 ` [RFC] bind and unbind drivers from userspace through sysfs Bill Nottingham
2005-06-25  3:26   ` Greg KH
2005-06-25  4:22 ` Dmitry Torokhov
2005-06-29 23:47   ` Greg KH [this message]
2005-06-30  6:13     ` Dmitry Torokhov
2005-06-30 16:01       ` Greg KH
2005-06-30 20:20         ` Dmitry Torokhov
2005-07-01 22:31           ` Greg KH
2005-07-02  4:25             ` Dmitry Torokhov
2005-07-02  4:51               ` Greg KH
2005-07-02  5:20                 ` 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=20050629234755.GA19599@kroah.com \
    --to=greg@kroah.com \
    --cc=dtor_core@ameritech.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@digitalimplant.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