Fwd: TODO (how ppl can help)

[James Larkby-Lahet]

In no particular order, but we really should get this online in an
obvious place, and keep it up to date

you can spend our money, write our code, upgrade your grey matter(brizain), organize or incorporate us, document, port, design, redesign;
userspace or kernel there is something in XOmB for Soulja Boy's best
friend: YOU!

Documentation)
- at a minimum, put this list online in an obvious place, so newcomers who want to contribute know what they can do to help
- appoint website maintainer
- clean up xomb.org, wiki.xomb.org, ask appropriate ppl for content/updates as needed
- document code
- document processes (or establish processes) for common tasks
- In-Our-Own-Words series, sum up what we know about a peice of hardware (the APIC, geting to 64-bit long mode on an x64 chip) or software (how to build a cross-compiler)

Reading!!!!!/Research/Writing)
- read about git and figure out a 'workflow' -- then write it up
- Device Driver models -- how do we manage the coming insanity?
- write an OS book
- read an OS book, and tell us what you learned, or how your vision ofXOmB changed
-  read modern and classic OS papers in a particular area
- trawl the internets on a topic and present what you learned as a teaching segment in a xomb meeting
- trawl and compare other ppl's code solving a given problem (e.g. linux vs smaller OS like syllable, haiku, other systems you find on osnews.com)
- read about tech businesses and pick an open source business model for XOmB inc

XOmB the .org)
- figure out what we need to incorporate XOmB (I can call in some lawyers, mebbe for free, for the actual incorporation)
- figure out 'code assignment' so that ppl turn their code over to XOmB org which administers the license terms
- how to get non-profit status
- do we need to be a non-profit to be part of 'google summer of code'?
- get us into summer of code
- non-profit to apply for grants?
- write grants
- what pgh-local orgs are there for tech startups -- Pittsburgh Digital Greenhouse, Alphaworks, Northside Community Development, incubators, etc.

XOmB the .com)
- can nonprofits do alphaworks? 20 week, $25k incubator of pgh tech startups
- can has business model?

Profiling and tradeoff analysis)
- how long does a context switch take?  a system call?  interrupt overhead?  IPIs versus standard interrupts?
- pick an app you care about and an existing OS, figure out where it spends most of its time and how the OS is impeding it

D lang)
- gdc is dead, D 2.0 is coming
- port XOmB to D 2.0 and D-style inline x64 asm in prep for switching to ldc (or any open source, maintained compiler)

Kernel)
- I/O buffer manager (in prep for FS, and maybe network)
- market/bidding mechanisms for RAM and Quantum allocation
- security model
- implement a full ACPI runtime for device detection -- standards compilance is always a selling point and this would help the device push
- (multicore) Virtual memory manager -- read about VMMs and figure out what we need to do
- multicore cache coherence foo -- figure out what x86 'invalidation' instructions we must execute when updating page tables, use IPIs to invalidate cache/TLB on other processors

new kernel)
- port XOmB to ARM, Sun's Niagra, Itanium, PowerPC etc.
- port XOmB to EFI bios replacement (unless you have an Apple, you get to buy an EFI dongle or two to turn 'normal pc' into 'EFI pc' )

Kernel-side? Devices)
- ne2000 network card driver (this is the psuedo-device from Xen)
- SATA/AHCI driver
- USB driver
- pick a GPU for us to buy and then port it to XOmB
- pick a NIC (preferably with built in support of virtualization) for us to buy and then port it to XOmB

Userspace devices)
- Intel-VT + intel VMQD? virtualization for intel network cards
- can GPUs be virtualized?
- pick an accelerator, GPU, FPGA, Creative's Zii reconfigurable 'stem cell' computing, or Intel's upcoming Larrabee and write a userspace library exposing it to Applications
- also, find a task that we care about accelerating :)

Userspace memory pseudodevice)
- super-ultra userspace memory management -- malloc, garbage collector, multicore slab allocator, Virtual Memory Managment, etc.

Applications and Demos)
- german ruler demo
- use xomb for distributed computing (P2P, heterogeneous hardware, high chance of node failure)
- javaVM -- it'll be fast as hell with no 'host OS' and modern compiler techniques
- start designing a clustered webserver with accomanying server scripting language (miniD?) and database (initially, I'd just assume SQL goes to a 3rd party Database, let oracle do oracle)
- use a port of Wine or ReactOS to build a remote-desktop windows App-farm (this is Citrix' business model, they also do virtualization)
- write optimized/clustered network fileserver (this is netapp's model, they sell commodity hardware with software profit margins)

Userspace executable foo) -- write OR port
- executable loader with general ELF support (and llvm bytecode, and java bytecode :)
- when do we zero BSS, how do we find _start, other fun executable philosophy
- 'runtime linker' dynamic library support

Userspace Compat) - we are bring UNIX along with us, so we won't be condemned to repeat it
- port libc & standard C++ library
- port UNIX languages and tools of your choice
- determine what is necessary for wider POSIX support (e.g. networking)

Userspace D)
- port tango
- appoint port maintainer, as tango is definitely a quick-moving target

