mmlib/mmat: replace some variables by literal constants
[mmondor.git] / Xisop / TODO
1 $Id: TODO,v 1.20 2004/10/14 15:13:20 mmondor Exp $
2
3
4 - Import modifications from mmsoftware/mmlib:
5   - New more efficient pool allocator, with enhanced debugging capability.
6     This could imply reworking some of the whole system.
7   - Maybe incorporate C byteorder library, so that less processor-specific
8     code is required (of course, they can override C ones with asm ones).
9
10
11 Working:
12 =======
13 - Memory management system and ANSI-C related functions
14 - Syscalls, including one which allows to execute arbitrary code in supervisor
15         mode
16 - Exclusive, recursive and read/write locks
17 - User interrupt facilities
18 - Preemptive multitasking, _yield() and task_sleep()/task_wakeup()
19 - CPU saving ideling
20         When no tasks are on the ready queue to run, the _scontext _ctx_t
21         defined in scheduler.c is resumed, which in fact returns to main.c's
22         main() function, which sole purpose is to sys_idle(), in a loop,
23         which suspends the processor until the next interrupt occurs.
24 - Serious exceptions generate a display showing a number of lines which
25   corresponds to the actual error (_ecatch() parameter), useful to debug
26   the current Amiga port.
27 - Useful statistics book-keeping of global counters
28 - Inter-task signals
29 - Inter-task communication reliable ports and messages
30 - The init and task reaper system tasks
31 - Operations which need fast lookup tables to use kernlib/hash.[ch].
32   This is done for some system lists, such as for port_find().
33 - Multiple tasks shareing a common mpool_t created with TF_SHARED
34
35
36 Bugs to work out:
37 ================
38 - There again is some problem with memory or stack sizes. When DEBUG and
39   STATISTICS are enabled in config.h, things do not work as intended.
40   This seems to simply arise now that the kernel image is about a k larger.
41   For some reason, the ports/amiga/boot/config.h values do not seem to
42   always generate proper kernel images, for instance when I increase the
43   stack size to 16384 I get a guru meditation...
44 - The scheduler which takes task priorities into account is currently not
45   working. There is a temporary replacement scheduler which works now and
46   only performs round-robin when preempting tasks. The old one which has
47   some bugs is found in src/common/kernel/scheduler.c and is called
48   old_schedule().
49 - Signals and message ports
50         Some hack should be found a more appropriate solution: signal_send()
51         needs to _yield() twice (See src/common/kernel/signal.c).
52         For some not yet determined reason, tasks would all eventually be
53         stuck on the wait queue if this was not done.
54
55
56 Remaining to complete:
57 =====================
58 - Add system similar to mmlib/mmalarm(3) to Xisop, to go with the existing
59   MI interrupt hook management functions
60 - Perhaps use hashtables in exceptions hooks management instead of linked
61   lists? Is this needed or wanted? Running through a hash table is slower,
62   but lookups are faster. Think about it and see which is best to use.
63 - Fix issue with amiga port init stack size... m68k usermode() could
64   be specified a stack size for instance, at least. We also could
65   reserve some memory for the stack in advance and supply it...
66 - Implement setjmp()/longjmp() for i386
67 - CPU specific _bfill16 and _bfill32 etc (at least _bfillint or such),
68   to efficiently fill a native word size with an 8-bit pattern. This
69   could be used by the string library in memset() for instance...
70 - Probably that the cases of usecount (devicenode_t, mpool_t) could use
71   an _rlock_t for more efficiency. It is implemented in assembler, and
72   is sure to be atomic.
73 - Finish dprintf() FIFO operation optimizations, and write a generic
74   vsnprintf() implementation with stdarg. We want to enhance DPRINTF()
75   to print module and line numbers, etc.
76 - _panic()
77 - Console and printf() (along with corresponding console.device)
78 - Map remaining exceptions to output messages on console
79         For the console.device to eventually exist, the port primitives are
80         essencial. So until they work reliably it's not really possible to
81         implement right now (at least on Amiga).
82         It would be easy to use the video hardware memory on a i386 port
83         however, so a i386 port could perhaps actually help in development
84         for the rest :)
85         Ports implementation is now working reliably. Revise.
86 - Probably that the statistics would also be nice to have on a per-task basis.
87         Moreover, they are not as useful as they would if a console existed :<
88         currently, the DPRINTF() system logs to a FIFO buffer.
89 - Xisop shared libraries
90 - Xisop devices as a synchronization abstraction over the message ports system
91 - Xisop handlers as a higher-level (filesystem/file) abstraction over devices
92   libraries and/or hardware
93 - Relocatable binary loader
94         This unfortunately either implies writing a full fledged ELF or a.out
95         loader, or a BFD library for GCC ld to output in a new desired format.
96         The ELF loader was started but was not completed (not included in the
97         current sources). ELF unfortunately seems really bloated for the
98         actual needs of this project, and it's state is uncertain.
99         The loader would be used to load shared libraries, and executable
100         tasks, including devices and handlers.
101         For the moment, the system is monolithic and soon a simple interface
102         will be provided to allow the port-specific code to provide a list
103         of tasks to be launched by Xisop init.
104         That alone, even monolithic, allows Xisop to stand as a nice C
105         interface which most code is portable among 32-bit systems, to abstract
106         interrupt facilities, shared memory access and multitasking for
107         various applications. Very small, it can fit the application on a
108         floppy (which includes the kernel).
109 - timer.device
110 - input.device
111 - console.device
112 - Add necessary functions to allow linking in the common/kernlib/hash.c module
113
114
115
116 NEW MEMORY MANAGEMENT SYSTEM NOTES:
117
118 As before, we need several types of memory.
119 For each memory type, we should still attach/detach memory chunks, like now.
120
121 For each memory chunk, a new system should be implemented for page-level
122 contiguous memory management and freeing, as well as a new pool allocator,
123 based on the idea of the new mmlib/mmpool(3) one.
124
125 Because Xisop does not rely on MMU/PMMU, we can simplify the allocator to a
126 simple block allocator, without even worrying about page boundaries, if we
127 wanted. This would also mean that a pool page could be virtual, that is, could
128 not be dependent on the system page size at all, if we wanted. If that was the
129 case, the current mmlib/mmpool(3) allocator could be used as-is.
130
131 Not to say that, even if we respected page alignment, we still could use a
132 better allocator.
133
134 A good idea would be to maintain a list of contiguous page (or memory bytes)
135 chunks. Nodes of this list would be split as necessary to provide the
136 requested size in the allocation functions. The freeing functions would need
137 to attempt to coalesce the contigious chunks together when possible as well.
138
139 Perhaps that we also would like a best-fit strategy rather than first-fit when
140 allocating, so that we could favor contiguous memory chunks that are closest
141 in size to the requested amount, rather than always splitting large chunks
142 unnecessarily. This would reduce fragmentation, although being slower at
143 allocation. However, because this would affect the page allocator, to which
144 calls would be reduced by the pool allocators, this could be reasonable.
145
146 Perhaps that to observe the best-fit strategy it would be possible to somewhat
147 maintain a sorted index or such, of the smaller to larger available chunks.
148 It needs to be verified that the code and memory overhead for such an index
149 is negligeable, however. Moreover, would keeping a sorted list of free chunks
150 useful for performance? How would the allocator efficiently perform jumps in
151 the list? Wouldn't it need to be a tree, instead? If we used one, wouldn't we
152 need recursion or special iteration for both node insertion and lookup? I will
153 need to check that out. What I should do is count the iterations in my similar
154 sorted tree system in dnamed, to get an idea of the actual code overhead
155 involved.
156
157 struct contiguous_chunk {
158         node_t chunks_node;     /* To link in free/allocated chunks list */
159         node_t sorted_node;     /* To link in free chunks sorted list */
160         void *address;          /* Starting address of free memory */
161         size_t length;          /* Size of contiguous free memory */
162         u_int32_t pages;        /* Or, could be number of free pages */
163 };