On Tue, 2007-02-13 at 10:06 +0100, Dietmar Hahn wrote:
>
> my main goal at the beginning was to fit in the existing x86-mini-os
> structure with as few changes as possible.
> The PAL/SAL/EFI comes in when I tried the timer stuff. I found, that xen-ia64
> doesn't support the wallclock time stuff, so I had a look at PAL/SAL/EFI to
> get the entrypoints to the SAL and PAL functions (for processor and board
> clock ticks, ratios and efi time). If there is another way to handle the
> timing stuff, we can remove this.
> The ACPI stuff was only a try to use more than one vcpu and to see how the
> firmware emulation works. This can be removed for a mono-cpu mini-os.
> I used parts from FreeBSD because I had some experience with ia64-FreeBSD.
> The other side is that mini-os maybe the base for a proof of concept,
> including the big endian stuff (I wrote earlier about this on the list), so
> there is a legal reason (no usage of GPL code).
> As you can see, there are no special design decisions, it's mostly driven by
> practical considerations.
Hi Dietmar,
Ok, sounds reasonable, thanks for the explanation. I'd appreciate if
you'd make another pass through the patch to clean up white space
differences (I noticed some tab indenting mixed with space indenting),
line wrapping (80 column please), and maybe think about cleaning up some
of the bootverbose code with an inline. I haven't looked at
FreeBSD/ia64, so I'm not sure which pieces are simply FreeBSD coding
style quirks. I'm assuming that since this is a very simplified OS that
we won't need to track upstream FreeBSD changes in mini-os. Thanks for
you're work on this,
Alex
--
Alex Williamson HP Open Source & Linux Org.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home