From: Tim Jansen <tim@tjansen.de>
To: linux-hotplug@vger.kernel.org
Subject: Re: Automatic download and installation of drivers.
Date: Tue, 16 Oct 2001 07:58:38 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-100321906517638@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-100319421829170@msgid-missing>
On Tuesday 16 October 2001 07:29, you wrote:
> > Automatic download and installation of drivers. That is definately a
> > good thing to have (in general).
> Wow, the security implementations and other complexities involved here
> are huge. Let try a few examples:
> - installing a module requires root permissions. You generally
> do not want to run a compiler as root.
> - Running anything as root isn't a good idea, unless the program
> has been audited for security problems.
> - Who is going to sign/verify the driver you just downloaded
> to prevent a trojan from being installed?
> - Lots of user machines do not have compilers installed. What
> then?
> - Where are you going to find the .config file that the
> currently running kernel was built against? Without that, you
IMHO there are two choices for auto-installation. The easier one is to use
distribution specific packages, then most of the problems do not apply. Only
if you want to distribute drivers in source form you have to take care that:
- the sources of the installed kernel are available at a well-known place
- you have a well-defined compilation environment. You have to make rules
which gcc version, which make version and so on has to be available and at
which location (or alternatively you need a configuration file that describes
their location). You need to be propared that the user has two compilers
(gcc&kgcc).
- you need to know how to install and maybe also de-install modules in the
system (it should provide a script for that)
- you need the configuration file of the installed kernel
- possibly you need the ability to re-compile the kernel itself if a needed
configuration option is missing (for example enable V4L if the user installs
a webcam). This can be quite complex which would be a reason to do this only
with CML2.
- ideally there would be a way for a installed driver package to add its own
configuration options to the kernel. For example if you would install each
drivers source in a directory /usr/src/linux/drivers/<driver-name>, then CML2
could automagically include all /usr/src/linux/drivers/*/Config.in files.
This, of course, is a LOT of work.
> But the main question I have is:
> What is the real problem that you are trying to solve?
> and
> Why does the current kernel/driver situation not work for you?
1. It makes it much easier for a user to find a driver that's not included in
his distribution. Linux drivers are usually named after the chipset's name or
the first device that was supported. How can a user know that his Logitech
Quickcam Pro 3000 needs the pwc (philips webcam) driver? And where can he
find the driver?
2. (source driver packages only) right now the situation for drivers authors
who want to distribute their drivers to end-users is really bad. Either they
make it complicated for their users and distribute the drivers in source
form. Even now I would guess the majority of Linux users is not able to
compile their own drivers, and hopefully the percentage will be much lower in
a couple of years. Or the driver author provides binary packages for each
version of each distribution. It is a lot of work and still won't help all
users. This is probably one of the reasons that so few hardware
manufacturers provide Linux drivers.
bye...
_______________________________________________
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
next prev parent reply other threads:[~2001-10-16 7:58 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-16 0:02 Automatic download and installation of drivers Stamatis Mitrofanis
2001-10-16 5:29 ` Greg KH
2001-10-16 7:35 ` David Brownell
2001-10-16 7:58 ` Tim Jansen [this message]
2001-10-16 11:38 ` Keith Owens
2001-10-16 16:52 ` Greg KH
2001-10-16 18:44 ` Tim Jansen
2001-10-16 18:58 ` Tim Jansen
2001-10-16 19:19 ` Greg KH
2001-10-17 2:01 ` David Brownell
2001-10-17 2:03 ` David Brownell
2001-10-17 18:47 ` Tim Jansen
2001-10-17 19:24 ` David Brownell
2001-10-17 23:31 ` Tim Jansen
2001-10-17 23:32 ` Greg KH
2001-10-18 0:07 ` Dmitri
2001-10-18 0:19 ` Stamatis Mitrofanis
2001-10-18 0:47 ` Tim Jansen
2001-10-18 2:17 ` Keith Owens
2001-10-18 2:35 ` Dmitri
2001-10-29 21:53 ` Greg KH
2001-10-30 8:26 ` Tim Jansen
2001-10-30 17:21 ` Greg KH
2001-10-30 21:24 ` Tim Jansen
2001-10-30 21:51 ` Dmitri
2001-10-31 12:36 ` Keith Owens
2001-10-31 20:49 ` Greg KH
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-100321906517638@msgid-missing \
--to=tim@tjansen.de \
--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).