Fordi's blog

uDSL - Delays, delays, delays

Well, it's April, and the work on uDSL continues.

I blame my discovery of UnionFS. It makes my dream of a unified ramless extension system real.

Well, that, and the advances in things like udev and a minor patch to the loop kernel module (nothing big, just that my kernel now supports a full whopping 1M loop devices.)

That, UnionFS and SquashFS put together let me make a 10M DSL core with the ability to add any software you want at no extra charge.

Well, some extra charge. from my calculations, you'll need an aditional 64k of ram per extension you add on.

Additionally, everything's being cross-compiled from scratch for two target platforms: i386 PC and G3 Mac.

uDSL - a personal experiment

I wish to make an attempt to rebuild the entirety of DSL with a few implementation changes - an attempt to squeeze a few more bytes out of the already tight DSL project.

1: everything (and I do mean everything) will be rebuilt from source using uClibc.

2: I will be building a 2.6.10 kernel using the knoppix 3.7 configuration.

3: SquashFS will be implemented upon KNOPPIX. sqsh type modules will be supported.

4: The x apps, all user applications, and basically anything non-system will be removed and repackaged. X-based user apps will be available in the least ram-using packages if available (like firefox), or be given a new package if not. The generic command line non-system and x apps will be in udsl-clapps.sqsh and udsl-xapps.sqsh.

SquashFS update

Ok, I'm having fun with this:

I have a squashfs.o that works in DSL 0.9.1, and will continue to work until DSL runs under a new kernel. It DOES NOT REQUIRE A NEW KERNEL. That's right. It's just a module, and you can plug it in just like any other module.

mksquashfs seems to work just fine with no extra libs.

I'm working on an experimental proof-of-concept design for a SquashFS DSL module. It will have all the benefits of both .dsl and .uci extensions, along with a feature stolen from .deb packages, but will not occupy much RAM at all.

Essentially, it gets mounted like a uci. Since the package for this is (and has to be) a dsl, mkwriteable is already run. Once the module is mounted, it is linked into the root filesystem, its user.tar extracted into your home dir, and /sdmrc run (the feature stolen from .deb packages - controlscripts). It also has /etc/init.d/sdm-config and /etc/rc5.d/S02sdm-config linking to that - ensuring that you can have .sdm - type modules on a liveCD.

XML feed