ShinyBSD didn't happen how I would have liked it to; instead of making a nice, shiny new BSD, I discovered something (awesome?), that TinyBSD is an amazing tool.
However, I did learn a lot which can help out members of the FreeBSD community; cross compiling, using TinyBSD to save lives, or at least to make tiny, tiny operating systems. Crunchgen and its beauty, and how it's failing to meet some modern needs. Generally, it's helped me become more familiar with the OS as a whole and more confident about the idea that I can work on the source code. At least, if it ever gets made into a git tree.
See, something I have been convinced of is that using something like Perforce for source control management isn't a great idea. It's a proprietary tool, and while FreeBSD is certainly much more pragmatic than many other communities online, it's still saying something when one of the many open source source control management tools isn't being used for some reason. SVN is good enough for the actual mainline code of the OS, why not also for the staging areas?
Anyway, enough politics, on to code.
if [ -d /usr/src ] then mv /usr/src /usr/pudding echo "moved stuff" fi ln -s /FreeBSD/src /usr/src echo "linked /FreeBSD/src to /usr/src" if [ -d /usr/obj ] then mv /usr/obj /usr/pudding_objects echo "moved /usr/obj to /usr/pudding_objects" fi ln -s /FreeBSD/obj /usr/obj echo "linked /FreeBSD/obj to /usr/obj"
if [ -h /usr/src ] then unlink /usr/src mv /usr/pudding /usr/src echo "moved /usr/pudding to src" fi if [ -h /usr/obj ] then unlink /usr/obj mv /usr/pudding_objects /usr/obj echo "moved /usr/pudding_objects to /usr/obj" fi
These two scripts helped me a lot. I was cross compiling, and having a separate working area for cross compiling tools is a neat thing.
Cross Compiling as a process is covered in many good documents. The most useful might be:
It might well be a solid project to see if there's any way to get this running on FreeBSD: http://www.gnuarm.com/support.html -- in either case the bottom of the page provides a lot of good information for building a cross compiler.
ShinyBSD is to be a new embeddedBSD; it's based loosely on the mold of PicoBSD, with an eye towards an additive method of creating a small BSD rather than a subtractive method, such as NanoBSD and TinyBSD take.
The essentials of the idea is this: take a bottom up view of creating an embedded OS. When I've been creating embedded linux based OSes in the past, I've done so by compiling the kernel with the minimum necessary featureset, the moving forwards with busyBox to create a striped but fairly complete system.
The idea is to take crunchgen and work upwards from a basic knowledge of the FreeBSD system requirements, while working downward from the stripped version of FreeBSD that TinyBSD can generate, and hoping to meet up somewhere in the middle.
One thing that makes this project different from some of the other GSOC projects is that its milestones are goals reached using existant FreeBSD tools, not the actual development of inherently new FreeBSD tools.
The beneath is a list based upon the original proposal, however, much is changing. I'll leave the original milestones list as context, and then move on to a discussion of current developments.
--begin legacy material--
1. First four weeks: research into and development of a small (32mb) FreeBSD based OS.
Due to design decision changes, this deadline has not been met. Eek! However, the research performed thus far is expected to assist significantly in the next time period, and I am not concerned by not having my deliverable to hand. Revised date for deliverable is Sunday June 22. I started off fooling around with NanoBSD until such a time as it became apparently that NanoBSD's approach would not work. Instead, I am looking at using a PicoBSD style approach, which is similar in spirit to TinyBSD. I will use TinyBSD as the base, but with the PicoBSD style crunch.conf to crunch things down.
Another reason this deadline has been missed is that I have been working with the hardware platform which is the aimed boot platform; an atmel board. This is trickier to work with in some ways than a VM, simpler in others.
2. Second four weeks :
This was to be allocated to performing the specific kernel configurations that would assist. As this is part of the TinyBSD approach, this has been taking place through simply using TinyBSD as a base. One thing this project has given me is an enormous appreciation for how smoothly the FreeBSD kernel can be reconfigured, and how fast it can be compiled relative to other FLOSS kernels.
Anyway, I expect that getting down to <16MB will be simplified by the work I have thus far done.
3. Next two weeks: Though I originally foresaw a makefile, I'm starting to see a makefile and a shell script coexisting peacefully amongst the mountain breezes and tall, tall grasses.
4. Unallocated time: clearly, this is already being filled...
---end legacy material---
I have reached the point where I have an 11 megabyte image. The TinyBSD folks deserve a lot of credit, they've put together an awesome tool.
I'm working some separate things right now.
The first is my actual hardware: it's being dicky. I mean, frustratingly so. I three quarters suspect that I'm just being a fool, but it's hard to see how.So, to solve that in the interim, I'm getting qemu up and running. This is nice because I'll be able to emulate the correct hardware and everything should work relatively smoothly for testings. Unfortunately, my qemu-fu is extremely limited. I'm also finishing up the pxeboot server I talked about on my blog in the distant past, to work around the hardware issue -- the CF reader doesn't seem to recognise media.
Second, cross compiling. I've been having a blast with cross-compiling; it's fun to know you're building something that won't work on _this_ hardware, but will on _that_ hardware over there in the corner behind the milk bottles.
Third, really, I'm working with crunchgen. I'm missing something simple, I'm sure. But once I've got that solved, I'm hoping to kind of emulate the TinyBSD process, returning to the PicoBSD idea of a crunch.conf. That might be a toughie, ultimately, because of time constraints, but I'm hopeful. And it'll help shave the rest of the size down, too, which would be nice.
What this means is that milestones 1&2 are in fact resolved, and milestone 3 is existent in the form of a tinybsd configuration file. Go figure. The hard work is kind of done, but my mentor and I always foresaw this as being a project to boot a non-x86 processor, too.
Contact email@example.com with suggestions to make this more awesome.