From: Roman Zippel <zippel@linux-m68k.org>
To: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
<linux-kernel@vger.kernel.org>, <greg@kroah.com>,
<jgarzik@pobox.com>
Subject: Re: [PATCH] Module alias and device table support.
Date: Fri, 31 Jan 2003 23:33:54 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.4.44.0301312045440.9900-100000@serv> (raw)
In-Reply-To: <Pine.LNX.4.44.0301302351550.15587-100000@chaos.physics.uiowa.edu>
Hi,
On Fri, 31 Jan 2003, Kai Germaschewski wrote:
> exactly great. In doing that, I already notice unresolved symbols and warn
> about them, which I think is an improvement to the build process, missing
> EXPORT_SYMBOL()s tend to go unnoticed quite often otherwise.
The problem here is that we use System.map, it's not that difficult to
extract the exported symbols:
objcopy -j .kstrtab -O binary vmlinux .export.tmp
tr \\0 \\n < .export.tmp > Export.map
> Doing this postprocessing unconditionally would allow to generate the
> alias tables at this point as well.
>
> And while we're at it, we could add another section which specifies which
> other modules this module depends on (a.k.a which symbols it uses), making
> depmod kinda obsolete.
It makes sense to keep depmod close to the linker, as both need the same
knowledge about resolving symbols, but I still don't know why that would
be a reason to put it into the kernel.
It doesn't really matter if that information is generated during build or
at install, it just has to be at /lib/module/`uname -r` in a way modprobe
understands. BTW for my taste modprobe has too much knowledge about the
module layout, which actually belongs to the linker.
I finally looked a bit closer at the module alias. The possibility of
wildcards is certainly interesting, but besides of this it looks to me as
if we exchange one crutch with another. The alias string is too static
and cryptic. Adding information to it requires changes at too many places
(let alone adding information dynamically).
What I'd really like to see is a really generic but still simple system to
match devices and drivers, e.g. describing properties like this:
bus=usb
vendor=0x1234
product=0x4321
device=1-3,5
Forcing the matching onto modprobe doesn't look like a good idea to me, as
IMO it takes too much away from hotplug. The alias string is not usable
for hotplug, but above properties can be used to trigger other operations
beside module loading.
bye, Roman
next prev parent reply other threads:[~2003-01-31 22:25 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-31 0:09 Rusty Russell
2003-01-31 6:23 ` Kai Germaschewski
2003-01-31 9:41 ` Horst von Brand
2003-01-31 15:42 ` Ingo Oeser
2003-01-31 22:33 ` Roman Zippel [this message]
2003-02-01 0:48 ` Kai Germaschewski
2003-02-01 1:22 ` Roman Zippel
2003-02-01 2:59 ` Kai Germaschewski
2003-02-01 10:31 ` Roman Zippel
2003-02-01 3:49 ` Rusty Russell
2003-02-01 7:20 ` Kai Germaschewski
2003-02-01 23:02 ` Horst von Brand
2003-02-03 0:52 ` Rusty Russell
2003-02-03 2:49 ` John Levon
2003-02-03 10:34 ` Rusty Russell
2003-02-04 9:56 ` Horst von Brand
2003-02-05 0:00 ` Rusty Russell
2003-02-03 8:31 ` Horst von Brand
2003-02-03 10:52 ` Rusty Russell
2003-02-04 8:05 ` Horst von Brand
2003-02-04 8:51 ` Rusty Russell
2003-02-06 23:09 ` [PATCH] Restore module support Roman Zippel
2003-02-06 23:25 ` Greg KH
2003-02-07 0:01 ` Roman Zippel
2003-02-07 4:06 ` Greg KH
2003-02-07 9:39 ` Roman Zippel
2003-02-07 18:01 ` Roman Zippel
2003-02-07 0:10 ` Russell King
2003-02-07 4:53 ` Rusty Russell
2003-02-07 10:03 ` Russell King
2003-02-07 6:12 ` Kai Germaschewski
2003-02-07 9:46 ` Roman Zippel
2003-02-04 14:49 ` [PATCH] Module alias and device table support Roman Zippel
2003-02-03 13:40 ` Roman Zippel
[not found] <20030201073007$5418@gated-at.bofh.it>
[not found] ` <20030201073007$3e7f@gated-at.bofh.it>
2003-02-01 10:36 ` Arnd Bergmann
2003-02-04 17:25 Adam J. Richter
2003-02-04 17:45 Adam J. Richter
2003-02-05 0:17 ` Rusty Russell
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=Pine.LNX.4.44.0301312045440.9900-100000@serv \
--to=zippel@linux-m68k.org \
--cc=greg@kroah.com \
--cc=jgarzik@pobox.com \
--cc=kai@tp1.ruhr-uni-bochum.de \
--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
all inboxes | Powered by JetHome®