> I got tired of the problems with the resource management - lack of
> hierarchy, and the stupid and utterly horrible static allocation.
>
> So I rewrote it. The new one can generate resource trees: you can claim a
> piece of the pie, and then within that piece you can continue to do
> resource management. And the new one doesn't have any arbitrary limits or
> magic constants (0 is IO, 1 is MEM is gone, gone, gone).
I've finally returned home and looked at your new resource code. I like
the generalization you've done, but I think it still needs several
improvements:
(1) We need a way how to search for free region to assign to a new
device (for example when a new card is inserted or when the BIOS
forgets to assign an address to a PCI device). This is exactly
what the occupy_region function Dave Hinds has written and I have modified
was doing. It needs to be given a resource pool, minimal and maximal
address allowed (several devices limit address ranges they're
able to process) and also required alignment (PCI regions must
be aligned on a multiple of their size).
(2) For this address allocation we need to know not only which regions
are allocated by drivers, but also which ones are in use by devices
even if there is no driver handling them. This can be done by making
generic bus code (which enumerates all devices on the bus) allocate
all the regions automatically, but then we need to modify all the
drivers not to request the regions and leave it only in ISA drivers.
This requires changing almost every driver, but it's a clean way to go.
(3) As we are in need of doing such major changes, it would be better to
take this chance and generalize the things even a bit more: introduce
a concept of `device' (represented by a structure having a generic
header and bus-specific fields), automatically attach resource regions
to devices during bus enumeration and then attach drivers to devices
during driver init. [This has been described in detail in in the
bus/device/hotplug proposal I've sent to linux-kernel a month ago.]
If you agree with this course, I'll start implementing it immediately.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Beware of bugs in the above code; I have only proved it correct, not tried it."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/