Hey, Mark (or anyone else who might know) -- I've been working on getting my VNC server into the kernel, and I'm noticing something very weird. In the userland app, I was reading a big chunk of data off the wire directly into a struct that was aligned properly. Now that I'm porting that to a kernel service, it seems that the data is not coming in the same order. Does that make any sense to anyone, or have I totally screwed something up somewhere that I can't find?

Something must be buggered.. what you report doesn't register with me at all.. Do note, that the arm-gcc seems to screw up royally when declaring variables in "misaligned" sequence, especially for "local" static variables, as in:

int f(void)
{
static char localbuf[21]; // odd-sized static
static long last_jiffies = 0; // this gets misaligned
...
}

The above code will run, but data will not end up in the right places due to the misalignment of "last_jiffies".

I've been bitten by this several times..

Cheers


-ml

Nope. I've definitely got it aligned properly. Even got padding variables in the structure. I'll have to map it out and see where I've gone wrong. Thanks.

I think I figured it out, and as you (and I, really) suspected, it did have to do with alignment, but in a way I've never experienced. I was reading one byte off the wire when many more were pending. I then tried to read a big chunk (something like 20 bytes). For some reason, it skipped a byte between reading the single byte and reading the chunk, as if reads from the network can only occur in 16-bit hunks. If that's the case, I wasn't aware of it, and have never encountered it before. Anyway, the data I was expecting was offset by 8 bits, but because of some htons()-type stuff, it was a little opaque to me at first. Anyway, I think I've got that solved. Now onto further bugs....

Now it's skipping past other data for reasons I can't figure. This time it's skipping past a whole 16 bits. Is there some sort of long-word alignment, too?

Edit: Nope. I've verified that it can read odd numbers of 16-bit blocks (at least in other cases occurring milliseconds before). I've even tried changing it so that it's no longer MSG_PEEKing at the first byte, but reading two bytes and holding the second in a buffer for later use. Still didn't fix it. And I'm watching the data fly across the wire with a packet snooper, so it's not like I'm expecting data that's not really being sent. This is being a royal pain.

Edit edit: actually, looking at it some more, I can read in odd bytes in other places as well. This makes no sense.

????

For network I/O, most apps can just use sockets. And for an example of socket-level I/O (TCP), have a glance at kftp.c::ksock_rw() from the Hijack patches.

Simple, robust, and no weird stuff..

????

Well, that's the weird thing, because I'm using your ksock_rw() and absolutely no other socket calls (besides the ones to open the connection, which I stole from your kftpd.c). I even modified it to printk() about all the bytes it sends and receives and it isn't showing it reading anything else -- it just skips over those bytes.

I don't suppose you'd want to take a look at it, would you?

Send it on over, and I'll have a peek. If I like it, I might even integrate it..