I attached the release Schedule. I am also volunteering to be in charge of it. JAn
xMach Release schedule Sunday, May 13, 2001 version 0.1 • Booting version 0.2 • OpenBSD Userland version 0.3 • Move device drivers out of kernel • Update FS interfaces/VFS • Fix disk support to allow large disks. version 1.0 Remove all known Bugs. version 1.1 • Ports/Packages - OpenPackages? • Add a wider variety of syscalls to Lites • Better documentation of code - all files have detailed information on what they do, and how they do it. The comments should read like an essay, so its easy to understand what is going on. It is not a goal to rewrite working code for better readability - that would introduce bugs. • Do good documentation and manpages. Manpages for all syscalls. Developer handbooks. We will compile all availabe information about mach that still applies to xMach. version 1.2 • Installer Post 1.2 • SMP • Device driver interfaces for *BSD/Linux/Windows • High performance filesystem (Journaling?) - FFS + SoftDep? XFS? Elephant? • FAT Binaries • X11 support/KDE/GNOME. This needs to work as port, and not be part of the os... • Fully re-entrant libraries • Distributed processing Ideas/wishes that need further discussion • Source-level compatibility with *BSD/Linux • Move from a.out/mach-o to ELF • Multi-server BSD layer • Decent User-Interface - Berlin? X11? • See if there are any ideas we can incorporate from other projects - HURD? Darwin? OpenBSD? NetBSD? FreeBSD? Linux? • Security officer • Working groups • Conference • UNIX standars (POSIX, XPG4, ...) compliance. On this item, we need to decide what UNIX standards we want to comply with. POSIX is a no-brianer, but the emulator emulates an environment, like FreeBSD and not a standard. Therefore we will be as standard compliant as the environment we emulate. • Avoid religion wars - No Sendmail/Postfix/QMail BIND/djbdns/maradns. - All of this should be in ports anyway. • Focus, make decisions, keep the base system small - anything that is not explicitly needed should be optional. Since everything in mach is a user proccess anyway, we can put all this in /usr/ports • Good development chain/environment • NEXTSTEP/OPENSTEP API - should we try to be compatible with MacOSX API? They are using a lot of NS... • Modern VM - UVM? FreeBSD VM? • Consistent feel/userland across platforms • Be portable to/provide ports to modern architectures • Fully localized text • Unicode from the ground-up
