[Syllable-kernel] High-priority bugs, plus adding a HAL portability layer

[Jake H. <jh...@po...>]

First, the "showstopper" bugs that we need to fix before 0.5.7:

1) Reformatting AFS partitions doesn't work correctly.  I ran into this 
problem ysterday when the unzip failed during the 0.5.6 install after 
reformatting my old AFS partition.  Zeroing out the first 100MB of the 
partition with "dd" before reformatting didn't solve the problem. 
Either there is a bug in afs_initialize() or the AFS code is accessing 
sectors on the disk that it shouldn't be accessing that contain old 
data.  I reformatted my partition as FAT (which others have mentioned as 
a workaround for this bug) and will try to reinstall 0.5.6 again.

2) Any other reproducible AFS bugs are high priority.  Fixing our SMP 
issues is high priority.  We should also work properly on large RAM 
systems (>2GB) and I'd like to know if any of Arno's fixes have fixed 
that bug or if it's still present on anyone's system.

3) Glibc issues such as DNS resolving, proper timezone handling, and 
proper locale handling should be fixed for 0.5.7.  Currently GNU gettext 
will crash when building Japanese message catalogs for GNU applications 
(e.g. binutils) due to a library loading bug in the new glibc.  The 
kernel will need to start returning the time in UTC instead of local 
time, and we'll need to adjust by the correct time zone offset when 
loading and saving to the battery backed clock.  If the user is 
dual-booting with Linux, she probably has the h/w clock set to UTC, but 
if dual-booting with Windows, it will be set to local time.  We will 
need a GUI checkbox for the user to select between these two 
possibilities and to select the correct timezone.

I've been thinking about how to separate the x86-specific code from the 
kernel, which would make the code easier to understand as well as to 
port, without compromising the simplicity of the existing code.  The 
model I came up with is based loosely on the Windows NT concept of a 
HAL:  a thin layer beneath the kernel to do things like SMP 
initialization and bus enumeration for a particular platform.  My rough 
sketch looks like this:

All MI (portable) code stays where it is.  Where there is x86-specific 
code now, it will be replaced with calls to hal_xxxx(), functions 
(possibly inline) defined in "hal/xxxx.h".  These functions will be 
implemented in .c and .s files inside a new 'x86' directory and will be 
linked into the kernel (not a module).  In the case of non-portable 
inline functions, the hal header file can include an x86 header file, or 
the appropriate header for another architecture, using #ifdefs to 
determine the appropriate header to include, e.g. #ifdef __i386.  MI 
code can only directly include headers from "inc" or "hal", not from "x86".

Rough sketch of how some existing functions will remap:

kernel_init() [init.c]    ->  hal_kernel_init() + helper funcs
init_kernel_mb() [init.c] ->  hal_early_init(), called from asm startup

spinlock_disable(),       ->  hal_spinlock_disable(),
spinunlock_enable(), etc. ->  hal_spinunlock_enable(), etc.
atomic_add(), etc.        ->  (no change)

cli()/put_cpu_flags()     ->  hal_cli(), hal_put_cpu_flags()

It'd be nice if we had some form of mutex optimized for use inside the 
kernel that would have less overhead than a semaphore and no dynamic 
allocation requirement, like a spinlock.  It might look like this:

create_semaphore(),       -> hal_mutex_init(),
lock_semaphore(),         -> hal_mutex_lock(),
unlock_semaphore(),       -> hal_mutex_unlock(),
delete_semaphore()        ->  (not needed)

dbcon_set_color(),        -> hal_console_set_color(),
dbcon_clear(),            -> hal_console_clear(),
dbcon_write()             -> hal_console_write()

init_smp(),               -> hal_smp_startup()
idle_loop(),              -> hal_idle_loop()
hard_reset(),             -> hal_system_reset()
sys_apm_poweroff(),       -> hal_system_poweroff()
parse_kernel_params()     -> hal_parse_kernel_params()

ISA read/write functions inb(), inb_p(), outb(), etc. can stay the same, 
and the other header files in <atheos/*> should be made portable (using 
inline hal_*() functions for abstraction if necessary).

The kernel header files in 'inc' to move to "x86" are:  cputable.h, 
i82489.h, intel.h, io_ports.h, mc146818.h, mman.h (split into inc/mman.h 
and x86/mman.h), pit_timer.h, smp.h, and virt86.h.

I can figure out the other hal functions as I go through the code, but 
that's the basic idea.  For example in the context switching code, there 
would be a call to hal_swap_context() encapsulating the x86-specific 
register manipulations that are there now.

Some ideas on security coming up..

Jake