William Lahti wrote:
> AOT
> - Core
> - Core.Tests
> - Kernel.Tests
> - Main
> Data
> - KeyMaps
> Kernel
> - Core
> - korlib
> References
> - Mono.GetOptions.dll
> - Mono.Cecil.dll
> Tools
> - KernelTestsWrapperGen
> - KeyCompiler
>
> We also plan to store the SharpOS userspace at trunk/Userspace. What
> do you think about this layout? Was the old one better?
>
It's definitely better. Actually, it could go even farther, just so that
"things are in place for the long-term". As most everyone knows that I'm
working on the out-in-left-field parts of the kernel (runtime VM, etc),
my code was already strewn about in odd places here locally. This is
what I had built here:
SharpOS.Compiler
- AOT
- JIT
- ADC
- X86
- PPC
- Optimizers
- IL
SharpOS.Kernel
- ADC
- X86
- Boot: Arch-dependent boot
- Boot.cs (our current Kernel.cs entrypoint)
- Asm: Arch-dependent assembly opcode stubs
- Schedulers
- Memory: Top-level here handles raw memory
- Pagers
- GCs
- SysRun: More or less what is currently known as korlib. This is the
lowest-level runtime needed for the kernel itself
- IPC
SharpOS.Hardware: Hardware drivers
SharpOS.Graphics: Non-hardware graphics layers
- 2D
- OpenGL
SharpOS.Audio
SharpOS.Net: Non-physical network stacks (e.g. everything above OSI
Layer 1 / Physical)
- IPV4
- IPV6
- TCP
- AppleTalk
SharpOS.DSSFS: Data-Storage System / File Systems. Top-level here holds
our VFS layer, common filesystem code, etc
- Ext2
- FAT32
- NTFS
- CDFS
- ZFSCore: The core of Sun ZFS
- DSS: Our native ZFS-based object data storage filesystem
SharpOS.GUI
- Remoting
- Widgets
SharpOS.TextMode
System.*: CLR Base Class Library wrappers into our API
That's the namespace layouts. As you may see, there really isn't much
"userspace vs kernel space" distinction. It's unnecessary, considering
we're a microkernel all running in the same memory protection space. The
"kernel space" is the kernel itself, which doesn't even handles drivers
and such.
For the directory structure, I personally am a fan of individual build
directories (e.g. SharpOS.TextMode\build, SharpOS.TextMode\src, etc
instead of build\SharpOS.TextMode). And I would rather we move the
References directory back into whatever module needed them, or maybe
even start splitting out the References directory into which module
needs them (e.g. References\SharpOS.Compiler). Tests should also be in
their own subdirectory under the module root (e.g. SharpOS.Kernel\Tests).
That's as much as I've come up with for now.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
SharpOS-Developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
