Merry year, etc. I didn’t write a great deal of code over the break, opting to trounce Dark Samus instead. But now I’m back at work, which means a few spare laptop hours each day, mostly while on the bus. I’ve already forgotten everything I was working on, so of course, its time for something new.
In days of old, I was an Amiga fanboy. I would’ve liked to be more, but I had nfi what I was doing, and couldn’t afford the necessary s3kre7 t3ch to do the really awesome stuff. I did spend many long hours in AMOS Pro, but I think the real heroes would tell you that doesn’t count.
Amiga is mostly dead and gone now, but I still have fond memories. At various times in the last few years I’ve stumbled onto AROS. A few clowns thought it’d be great to reimplement AmigaOS from scratch, and who am I to argue? I remember when I first saw it it was complete pants, but I tried it again in 2005 and found it to be quite impressive. I started playing with the code then, even porting JJFFE (sadly, that code is lost). As usual, I got sidetracked later (I think on some interesting MUD code), and forgot about it.
Anyway, I rediscovered it again a couple of days ago and grabbed the code. It didn’t compile, which turned out to be the build system wrongly assuming that a particular header file was always in the same place. On Debian, its not. But in the course of finding and fixing the problem, I got to look at the code again, and was reminded of just how interesting the system is. So AROS has been selected as my next plaything.
I’ve joined the lists and posted my build patch, and last night dropped into #aros. Talking about possible projects, someone suggested a decent telnet/SSH client would be useful, immediately making me think to port PuTTY. First of course, I need network.
As far as I can tell, AROS has working network/TCP support, but only if running in native mode (ie running direct on the hardware). I’m not particularly interested in that mode of operation, preferring the Linux hosted mode - saves dicking around with partitions and rebooting and whatever. Unfortunately there doesn’t seem to be a network driver for hosted mode, so I decided my first project was to make one.
I know from past fiddling that the TUN/TAP drivers are the way to realise this. Basically it creates an network interface that is attached to a process rather than a physical bit of hardware. With the right setup it sends and receives raw ethernet packets. So my thought was to learn it, then work out how to integrate into AROS.
I wrote taptest.c to get a feel for how things should work. Armed with that, I set about building a AROS hardware driver.
Since AROS is trying to be portable, its device drivers don’t talk directly to hardware. Instead, there exists Hardware-Independent Device Drivers (HIDDs), that essentially abstract the underlying physical hardware. Then, the device drivers (eg
graphics.device) talk to the HIDD to do the work. It makes sense, but the importance was completely lost on me as I charged ahead, copying one of the network card drivers and gutting it to do my bidding.
After a little while I started thinking about how to make a AROS binary use facilities provided by the host when it hasn’t the faintest clue that there exists something called a “host system”. Then it dawned on me that I’d need a HIDD that talks to the Linux TUN/TAP driver, and then a network driver that talks to it and implements the SANA-II interface.
So now I had two things to write. Digging around, turns out there’s already a
tap.hidd, but a corresponding
tap.device is nowhere to be seen. I can’t imagine what the HIDD could possible be for on its own, and nothing in the source tree seems to reference it, but I’m not above stealing it and using it.
So there, I’ve said basically nothing, but at least you now know. The one thing I am finding is that this project is fun to hack on, something I’ve really been missing in the last little while. And there’s heaps to be done still, so I shouldn’t be lost for ideas. Hopefully I can hang around here a little longer than most other things.