whitix.org

It’s been suggested to me that I should explain some of the technical decisions I’ve made on the project’s weblog. Here’s the first of (hopefully) a long series of articles about the technical elements of a modern desktop operating system. In this article, I’m going to explain and detail my recent redesign (or rather a redesign in progress in a Subversion branch) of the Whitix kernel.

The plan, at the moment, is to make Whitix a hybrid kernel, mainly to ensure stability. But hybrid in what way? Basically, most of the kernel at the moment will become modularised (even the slab allocator and virtual filesystem; a general rule is anything that has a *Init function in the current kernel will be modularised) and moved to userspace, where they’ll be linked in to the kernel at runtime using the kernel’s new module code. This will all happen at different points in the kernel’s startup procedure; some core modules will be loaded into memory at boot-time, where as drivers can wait a good deal longer before being loaded.

The advantages of moving a lot of driver and stack code is that it ensures system stability. A lot of the system crashes I see, in Whitix, Linux (see kerneloops.org) and other operating systems, involve null pointer errors or page faults in device drivers and subsystems, rather than in the core kernel code. Moving stacks and drivers to userspace means, that when they do crash, the kernel can look at the instruction pointer (eip) and determine which module crashed, and if so, reload it. (which may just involve resetting the module)

Surely the kernel needs some system functions that will now be modularised in userspace? Some functions, like malloc and other memory allocation functions, can still be called by the kernel (using a trampoline function down to userspace, much like how the kernel can transfer down to userspace for tasks) using a function pointer whose value is set by a GetModuleSymbol(<symbol>)-type function. The kernel can return a link to a stub function that transfers the CPU into userspace and then the real function.

How do the userspace drivers call kernel code? (or how does system code return to the kernel?) My proposal is for a seperate interrupt that transfers to any point in the kernel (the interrupt would check the EIP of the calling process, and ensure it came from a driver, rather than a user process). This interrupt would be called by a stub function in the kernel, which would be generated by a SYMBOL_EXPORT define. The kernel would return to userspace via the usual iret method.

One advantage is that there could be a DRIVERS_IN_KERNEL define, which would move all the modules into the kernel; losing the increased stability, but also decreasing the number of privilege switches while still retaining the modular aspect of the new design.

At the moment, development of this new kernel is taking place in the branches/hybrid/ section of the Whitix development tree. Want to help out? See the becoming a developer section of the wiki.

In the next tech talk article, I’ll go over (with code examples) the hybrid kernel design in greater detail. Thanks for reading.

It’s now here.

The latest version of Whitix, V0.1, has just been released by the development team. The new release includes a whole load of new code, a fully featured desktop and graphical user interface (Xynth), ports of new languages such as Lua, and a whole host of other features and bugfixes that you can scroll through over at the changelog. Just type ‘xy’ at the command line to start Xynth up (the next release will include a startup program, so you won’t even have to do that!)

You can download the new release here. Let us know what you think by leaving a comment.

Just a quick note to announce that there’s a new Whitix release candidate, 0.1rc2! This has quite a few bug fixes (thanks to reports from the bug tracker), and the GUI and other programs are now much more responsive. Give it a go, or you can wait for the 0.1 release at the end of the month. It’s your choice!

See the download page for more.

In preperation for a proper 0.1 release by the end of this month, we’ve put together the first release candidate. This release includes the new GUI, xynth (complete with a new terminal program), and other updates to the core system; we’ll put up a changelog for the proper 0.1 release (we’ve lost count of features and bug fixes in just two weeks of intensive development!).

Download it from here. This release will have bugs and glitches, so if you do find them, report them at the bug tracker.

The port of Xynth, a free window system, is coming along nicely. Although the development mailing list may seem a little quiet at the moment, it’s only because we’re hard at work adding new features and fixing lots of bugs.

Xynth includes a desktop program, and ports of GTK+ and FLTK, so Whitix will receive a fairly functional desktop (and by 0.1! How efficient are we?). We’ve currently got a VGA driver working, but plans to implement drivers for several more modern cards (including a 2D NVidia driver) are in the works.

See the screenshots of Whitix for more.

We’ve recently ported the popular scripting language Lua to Whitix, so you now have a choice of two high-level languages. If you’re a developer (or wish to build Whitix from source), you can get Lua from the ports directory by using the portdownload.sh script. What other language ports would like to see? We’ve already got plans to port the GCC toolchain, but we’d like to hear suggestions. Leave a comment here with your ideas.

In other news, work towards 0.1 continues. We’re going to take a bit more time over this release, so expect one by the end of this month. We’ll include a lot of bugfixes, new features, and a fork of Xynth, a windowing environment, named Blaze. Yep, you read that right. Whitix will soon have its own GUI. Watch this space.

Just a short note to announce that Whitix 0.03a is now available for download. See the download page for more. The release fixes many issues that users were having with booting or running the operating system. See the changelog for more. Post any bugs you may have with this release to the bug tracker or the user mailing list.

Big news - we’ve now ported Python to Whitix. Porting it to the platform meant writing a lot of POSIX and libc stubs, many of which can be expanded. See the list of POSIX stubs for an idea of what’s left to do.

A new port download script has been committed to the Subversion repository. At the moment, you can download tcc, nasm and python (tcc and nasm have been removed from the repository and will not be present in future source downloads). This should make it easier to combine, store and alter ports for Whitix. (See the ports for a list of ported software).

With the addition of local network sockets, ATA bug fixes (as some users reported their CD drives were not being detected) and new software ports, Whitix 0.03 is now released. See the download page for the source and CD image.

After two weeks of intensive development, we’re proud to announce the latest version of Whitix, 0.02, is now for download. The changelog is full of new features and bug fixes; why not download it and check it out? Devfs now supports directories (and is a lot more flexible as a result), the filesystem has been tidied up (/Devices is now at /System/Devices, all user applications are now in /Applications). A basic FAT filesystem formatter, mkfatfs, is now included in the ISO.

We’re adhering to the “release early, release often” mantra (every two weeks is not an impossible goal!), so each release will have one or two new features that make Whitix much more usable. See the download page for more.

After setting up the commit mailing list, public subversion repository and a developer framework, we’ve had 50 commits in a matter of days. Work continues at quite a pace towards a 0.02 release (hopefully by the end of this month). Why not join the effort? Check out the code from svn://www.whitix.org/svn/projects/Whitix, make a change (try searching for TODOs or FIXMEs) and e-mail your patch to developers@whitix.org.

If you’ve got a feature you particularly wanted added to Whitix, but you’re not a developer, send an e-mail to users@whitix.org or start a feature request on bugs.whitix.org. We’ll reply to every request!