ia64/xen-unstable

changeset 345:dc2e4de1850f

bitkeeper revision 1.159 (3e803a35-Yk3EywTimePoA1HCtTIgg)

TODO:
Updated TODO to suggest a module system for Xen.
author kaf24@scramble.cl.cam.ac.uk
date Tue Mar 25 11:15:01 2003 +0000 (2003-03-25)
parents 8c63ec842aca
children 6b300fe8e6b9
files xen/TODO
line diff
     1.1 --- a/xen/TODO	Mon Mar 24 16:44:31 2003 +0000
     1.2 +++ b/xen/TODO	Tue Mar 25 11:15:01 2003 +0000
     1.3 @@ -16,7 +16,7 @@ spreading them across processor packages
     1.4  
     1.5  What we need to do is port code from Linux which stores information on
     1.6  relationships between processors in the system (eg. which ones are
     1.7 -siblings in teh same package). We then use this to balance domains
     1.8 +siblings in the same package). We then use this to balance domains
     1.9  across packages, and across virtual processors within a package.
    1.10  
    1.11  2. PROPER DESTRUCTION OF DOMAINS
    1.12 @@ -78,7 +78,19 @@ Xen's timebase. Once this is done, we ca
    1.13  not worry about relative drift (since they'll all get sync'ed
    1.14  periodically by ntp).
    1.15  
    1.16 -8. NEW DESIGN FEATURES
    1.17 +8. MODULE SUPPORT FOR XEN
    1.18 +-------------------------
    1.19 +Network and blkdev drivers are bloating Xen. At some point we want to
    1.20 +build drivers as modules, stick them in a cheesy ramfs, then relocate
    1.21 +them one by one at boot time. If a driver duccessfully probes hardware
    1.22 +we keep it, otherwise we blow it away. Alternative is to have a
    1.23 +central PCI ID to driver name repository. We then use that to decide
    1.24 +which drivers to load.
    1.25 +
    1.26 +Most of the hard stuff (relocating and the like) is done for us by
    1.27 +Linux's module system.
    1.28 +
    1.29 +9. NEW DESIGN FEATURES
    1.30  ----------------------
    1.31  This includes the last-chance page cache, and the unified buffer cache.
    1.32