Userspace XOmB)
- write RAMFS libos, patch into libc and tango
- do we want D libOSes to be based solely on tango, on a subset of tango, or on our own homegrown libd?

Userspace Windows)
- port wine or reactOS as a libOS for Windows support
- port Mono / .NET CLR virtual-machine

Kernel-userspace interface)
- method for issuing batches of system calls for maximum win, along with wrapper code on both sides to manage it

Virtual machines)
- (reiterate: port javaVM or ,NET CLR applcation virtual machines)
- port xen to XOmB
- implement xen paravirtualization API or VMware API to support VMs natively as 'applications'
- use Intel-VT to fully virtualize a client OS (in this case it is unaware that it is a VM client)

===a good independent study===
- in a similar vein, implement a "dynamic binary translator" -- more a 'generic framework & custom plugin' approach to allowing apps for different OSes and even completely different CPUs to run on XOmB
- port Dr. Childer's "Strata" dynamic binary translator to XOmB, which can probably then be used for Application virtual machines, running foreign binaries, AND xen/vmware emulation

Get Famous)
- implement Apple's OpenCL standard for parallelization and acceleration (you'd be the first :)
- port/implement other popular or up-and-coming specs and if-possible participate in the working group in charge of the spec
- perl 6 doesn't count :)

Toolchain)
- get ldc working for x64
- maintain a separate git package of everything one needs to build xomb, with scripts to automate the process
- appoint a maintainer to keep tools synced with upstream releases
- script testing of new compilers so maintainer knows if new releases break stuff

Testing & Committers)
- pick some committers
- have things to commit
- kernel unit tests?
- userspace unit test support
- start scripting (or borrow) a harness for regression testing
- consider the addition of 'contracts' to our D programming for greater testing and fault detection

[James Larkby-Lahet]

I should also note that with most of our OS in userspace, a dynamic binary translator at the kernel level could make porting to new CPUs _really_  easy.

In the other direction, It might (dont ask WHY we'd do this) possibly allow unprivleged userspace running of XOmB (as an application) on top of <insert name of OS>.  (maybe good for debugging/testing/porting/demoing?)

all this on top of the basic goals of runtime program optimization and allowing us to run foreign binaries and 'bytecode' style languages natively.
its basically the XOmB Unversal Translator (and compiler, interpreter, virtual machine and optimizer) which I shall christen Xombot.

I'll be talking (selling) to Dr. Childers about this on thursday, is there anyone possibly interested in this (besides me :) on our end?

cheers,

James

[Steve Klabnik]

All of this is epic win, James. If I get some time tomorrow, I'll get some wiki-ifying going on.This shouldn't just be on the mailing list.

Yeah, we need to have a real meeting soon, with everyone who's anyone on this project, and get some of this shit straightened out. Like, the processes and workflows and such.

[James Larkby-Lahet]

I don't want to decend into religous war with the following, but some planning may be in order

build system:
hierarchical make considered harmful?
I vote for rebuild for D stuff(at a minimum for applications), since it will handle statically linking only the modules a program imports
others?

remember that build tools should ideally fit into the "things you need to build XOmB kit" neatly, without tons of dependencies

some day soon we will be developing XOmB on XOmB... and porting all these lovely toys and their dependencies (git implies ssh, I don't wnnna think about what svn implies :)

tango, gdc and dsss (with rebuild) tend to be distributed together for similar reasons

along with this
Restructure codebase(s):

-our code vs. foreign repos (in practice we may require this foreign code to live at a place known to the scripts, do we manage changes with their version control or ours?)
do we hook in to thier build scripts?

-kernel vs. userspace vs. libos (is this a useful distinction for us?) vs. c libraries vs. c++ libraries
vs. applications vs. 'servers'

- language libraries vs. language (or compiler) runtime 'libraries'  is this what libexec is for?

-general applications vs. appps that actually should be bundled with the OS
common kernel code vs. machine dependent (looking to porting)

-device drivers  && userspace devices


---we might not agree on a directory structure but what are our goals?
-hide unrelated code
-group code that is edited together
-???

--package managers also seem related to this topic. and while we are at it, distribution methods.  Is there a way we can combine gittorrent repos together?  mebbe a git-torrent based packge manager?

as it stands now our goal is to provide a complete-source system and a 'supported' build environment built on open tools.
adding in a method for others to provide similar assurances about their contributions seems like a good thing (this could also be provided by old school '/contrib' or generally lax committer standards :)

cheers,

James