linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).