Files in asm/ have got modified quite a lot. These files were edited today and yesterday: * checksum.h * current.h * semaphore.h * uaccess.h * system.h
Each change is generally very small and always has a comment with EDIT in it to mark it.
The title says it all really. There are still problems, but things are looking good. I now have a sustained bulk transfer with Linux as the sender and OpenBSD as the receiver.
View the graph showing this here.
Even though there is a transfer for 35 seconds (the NAM trace shows this) for some reason the pcap cuts off after 1 second.
Hmm. I just had a thought. I think pcap node files are named node-[stack_id].pcap and both Linux and OpenBSD start at stack ids of 0. Maybe I should check this before I go home…
Update: Yep, that was the problem. Fixed now. Says ‘node-linux24-0.pcap’, for example, now.
After playing around of create_proc_entry I made it so it was possible to look into some of the information that is normally stored in /proc. This includes some routing information.
From this I figured out that there is not a single route in the routing table. I’m not sure why. I had assumed giving the interface an IP address made this route. I wonder if the interface isn’t marked up or something? I should check this out. Looking at the ifconfig source last night didn’t help me any, it looked to be doing the same that I do.
Update: This was because I had not implemented notifier chains. So the current functions were not called as part of a notifier chain. This meant the route was never created.
IP address and netmask is set on the interface without an error returned.
When trying to do a tcp_connect, it can’t find a route. The IP I’m trying to connect to should be on the local network; the interface should have brought up a route for this network.
Either it hasn’t, or something else is wrong. I’ve always had problems around this time in developing the NSC for various stacks. To my knowledge the problems end up being reasonably different every time. So I’m not sure what the problem is this time.
I hate trudging through the routing code and trying to guess what is wrong.
I can now create an interface and attach it without error. It doesn’t have any callback functions yet.
Next it will need an ip address.
As far as I can tell initialisation is working OK now. That wasn’t too bad; got it done in one day. Maybe I’m forgetting something, but important stuff like tcp_init() and so on get called, so I’ll just assume it is working.
This is probably a good place to stop for the week. Got further than I was expecting this week.
Getting the initcall stuff working required making my own linker script. Getting the default linker script was easy:
ld --verbose
Then I looked at the kernel linker script and got the relevant sections and added it to the output from the above command. I then screwed around for a couple of hours before I realised that changing SIZEOF_HEADERS to 2048 fixed things. For some reason SIZEOF_HEADERS was not big enough.
Anyway, now initialisation gets a lot further:
<6>Linux NET4.0 for Linux 2.4 <6>Based upon Swansea University Computer Society NET3.039 0] Unimplemented kmem_cache_create called. 0] Unimplemented kmem_cache_create called. 0] Unimplemented register_filesystem called. 0] Unimplemented kern_mount called. Initializing RT netlink socket 0] Unimplemented new_inode called. 0] Unimplemented kmem_cache_alloc called. 0] Unimplemented kmalloc called. 0] Unimplemented __wake_up called. 0] Unimplemented notifier_chain_register called. 0] Unimplemented notifier_chain_register called. 0] Unimplemented create_proc_entry called. <6>NET4: Linux TCP/IP 1.0 for NET4.0 <6>IP Protocols: ICMP, UDP, TCP, IGMP 0] Unimplemented kmem_cache_create called. 0] Unimplemented tasklet_init called. assert: add_timer not implemented.
It looks like further initialisation is going to rely on having a linker script. I liked how FreeBSD didn’t require one of these, even though it took me many hours to figure out how FreeBSD worked 
Now to look up how I can include one in my build, and what bits of the kernel script I actually want. I presume I don’t want the entire thing…
Current progress:
stj2@voodoo ~/900/simulations/work$ ns ../sim-15-bsd/sim.tcl 0] printk: <6>Linux NET4.0 for Linux 2.4 0] printk: <6>Based upon Swansea University Computer Society NET3.039 0] Unimplemented kmem_cache_create called. 0] Unimplemented kmem_cache_create called. 0] Unimplemented register_filesystem called. 0] Unimplemented kern_mount called. 0] printk: Initializing RT netlink socket Segmentation fault (core dumped)
Looks to me like implementing kmemcachecreate is going to be necessary.
Also, the segmentation fault is because the pointer kern_mount returns is NULL and is trying to be dereferenced. No biggie.
1:20pm: Now calls sock_init() and it runs without crashing.
It now compiles with -fPIC, but I had to modify a couple of header files in include/asm. I was always expecting to do this, I figure locking and the like were always likely to break things. Modified #defines include: * local_bh_enable * BUG * spinlock stuff * smpprocessorid (smp.h)
I think that is all currently. They were all modified to have empty bodies.
I’ve got the Linux network stack linking into an executable now. Compiling and linking is always the easy, somewhat menial bit. Now thinks get more complex.
I have some somewhat collated data of TCP performance comparing 3 TCP stacks: FreeBSD, OpenBSD and lwIP.
Environment: * 2Mb/s link, 100ms latency * 2Mb/s presented load * Random loss in both directions
0% Random loss
Measured load (Mb/s) (Sender, Receiver)
1.140002 ('FreeBSD5', 'FreeBSD5')
0.619301 ('FreeBSD5', 'OpenBSD3')
0.604440 ('FreeBSD5', 'lwip')
0.540672 ('lwip', 'OpenBSD3')
0.505719 ('lwip', 'FreeBSD5')
0.468173 ('OpenBSD3', 'lwip')
0.466006 ('OpenBSD3', 'FreeBSD5')
0.434343 ('OpenBSD3', 'OpenBSD3')
0.289314 ('lwip', 'lwip')
1% Random loss
Measured load (Mb/s) (Sender, Receiver)
0.463597 ('FreeBSD5', 'FreeBSD5')
0.419477 ('FreeBSD5', 'OpenBSD3')
0.380382 ('lwip', 'OpenBSD3')
0.336282 ('lwip', 'FreeBSD5')
0.307774 ('OpenBSD3', 'FreeBSD5')
0.282137 ('OpenBSD3', 'OpenBSD3')
0.108235 ('FreeBSD5', 'lwip')
0.072057 ('OpenBSD3', 'lwip')
0.065946 ('lwip', 'lwip')
5% Random loss
Measured load (Mb/s) (Sender, Receiver)
0.203844 ('lwip', 'FreeBSD5')
0.198514 ('FreeBSD5', 'FreeBSD5')
0.191556 ('lwip', 'OpenBSD3')
0.153238 ('FreeBSD5', 'OpenBSD3')
0.122783 ('OpenBSD3', 'OpenBSD3')
0.112735 ('OpenBSD3', 'FreeBSD5')
0.061515 ('FreeBSD5', 'lwip')
0.048469 ('lwip', 'lwip')
0.047389 ('OpenBSD3', 'lwip')
10% Random loss
Measured load (Mb/s) (Sender, Receiver)
0.126157 ('lwip', 'FreeBSD5')
0.125884 ('lwip', 'OpenBSD3')
0.096863 ('FreeBSD5', 'FreeBSD5')
0.083348 ('FreeBSD5', 'OpenBSD3')
0.064492 ('OpenBSD3', 'FreeBSD5')
0.055419 ('OpenBSD3', 'OpenBSD3')
0.042827 ('FreeBSD5', 'lwip')
0.038739 ('OpenBSD3', 'lwip')
0.035362 ('lwip', 'lwip')
bin/run.py -s 100 -r 10 sim-6-bsd
OpenBSD: 0.046631 0.059601 0.036433 0.044405 0.035663 0.039193 0.051878 0.042804 0.062304 0.038605
Average: 0.055419 Mb/s
FreeBSD: 0.084344 0.088754 0.083155 0.079157 0.084507 0.086244 0.080895 0.078908 0.082190 0.082383
Average: 0.097249 Mb/s
Really need to validate this result
It looks to me that Markdown is technically superior to Textile.
The reasoning for this is that it is easier to put source code/preformatted text in it and for it to work. I wish I had made the change earlier.
Some of my old entries have slightly stuffed up formatting now. Oh well. For the most part, things are better. I still need to do some testing and figure out how Markdown stuff works though.
A paragraph.
Different types of emphasis. Multiple word emphasis? Is there a horizontal rule below?
There should be a horizontal rule above.
I think being able to escape symbols is a big feature Textile lacks. Still, my previous post seems to show some bugs in Markdown. Need to investigate this further.
Take the following code:
int __attribute__((section("sam"))) symbol_1;
int __attribute__((section("sam"))) johno_2;
extern int *__start_sam, *__stop_sam;
int main(int argc, char *argv[])
{
int *i = __start_sam;
return 0;
}Compile it:
gcc test.c -Wall -o sam
And run nm over it and sort it by address:
nm sam | sort -n ... 080494d4 A __start_sam 080494d4 D symbol_1 080494d8 D johno_2 080494dc A __stop_sam ...
Look, a __start_sam and a __stop_sam, even though we never instantiated such variables. Thank you GNU ld.
If we check the sections in our freebsd library:
objdump -h libfreebsd5.so
libfreebsd5.so: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .hash 00002f2c 000000f4 000000f4 000000f4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .dynsym 00007c20 00003020 00003020 00003020 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .dynstr 0000933a 0000ac40 0000ac40 0000ac40 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
...
9 .text 000fbfa0 0002eef0 0002eef0 0002eef0 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
...
15 .data 00014bbc 00146000 00146000 00146000 2**5
CONTENTS, ALLOC, LOAD, DATA
16 set_sysinit_set 00000018 0015abbc 0015abbc 0015abbc 2**2
CONTENTS, ALLOC, LOAD, DATA
17 set_sysuninit_set 00000004 0015abd4 0015abd4 0015abd4 2**2
CONTENTS, ALLOC, LOAD, DATA
18 set_sysctl_set 00000014 0015abd8 0015abd8 0015abd8 2**2
CONTENTS, ALLOC, LOAD, DATA
19 .dynamic 000000d8 0015abec 0015abec 0015abec 2**2
CONTENTS, ALLOC, LOAD, DATA
...
We notice the mod_metadata isn’t there.
I eventually tracked down the problem to the parser losing __attribute__ strings between identifiers in a declaration. This is fixed now. This problem would never have existed if I could have figured out how to put attribute and extension stuff in the grammar itself, rather than hacking them nastily into the parser. Oh well.
Linux (2.4.26) is looking hopeful.
Timers don’t look too bad, though the mechanisms are not as obvious as those in FreeBSD. kernel/timer.c handles timer functions. Gonna need to learn a bit about the terminology (can’t remember what jiffies are) and what function is fired where (which is the hardclock()-like function? softclock-like function? how often are they called?).
Initialisation also doesn’t look too bad. Some functions are marked _init, which can possibly put them in a specific section (kinda like FreeBSD). Also, sockinit() is called explicitly from the kernel main function, from what I can see. Exactly what function is called for initialisation seems to depend on whether the code was compiled as a module or statically. Still need to do some more research on this, but it all looks very doable.
I just need to fix FreeBSD now!
FreeBSD used to work; I even started testing OpenBSD against it. Now it doesn’t. The shared library wont load because of the following error:
/home/stj2/900/nsc/freebsd5/libfreebsd5.so: undefined symbol: __start_set_modmetadata_set
This is one of those “linker sets” like the sysinit set and so on. The only places the above symbol and the sysinit equivalent are referenced:
stj2@voodoo ~/900/nsc$ nm freebsd5/kern/kern_module.parsed.os | grep start_set
U __start_set_modmetadata_set
stj2@voodoo ~/900/nsc$ nm freebsd5/support/support.os | grep start_set
U __start_set_sysinit_set
They are not defined in any object files. There doesn’t seem to be a problem with the sysinit one:
stj2@voodoo ~/900/nsc$ nm libfreebsd5.so | grep start_set 0016c3b8 A __start_set_sysctl_set 0016c3a0 A __start_set_sysinit_set 0016c3cc A __start_set_sysuninit_set
But the mod_metadata start_set doesn’t exist. I don’t know how these start_set symbols are sorted out by the linker at all. At all. I just have no idea whatsoever.
This means I can’t test FreeBSD vs. OpenBSD at the moment.
Since the global parser is now able to modify static locals correctly and also print out globals and static locals it encounters that are not “globalised”, multiple instances of OpenBSD suddenly work. I should perhaps do some testing… But I really want to get on to some more Linux research.
An edited list of undefined symbols follows. There are only 105 or so symbols here, but the info on where they can be found is rather long. (more…)
The parser seems to work on static local variables now. The code is getting a bit ugly, there is too much legacy stuff in there. It isn’t all that easy to fix because it is getting reasonable complex. I just don’t have the time to clean it up, unfortunately. So far so good as far as it working goes: it is replacing a couple of static local variables fine now. It also prints out all static locals it encounters. This was for debugging, but is quite a bit help at the moment.
Still haven’t got around to doing anymore Linux research. Really need to get on to this.
Update: now making GLOBAL index of Linux. I’ll see where all the undefined references are coming from. OpenBSD is getting closer, but still needs debugging work in uni.
Powered by WordPress