DISCLAIMER: These notes are from the defunct k8 project which precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26! The k8 project was effectively a Java SE 8 operating system and as such all of the notes are in the context of that scope. That project is no longer my goal as SquirrelJME is the spiritual successor to it.

00:32

Actually I know why now, loadClass uses the binary name of a class which uses slashes.

00:56

Actually it is the method not being found.

01:11

My method is declared as "public static void net.multiphasicapps.hairball.os.Main.main( net.multiphasicapps.hairball.PackageList,java.lang.String[])", the error states "net.multiphasicapps.hairball.os.Main.main( net.multiphasicapps.hairball.PackageList, [Ljava.lang.String;)". javap has "(Lnet/multiphasicapps/hairball/PackageList;[Ljava/lang/String;)V". So why is this failing?

01:53

Stuck on this for awhile, why does this happen, it has to be dumb.

15:16

OK, the main without PackageList works.

15:20

Caused by a ClassLoader mishap. I would assume since the parent class loader was not set it was causing issues because the sub-called code uses a different class loader. After bootstrapping hairball itself the classloader for hairball is created and then main is executed.

18:22

With this new hairball build system I can remove the old k8-platform stuff and then just toss all of that information into the project.pki files.

19:07

I believe my JSON parser is... nevermind. Right now I am trying to use an array of objects, but they cannot have keys. So instead I am just going to turn them into objects.

19:26

Need to determine the best way to manage kernel configuration, is it just a simple set of options or is it more complex?

19:43

It does not have to be complex like the Linux kernel. In Java there are no

defines and any fields that exist even when final are determined at run-time.

So virtually all options for the most part will not require recompilation at all. Everything could be managed by the kernel command line and any systems options that exist. The basis of the configuration will be selecting a CPU to target, and then selecting the machine to target. After that is optional CPU settings and other packages to include or exclude from the system along with default command line arguments and such. Another thing I will need is a selection of payloads to use (such as ISO, or ROM).

20:27

One thing I am stuck thinking about is self dependency problems. If my bootloader is in Java, it will have to load the classes on the disk which could be inside of any filesystem first, while being itself written in Java and using the associated filesystem libraries before they are available for being read. I could have some kind of hibernation system which is a pre- existing state of memory of all the code. However while that would work, things would be a bit complex and it may waste memory needlessly.

20:35

What I would need to do is have a bootstrap class loader and a static run of the execution path to determine what is used and what is not used. With that run I will need to modify the FormClass loader for Java class files and then include the Java assembly to list the "imports" used by a specific method. Then I would essentially follow the trail of imports. Such import listing would have to handle constructors also. Constructors when it comes to stuff such as calling another constructor with some arguments will need to be handled also. This trial will only need to be done up to a certain point. Static fields will be the most problematic however as they could pull many things in. Java is a very dynamic language and machine, there is no such thing as static.

20:57

I suppose the simplest thing to do is have built-in and external classes. Similar to Linux with built-in and modules. The kerenl would be bound to a set of JAR files on the disk that must be there and not be modified (at least class wise). Then with such a system, I could have built-in support for specific filesystems or load external JARs. Stuff such as JARs would be handled by user space layers so that malicious filesystem drivers do not deal much damage. Well for filesystems, access would be layered. Users could mount any supporting filesystem but they might not have the ability to access raw devices. As such, the filesystems would be rather isolated and require specific permissions. So in short, filesystems are just another process being ran. But anyway, some classes will exist inside the kernel as a giant blob. The Linux kernel at least on my system is a hefty 11MiB with all of its included stuff. I just hope mine stays below 1MiB. The classes that are built- in to my kernel though can be reused by non-virtualized (those using the system provided classes) classloader so they do not need to be reloaded many times, just initialized for each process. Non-virtualized because I plan on permiting userspace processes to spawn virtual machines for emulation or running other systems. In these cases, such processes (the VMs) would be userspace processes that do not use the kernel and execute on their own. They may however use hypercalls and such. There may also be a need for para-virtual (pure userspace) with a custom kernel being used where core classes existing in the kernel are not used. So, having classes which are built-in would simplify things for the most part. Doing that then, I would only need to initialize a base system to actually use the things.