> It will allow building and testing by people without 2 computers and
> ethernet (aka etherboot).
I meant, as opposed to booting from the HD and handing control off
to JJOS directly -- why slow JJOS down even more by using the emulator?
Is there some technical difficulty with using the i386's ELF/stipped
binary? (I'm rather ignorant about booting, so it might be really
obvious...)
> The first as a developer "bundle" including the sources (if any) you
> needed in order to get the "base" versions of either jos or bochs to
> work. Do we have a clear abstraction of a booter ala JavaOS or
> would checking a second booter into CVS cause conflicts?
We don't have a distinct abstraction for the booter, but the JJOS
kernel does need to be handed the ramdisk information. Checking a second
booter into the CVS would work fine, but we'd probably cast it as a third
architecture or an option in the i386 makefile.
> The second as a pure binary for those that just want to get the
> base running. This second dist won't be super useful right now, but
> as soon as we get a classloader ready (do we have a classloader
> ready?) people can use the system to mess with adding class
> library support without actually hacking the kernel. It is also a
> good first look at a possible system demo.
Er, the classloader is ready and works fine, with the exception
that native code doesn't work at all, which is OK because JJOS doesn't
support that right now anyway. The problem w.r.t. classloading is the
lack of an fs/device driver. Someone (can't remember who offhand) is
writing a FD driver, so floppy-based classloading (i.e. not from the
pre-compiled ramdisk) should be possible soon, although extrordinarily
clunky.
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
