Thoughts about mod-boot

I've been recently thinking about where to take mod-boot, and one thing that I decided was to look into using Python instead of C. C is plenty faster of course, but I'm not convinced that in this case it would be a big deal, but I do know that it'll increase maintenance quite a bit. Of course, bourne scripting might be the best option, but I really hate bash. Meh, I'll get more serious about mod-boot after my stupid math course stops sucking up all of my time.

Development paused

Development of mod-boot has paused (These words usually indicate the semi-death of one of my projects, dooming them to be forever in a state of almost-under-development-ness), to allow me to, foremost, get on track with my math assignments, but also so that I can rethink some design elements about mod-boot and to work on another project idea I had.

Design cleanup

Having partially read the first chapter of the excellent The Art of Unix Programming, by Eric S. Raymond, I've been thinking more about the design of mod-boot in terms of simplicity. One portion that called attention to itself was the blockList concept that I explored in an earlier post. It's an interesting concept I think, but it adds a lot of code that 99% of the time will only end up taking up more memory. It would be simpler and in most cases faster just to use either a standard array or a GArray or something.

Also, I've been thinking about the concept that if a program doesn't have anything helpful to say, it should just shut up. I'll have to work on this aspect, but it'll have to give what the user and other programs need; nothing more, nothing less (Good: Fedora. Bad: Debian. Worse: Slackware).

There's other matters I shall have to look in to as well to simplify the project.

blockList

I hit a wall recently with mod-boot. Basically, when I parse a script file, I need to be able to store all the data given. However, I don't know before-hand how many dependencies the script will have, or how many features it provides. I could use a standard array, but that would be inefficient since I would have to allocate like 25 memory slots of which I might only use 3, and if something needs more then 25 slots, well, that's tricky now ain't it? I could use a GArray, which is a handy little feature of GLib, but unless I'm wrong, whenever you exceed your allocated memory, it has to allocate more and copy everything over, which gets inefficient, and if it works like the C++ STL vector template, then I'm still wasting a lot of memory. I could use a linked list, but that's slow to loop through.

Hence the need for blockList. Basically, it's a doubly linked list implementation where each node has an array. When you first create the blockList struct, you give it a number of bytes per array element (as with GArray), and a default number of elements per blockListElement (basically a node; I should rename it). It then keeps track of the number of blocks currently allocated, and the address of the first and last nodes, so that it can get to any given element as quickly as possible. The programmer can of course manually allocate a block with X elements, but that should also be handled transparently when an element is appended. It's currently not yet finished, but it's getting there. And it's fully 100% memory leak free, too!

mod-boot

Recently I had an interesting idea to improve boot speed on FOSS operating systems. I'll give some basics here, and then sometime maybe I'll add some more details on my website.

It started some time ago when I was reading all the Fedora stuff that was being planned and/or thought about, and something struck me as very interesting: Early GDM. Basically, the idea was that, instead of starting all the services needed for a runlevel during boot, you only run what's absolutely needed for GDM, and then once GDM and X.org is up finish with the other stuff.

I thought that was a brilliant idea, since it could lead to really short boot times. So I thought about it, and my idea is to have init start a C program with different command line options depending on the runlevel init wants, and then the C program would be in charge of running various daemons and configuration scripts asynchronously with a dependency system so that the user can configure with a configuration file what the goal daemon is. What I'm thinking of then is a directory for each runlevel, and all the scripts in each runlevel are analyzed for dependencies and a viable parallel execution order is run using forks and pipes. I'm not sure how backward compatibility will work (since every vendor has their own system... *groan*...), but I think something could be gimmicked with links since I'm not replacing init itself.

I've already designed a simple algorithm to determine the execution order, but I'm still attempting to optimize it so that it will work in parallel for performance reasons (especially now that all the major vendors have 4-core processors).

Tell me what you think.