From: David Brownell <david-b@pacbell.net>
To: Jeff Garzik <jgarzik@pobox.com>, Greg KH <greg@kroah.com>
Cc: rusty@rustcorp.com.au, kaos <kaos@ocs.com.au>,
linux-kernel@vger.kernel.org
Subject: Re: 2.5.47bk2 + current modutils == broken hotplug
Date: Wed, 13 Nov 2002 15:00:05 -0800 [thread overview]
Message-ID: <3DD2D975.6020302@pacbell.net> (raw)
In-Reply-To: 3DD2C30B.9000404@pobox.com
Jeff Garzik wrote:
> Greg KH wrote:
>
>> On Wed, Nov 13, 2002 at 03:59:56PM -0500, Jeff Garzik wrote:
>>
>> >(tangent warning!)
>> >Another long term idea I would eventually like to realize is the removal
>> >of device ids from the C source code. ...
Hmm, maybe Linux should use Microsoft's ".inf" file syntax? %-)
That's one thing that it achieves, at the cost of serious chaos
when the files with the device IDs get out of sync with the
drivers they supposedly work with.
>> True, this would be nice, but how would the driver know to bind to a new
>> device, if it isn't rebuilt, and doesn't know about the new id that was
>> just added? In the current scheme of driver matching to devices, I
>> don't see how this could be done.
It'd be good if we had ways that user mode tools can request drivers be
bound and un-bound. "usbfs" has some support for that, not exactly
packaged in the way I'd most like (and "usbfs" is problematic too).
> I think that truly seamless rebinding is doable but would require too
> much additional complexity in the kernel. Rebinding to a new id table
> between unregister() ... register() pairs, or between mod unload and mod
> load, should be enough to be useable for 98% of the cases.
I'd rather not try swapping ID tables ... likely better to keep some
of that information compiled in to the drivers, but also ADD ways that
user mode tools can modify the bindings that the kernel does (or doesn't)
establish. Unless someone wants to get radical and insist that ONLY the
user mode tools can define such policies (after bootstrapping is done).
Of course Greg's example of a Palm could be addressed using current
infrastructure and module parameters, with "wildcard" binding (to
make sure the driver can see if the device matches the parameters).
- Dave
next prev parent reply other threads:[~2002-11-13 22:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-13 20:11 2.5.47bk2 + current modutils == broken hotplug David Brownell
2002-11-13 20:17 ` Greg KH
2002-11-13 20:40 ` David Brownell
2002-11-13 20:59 ` Jeff Garzik
2002-11-13 21:07 ` Greg KH
2002-11-13 22:45 ` David Brownell
2002-11-13 21:24 ` Jeff Garzik
2002-11-13 23:00 ` David Brownell [this message]
2002-11-14 3:46 ` Rusty Russell
2002-11-14 8:02 ` David Brownell
2002-11-14 10:01 ` Rusty Russell
2002-11-14 16:19 ` David Brownell
2002-11-14 17:42 ` Rusty Russell
2002-11-14 10:41 ` Gerd Knorr
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=3DD2D975.6020302@pacbell.net \
--to=david-b@pacbell.net \
--cc=greg@kroah.com \
--cc=jgarzik@pobox.com \
--cc=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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