tuesday, 16 january 2007

posted at 07:44
tags:

Made some excellent progress yesterday. Turns out that only code built into the kernel can access the host OS, so I have to make use of a HIDD of some kind. But then I found the UnixIO HIDD. Essentially it exposes Unix file access to AROS applications. Since all I do is file operations on /dev/net/tun, it will work nicely.

Late last night I got tap.device as far as detecting that packets were being sent. I thought I'd add a simple packet dumper before bed, because its only an extra couple of lines of code - read then print. And then something truly horrible happened. Turns out the the UnixIO API doesn't have a method for reading data from a file. It has one for writing, but not for reading.

This is truly bizarre. I can only guess that it hasn't been required thus far. I went to bed rather annoyed, and this morning poked around for an alternative - I wondered if maybe the data was being sent along with the "ready to read" event. Sadly, no dice. So on the bus trip this morning I implemented a ReadFile method, which is working very nicely. Once again, I'm impressed at how intuitive the code is - in under an hour I'd learnt what I needed and got it working.

I'll write some tests for it today (mostly just extending test/unixio) and check it in tonight. I'm not sure what the etiquette is for changing something rather core to the whole system. I haven't broken anything, so I think I'll just check it in, tell #aros, and then deal with any fallout (though that seems unlikely). They gave me commit bits, I intend to use them :P