Messages in this thread | | | Date | Fri, 22 Feb 2002 14:45:32 +0100 | From | Martin Dalecki <> | Subject | Re: [PATCH] 2.5.5-pre1 IDE cleanup 9 |
| |
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/
| |