On Fri, 2007-10-05 at 10:48 -0800, Jeff Spaleta wrote:
> On 10/5/07, David Zeuthen <davidz@xxxxxxxxxx> wrote:
> > But you're right; it's about balance; there's a couple of kernel drivers
> > we don't ship because they're just too obscure. Or they're too buggy. Or
> > too bloated. Whatever. Ideally our OS should be able to detect the
> > hardware and properly request for the driver / enabling software to be
> > installed (clearly, this won't work for kernel drivers now that kmod's
> > are banned but there's a lot of other stuff in userspace).
>
> Detection of this at install time?
No, it's basically the wrong mindset to think that we only need to
detect hardware at install time; with hot pluggable buses like USB,
Firewire, whatever, hardware can come and go at any time. So any
solution that only works at install time is just fundamentally wrong.
In fact, the installer just be just an installer; not it's own little OS
with it's own private hardware detection routines; that kind of services
should be part of the core OS and the installer should take advantage of
it as should the environment the user normally use too (e.g. the desktop
or commandline tools)
> Even if all the pieces to do that
> are available, doesn't that require some significant re-think in
> installer package management? At the very least we'd have to have a
> list of packages associated which each sort of hardware detection flag
> that could be parsed by the installer. Using what we have currently as
> a starting point, you'd essentially have to group things in a comps
> group associated with each detection criteria, and then teach anaconda
> to set that group to install by default if the detection criteria is
> met.
Yes, it's a can of worms; basically what most "Enterprise" distros do
(because they have a kABI and support vendor drivers not shipped with
the OS etc.) is to use RPM Provides: with the modalias for what the
driver in the RPM support. So it goes like this
1. Plug in your hardware
2. Find the modalias for the device (look e.g. in sysfs)
3. yum search $modalias
4. yum install package-that-you-found
It's not really difficult to imagine this could be automated; you'd have
a small tray icon saying "yo, I don't have a driver for this device;
would you like to search for one?".
Of course the party line of Fedora is (or used to be) that we install
all drivers in the default install and that renders the problem moot. In
fact, I think it's a bit silly to build all this infrastructure just
because
- we've changed the party line from "we ship all drivers in the default
install" to "we don't ship all drivers in the default install". This
kind of baffles me; I'm not really sure DVD space and hard disk space
is that expensive.
- it creates the illusion that Fedora has a stable kABI; that's just
wrong
- it'll never work for kernel drivers anyway and the majority of
interesting drivers are indeed in the kernel
- it's just plain annoying having to click through crap like that
just because we decided not to ship all drivers in the default
install. Of course, such a gizmo has the side effect to tell
you if the hardware you just plugged in is supported or not so
we may end up doing something similar *anyway*.
> And when installing from livecd targets... could you discriminate in a
> similar fashion and only install to disk the hardware specific
> userspace bits that system needed? I think that'd be tougher since the
> livecd's install a pre-cooked disk image with all the bells and
> whistles already installed.
I can't really see what's wrong with "we ship all drivers in the default
install" but if we want to change it we need some of that silly
infrastructure above to make the system Just Work(tm) when you e.g. plug
in a USB smart card reader.
David
--
Fedora-desktop-list mailing list
Fedora-desktop-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-desktop-list
