More modularization.

[Mike A. Harris]

Peter Lemenkov wrote:
> Hello, All!
> 
> Just my simple proposal. If we look into mesa-libGL package, we'll see a 
> number of dri-modules:
> 
> [petro at Petro ~]$ rpm -ql mesa-libGL
> /usr/lib
> /usr/lib/dri
> /usr/lib/dri/i810_dri.so
> /usr/lib/dri/i830_dri.so
> /usr/lib/dri/i915_dri.so
> /usr/lib/dri/mga_dri.so
> /usr/lib/dri/r128_dri.so
> /usr/lib/dri/r200_dri.so
> /usr/lib/dri/radeon_dri.so
> /usr/lib/dri/savage_dri.so
> /usr/lib/dri/sis_dri.so
> /usr/lib/dri/unichrome_dri.so
> /usr/lib/libGL.so.1
> /usr/lib/libGL.so.1.2
> 
> I (and many others, definitely) haven't neither i810-based cars, nor 
> others from this list. So question is - why I enforced to install all of 
> these dri-modules? We can simply split this package into a bunch of 
> little packages, for example mesa-libGL, mesa-dri-i810, mesa-dri-i830, 
> etc. It''s not a hard work, IMO.

This is a long term possible feature.  In order for this to happen, here
is what needs to be done:

1) The upstream Mesa project needs to be autotooled, so that it has a
    sane buildsystem that works like everything else that is a part of
    modular X.  Adam Jackson has expressed interest in possibly taking
    this task on once X11R7 ships.

2) The upstream Mesa project needs to be enhanced to provide a driver
    development kit of sorts, similar in vein to the Xorg SDK which we
    currently use to build all of the 2D drivers in their own individual
    rpm packages.  Once this is provided by the Mesa project, it then
    becomes easy to split the driver sources out of the project if
    desired, and build them separately.

3) The 3D drivers need to have metadata files included with them of
    some sort to indicate what hardware they support based on PCI ID
    information, similar to what we need for the 2D drivers.  That
    information needs to be coupled with the driver source, or generated
    dynamically from data contained in the drivers.

4) The Fedora Core installation and X configuration tools need to be
    updated to have the ability to ask for the Fedora CD and/or to
    be able to download uninstalled drivers for the hardware, should you
    put in a card that a driver exists for, but which you have either
    chosen not to install, or have intentionally uninstalled, thinking
    you will not need it or do not want it for whatever other reason.


In all previous operating system releases, all of the drivers (both
2D and 3D) were all built from one giant monolithic tarball.  They
were installed from a single giant tarball for multiple reasons.  One,
was to ensure that all of the drivers were always installed, so that
the installation and configuration tools could be simple.  You don't
want the config tools to configure X to use a driver that is part of
the operating system, but is not currently installed.

Allowing people to choose to not install drivers, or to uninstall
individual drivers, without having support in the operating system
for easily downloading drivers or getting them from the CD when they
are needed, would be a terrible mistake, and a massive support
nightmare from hell.  Bugzilla would overflow with "you didn't ship
my driver" bug reports by the dozens.

Having said all of this, I hope this helps to understand what is needed
in order for this feature request to become a reality.  If someone
is interested in hacking on anaconda and/or system-config-display to
add the support needed for downloading drivers with yum, and asking
for CDROM/URL/harddisk or whatever like Windows does, that would be
a step in the right direction for seeing such a feature exist in
Fedora Core sooner.


> The same thing with kernel. Not all of kernel-modules are needed 
> actually. Why don't repack kernel into kernel, kernel-modules-all (which 
> contains nothing, actually, but installs a huge number of small packages 
> with modules itself - the way xorg-x11-drivers does).

The X server has a stable Xserver<->driver ABI in one direction.  This
means that from one bugfix release of a driver to the next, the driver
will work with the same X server.  And new X servers generally will
work with the drivers they shipped with, as well as drivers from the
previous release or two.  Every few releases of the X server, something
sometimes changes which breaks the ABI however, but it is generally
quite stable for 1-2 years or so.

The kernel on the other hand, very intentionally does not have a
kernel<->module ABI at all whatsoever.  Last I heard, Linus had no
interest in giving the kernel a stable module ABI.  Having the
kernel broken up into a bunch of individual per-driver modules
would probably be a massive nightmare.  I wouldn't hold your breath
waiting for that to happen.  ;o)