public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: linux-kernel@vger.kernel.org, Patrick Mochel <mochel@digitalimplant.org>
Subject: Re: [RFC] bind and unbind drivers from userspace through sysfs
Date: Fri, 24 Jun 2005 20:26:39 -0700	[thread overview]
Message-ID: <20050625032639.GA3934@kroah.com> (raw)
In-Reply-To: <20050625030553.GB7380@nostromo.devel.redhat.com>

On Fri, Jun 24, 2005 at 11:05:53PM -0400, Bill Nottingham wrote:
> Greg KH (greg@kroah.com) said: 
> > 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.)
> 
> Playing devils advocate, with this, the process flow is:
> 
> - kernel sees a new device
> - kernel sends hotplug event for bus with slot, address, vendor id, etc.
> - userspace loads a module based on that info
>   <some sort of synchronization here waiting for driver to initialize>
> - userspace echos to sysfs to bind device
> - kernel sends hotplug device event
> - userspace creates device node, then continues with device

Yeah, I'm not saying I think it's a good process flow for people to
implement.  But if they want to, they now can.

The main reason for this is for drivers that replace built in drivers,
or multiple modules for the same device (think of new rev of driver,
both loaded at once, some devices should bind to the new one, other
devices you want staying with the old one due to it controlling your
root partition.)  Now userspace has a chance to unbind and bind devices
to drivers in those situations, which it never could before.

But remember, I'm not changing the way things bind to devices here, like
requiring userspace to pick the driver for the device, so no one lives
will change at all, if they don't want to.

Hope this helps explain it.

greg k-h

  reply	other threads:[~2005-06-25  3:27 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 [this message]
2005-06-25  4:22 ` Dmitry Torokhov
2005-06-29 23:47   ` Greg KH
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=20050625032639.GA3934@kroah.com \
    --to=greg@kroah.com \
    --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