Alan Cox wrote:
>>If I hadn't tought about it I wouldn't be that advantegrous.
>>And my testing of it did consist of the following:
>>
>>1. 2 x IDE drives of one IDE port.
>>2. 1 x CD-RW on a second port - modularized.
>>3. 1 x CarBus to CF adapter.
>>
>
> So you didnt test or consider the upcoming things like hotplug.
I did plugging and unplugging a CardBus IDE contoller in and out on
a hot system.
> I'm sure the cleanup works now, but imagine if I was to "clean up" Jens
> new block code by removing all the stuff he has there ready for next
> features.
Well the hotplug/suspension problem is certinaly to be targetted by
using the struct device_driver infrastructure and not by reduplicating
it's fuctionality inside ide.c. Agreed? Before one could even thing
about this the splitting between ide_driver_t and ide_module_t *had* to
be removed.
Just have a look at the massive code duplication between init_module
and driver_reinit functions inside the subdrivers to see why this is.
Before this can happen one has to untagle the flow of the current
driver. Like for exampel double calls to module initialization
functions. The device detection part *has* to be pulled
out from the corresponding module initialization routines - yes I'm
aware of this. But I would rathter like them to find they home
inside the following:
struct device_driver {
int (*probe) (struct device *dev);
int (*remove) (struct device *dev);
int (*suspend) (struct device *dev, u32 state, u32 level);
int (*resume) (struct device *dev, u32 level);
}
instead of ide_driver_t ide_hwif_t or whatever the ide-typdef of the day
is.
Finally: Before something can go in - well something has to go out.
In esp. if it is in the way and the removal doesn't cause any loss
modulo current functionality.
This is the reaons of the FIXME notes I have itroduced here and there
inside the patch as well.
But currently one has to fight far too frequently
with functions which are exported without any justification or
different functions which basically just do the same, games on
ifdef's inside headers and so on...
-
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:35 EST