From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Jansen Date: Tue, 16 Oct 2001 07:58:38 +0000 Subject: Re: Automatic download and installation of drivers. Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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/, 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