From: Rusty Russell <rusty@rustcorp.com.au>
To: linux-hotplug@vger.kernel.org
Subject: Re: [PATCH] input hotplug support
Date: Wed, 29 Oct 2003 00:15:27 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-106747010425731@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-105977896014708@msgid-missing>
In message <200310282119.01702.arvidjaar@mail.ru> you write:
> > Thanks, I've applied this patch. Did your module-init-tools patch make
> > it into that package too?
>
> No, Rusty was against it. You should have received those mails as well (you
> were on Cc at least), subject was
>
> "module-init-tools - input devices id support"
Let's go through this again.
1) I don't understand what you want. eg. for USB devices, they're
used to match the USB device to the USB driver for autoloading.
You seemed surprised when I suggested you could autoload the input
drivers: but what else would you want this information for?
2) While a naive approach to aliases would make aliases for input
drivers about 1000 chars long, that's just a good reason not to use
a naive approach. I already suggested one approach based on the
looking at the current drivers in the tree.
3) Since we're talking about 5 drivers in all, you could simply
hardcode them if this is all too much trouble for you.
4) You *have* been informed that this is changing, months ago. As
soon as Greg tells me that hotplug scripts no longer need those
tables, they will be removed in favour of the aliases which exist.
5) If you want some tables for other reasons, there's no reason for
you not to generate them yourself. Experience has shown that this
method is fragile, but that's your choice.
6) You're confused about external modules: the module supplier runs
file2alias as part of the build process, the user runs depmod as
normal, so no problems.
> I really think that keeping module-init-tools in sync with kernel is not much
> more difficult than keeping file2alias in sync with kernel.
But they are *distributed separately*, so for the end user, it's much
harder to keep them in sync. That's been one of the main aims of the
new module code: kernel independence.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
prev parent reply other threads:[~2003-10-29 0:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-01 21:39 [PATCH] input hotplug support Andrey Borzenkov
2003-08-01 23:57 ` Greg KH
2003-08-02 8:53 ` Andrey Borzenkov
2003-10-13 23:56 ` Greg KH
2003-10-28 18:19 ` Andrey Borzenkov
2003-10-29 0:15 ` Rusty Russell [this message]
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=marc-linux-hotplug-106747010425731@msgid-missing \
--to=rusty@rustcorp.com.au \
--cc=linux-hotplug@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).