From: Rusty Russell <rusty@rustcorp.com.au>
To: Martin Schlemmer <azarah@nosferatu.za.org>
Cc: Linux Kernel Mailing Lists <linux-kernel@vger.kernel.org>
Cc: Greg KH <greg@kroah.com>
Subject: Re: module-init-tools/udev and module auto-loading
Date: Mon, 02 Feb 2004 11:10:11 +1100 [thread overview]
Message-ID: <20040202003922.3180E2C078@lists.samba.org> (raw)
In-Reply-To: Your message of "Mon, 02 Feb 2004 00:31:58 +0200." <1075674718.27454.17.camel@nosferatu.lan>
In message <1075674718.27454.17.camel@nosferatu.lan> you write:
> A quick question on module-init-tools/udev and module auto-loading ...
> lets say I have a module called 'foo', that I want the kernel to
> auto-load.
The *idea* of udev et al is that the kernel finds the devices,
/sbin/hotplug loads the driver etc.
This does not cover the class of things which are entirely created by
the driver (eg. dummy devices, socket families), so cannot be
"detected". Many of these (eg. socket families) can be handled by
explicit request_module() in the core and MODULE_ALIAS in the driver.
Some of them cannot at the moment: the first the kernel knows of them
is an attempt to open the device. Some variant of devfs would solve
this.
> Then a distant related issue - anybody thought about dynamic major
> numbers of 2.7/2.8 (?) and the 'alias char-major-<whatever>-* whatever'
> type modprobe rules (as the whole fact of them being dynamic, will make
> that alias type worthless ...)?
Yes. This could be changed to probe by device name, not number
though. And most names can't be dynamic: /dev/null has certain, fixed
semantics.
The "I found this hardware, who will drive it?" mechanism of udev, and
the "User asked for this, who will supply it?" mechanism of kmod have
some overlap, but I think both will end up being required.
Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
next prev parent reply other threads:[~2004-02-02 0:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-01 22:31 Martin Schlemmer
2004-02-02 0:10 ` Rusty Russell [this message]
2004-02-02 19:02 ` Martin Schlemmer
2004-02-03 0:55 ` Rusty Russell
2004-02-03 4:55 ` Martin Schlemmer
2004-02-03 17:48 ` Martin Schlemmer
2004-02-03 19:33 ` viro
2004-02-03 20:47 ` Martin Schlemmer
2004-02-03 20:53 ` viro
2004-02-03 21:34 ` Martin Schlemmer
2004-02-04 1:22 ` Rusty Russell
2004-02-04 2:04 ` viro
2004-02-04 3:43 ` Rusty Russell
2004-02-02 5:21 ` Greg KH
2004-02-02 18:12 ` Jamie Lokier
2004-02-02 19:14 ` Martin Schlemmer
2004-02-02 19:13 ` Martin Schlemmer
2004-02-02 7:20 "Andrey Borzenkov"
2004-02-02 7:34 ` Greg KH
2004-02-03 15:00 "Andrey Borzenkov"
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=20040202003922.3180E2C078@lists.samba.org \
--to=rusty@rustcorp.com.au \
--cc=azarah@nosferatu.za.org \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®