Gadi Oxman wrote:
> Hi Martin,
>
> ide_module_t was designed to conceptually divide the code to multiple
> layers,
> whether one actually uses modules or compiles all the IDE code into the
> kernel,
> and in the future, to alow several parallel implementations of the same
> functionality
> which could reside in the kernel simultaneously.
>
> The job was not finished, but the original idea was to have:
>
> 1. Core IDE code.
> 2. Chipset modules.
> 3. Probe modules.
> 4. Subdriver modules.
>
> ide_module_t was created so that the core IDE code could track all the
> modules
> currently available to it, and to be able to have several chipset drivers
> for the same
> chipset simultaneously, several probe modules simultaneously, and several
> subdrivers
> for the same device type (so that one could choose the one which works
> best).
The normal linux way using multiple driver implementations are
aliases in /etc/modules.conf - see for example ALSA vers. OSS sound
drivers for the same hardware.
> The last example was actually used in ide-scsi.c. The intention in
ide-scsi is intendid to be gone in 2.5.x.
> ide_module_t was
> that one would be able to have, for example, ide-cdrom + ide-scsi or
> ide-tape + ide-scsi
> in the kernel simultaneously (either compiled in or as modules), known to
> the
> core IDE code, and one could then change drivers for a single drive on the
> fly using
> something like "cat driver_name > /proc/ide/hdx/driver".
See above that is *not* the proper interface for implementation choice,
which is *user* policy anyway and can be handled fine by the
existing generic module interface infrastructure.
For the sake of modularization. I have already at home a version
of ide-pci.c, where the signatures of chipset initialization
source code modules match the singature of a normal pci device
initialization hook. This should enable it to make them true modules
RSN.
The chipset drivers will register lists of PCI-id's they can handle
instead of the single only global list found in ide-pci.c.
> Upon receiving such a command, the IDE core could call the cleanup code of
> the driver which was originally assigned to hdx, the cleanup code would
> de-attach
> the driver from hdx without unloading the module and without affecting the
> other drives which are currently supported by it. The core code could then
> call the init code of the other driver to attach to the device.
>
> The reason ide-probe was splitted to a different module is that in most of
> the
> time, one doesn't need the probe code in the kernel. It is needed during
> boot, and
> each time one "hot swaps" an IDE device. In addition, it could provide the
> framework
> for having several probe modules simultaneously, altough that never
> materialized.
It's inventing too many races (in esp. in the hot plug case) and the
module would be too small for beeing worth it:
[root@kozaczek ide]# size ide-probe.o
text data bss dec hex filename
8445 16 0 8461 210d ide-probe.o
[root@kozaczek ide]# size ide.o
text data bss dec hex filename
30951 521 9376 40848 9f90 ide.o
[root@kozaczek ide]#
(BTW.> I hate the ALSA OSS emultaion module splitup as well.)
As it goes about the possibility of multiple different probe
implementatoins - please show me a different one.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Feb 23 2002 - 21:00:41 EST