From: Stamatis Mitrofanis <ewstam@softhome.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: Linux-hotplug-devel digest, Vol 1 #144 - 5 msgs
Date: Wed, 10 Oct 2001 19:47:08 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-100274690723928@msgid-missing> (raw)
From: Keith Owens <kaos@ocs.com.au>
>On Mon, 08 Oct 2001 01:05:45 +0100,
>Stamatis Mitrofanis <ewstam@softhome.net> wrote:
>
>>... a server will return info about how the client can
>>find appropriate driver software (like a precompiled kernel module
>>packaged together with appropriate driver agent scripts... or the source
>>code for a kernel module... maybe a ready-to-install
>>RPM/Debian/Slackware package...).
>>
>A precompiled kernel module will not work, trust me on this. Modules
>must be compiled with the same config options, with a compatible[*]
>version of gcc, for SMP or non-SMP and for multiple architectures. The
>only way that will scale is a source driver. But that assumes that
>everybody using the server has a current set of sources and config for
>their kernel.
>
Well, a "configure" script would be good to use for source code. It
would return success/failure depending on whether the local
architecture/configuration is known to work for compiling the driver. If
it's not, then manual compilation and installation is required. Drivers
should be tested on as many kernel versions as possible and the
"configure" script should do any necessary tweakings to make the driver
compile on the particular system (as GNU apps do).
By "format" I didn't refer only to a file format that drivers are
packaged in but also to certain semantics -- like "how is this package
compiled and installed?". So, a driver that comes in source code in a
.tar.gz and has a "configure" script that must be run before make is in
different "format" than a .tar.gz that doesn't need "configure".
Also, installation of a driver should have its mirror (uninstallation)
as well. Of course, it's not very practical to install/uninstall a
driver every time it's devices are plugged/unplugged, so it should be
left to the user to uninstall the driver when necessary.
pcimodules should do the high-level management for downloading and
installing a driver. It contacts the server to find out where the driver
is, downloads the "resource" and then passes control to a specific
"resource agent" which can install/uninstall this kind of resource.
Resource agents are placed in /etc/hotplug/driver and they accept:
ACTION={install,uninstall}
RESOURCE=/filename/of/resource.extension
TYPE={tarball,tarball_gnu,...}
That also suggests adding a new "driver.agent" to be called by
/sbin/hotplug .
If no one is willing to work on this, I'll try to set up some
client-side scripts on my localhost.
_______________________________________________
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
reply other threads:[~2001-10-10 19:47 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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-100274690723928@msgid-missing \
--to=ewstam@softhome.net \
--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).