For the last few months I've been scouring the internet looking for documentation on implementation of Berkeley Sockets in ASM under Linux.

There's plenty of documentation on ASM interfacing with Windows Sockets (thank you Iczelion, you rock) but everything dealing with sockets under Linux assumes I'm writing in C/C++.

Anyone? Bueller?
Posted on 2007-11-17 16:47:30 by Carl Hamlin
The defactor socket guide is probably beej's. It's not asm-specific, but you ought to be able to read C and translate it to Asm if you need - otherwise you're not going to get far with anything :)
Posted on 2007-11-17 17:25:45 by f0dder
Thanks. I've seen his explanation before - what I'm looking for specifically is an explanation of the mechanics of the socketcall() function. I can't imagine there isn't documentation at the ASM level somewhere, but I've been coming to the reluctant conclusion that I might just have to piece it together from the C include files on my system.
Posted on 2007-11-17 19:21:52 by Carl Hamlin

Thanks. I've seen his explanation before - what I'm looking for specifically is an explanation of the mechanics of the socketcall() function. I can't imagine there isn't documentation at the ASM level somewhere, but I've been coming to the reluctant conclusion that I might just have to piece it together from the C include files on my system.


Well, that may force you to draw incorrect conclusions. A better, yet more extensive, approach would be to download the latest Linux kernel source files and take a gander at how such system calls are implemented.
Posted on 2007-11-17 20:29:00 by SpooK
C level and ASM level of using sockets is pretty much the same - even if you choose the stupid way of directly doing syscalls, there isn't much difference, really.

If you're talking about how the stuff is implemented, kernel level, then it's a completely different matter - but it's still not done in assembly :)
Posted on 2007-11-17 21:48:46 by f0dder

Well, that may force you to draw incorrect conclusions. A better, yet more extensive, approach would be to download the latest Linux kernel source files and take a gander at how such system calls are implemented.


Yep. I've been trying to get an idea of what I'm doing by going through the source included in the latest distribution of Ubuntu (7.10) and seeing if I can find the definitions for the socket functions.

It's slow and frustrating work, but if it's what I gotta do, then it's what I gotta do.
Posted on 2007-11-18 00:20:09 by Carl Hamlin

C level and ASM level of using sockets is pretty much the same - even if you choose the stupid way of directly doing syscalls, there isn't much difference, really.


OK, I'm curious; why is that the 'stupid' way?
Posted on 2007-11-18 00:21:33 by Carl Hamlin

OK, I'm curious; why is that the 'stupid' way?

I guess because of portability through different distros or builds of a kernel.
Syscalls opposed to importing dynamically-linked sources.

Btw, last time I checked the kernel drivers' sources for two of the most common adapters, they were a mess :). Opposed to the clean professional style the rest of the 1.0 kernel had (iirc).
Posted on 2007-11-18 01:32:43 by Ultrano
http://forum.int6.net/index.php?topic=93.0
Posted on 2007-11-18 02:31:59 by Dite


C level and ASM level of using sockets is pretty much the same - even if you choose the stupid way of directly doing syscalls, there isn't much difference, really.

OK, I'm curious; why is that the 'stupid' way?

Ultrano already answered that, but let me add that you don't gain anything from using syscalls directly as opposed to the libc interface. You won't be able to measure any speed difference, and you run the risk of app breakage on new kernel version etc.
Posted on 2007-11-18 06:46:31 by f0dder

I guess because of portability through different distros or builds of a kernel.
Syscalls opposed to importing dynamically-linked sources.


Ah. Gotcha - makes a certain amount of sense. Fortunately, I'm coding this project as a learning experiment, and it'll never see the light of day.


Btw, last time I checked the kernel drivers' sources for two of the most common adapters, they were a mess :). Opposed to the clean professional style the rest of the 1.0 kernel had (iirc).


Yep. I've been looking at some of that code and it's making my eyes cross.
Posted on 2007-11-18 14:17:53 by Carl Hamlin

http://forum.int6.net/index.php?topic=93.0


Thank you. I may have already seen this, but I'll know for sure as soon as I pull a reader capable of handling its format. Bulletins as events warrant.
Posted on 2007-11-18 14:19:25 by Carl Hamlin

Ultrano already answered that, but let me add that you don't gain anything from using syscalls directly as opposed to the libc interface. You won't be able to measure any speed difference, and you run the risk of app breakage on new kernel version etc.


Makes sense. Mostly I'm just trying to get a hands-on feel for what's going on on the processor when sockets are in play. I'm not so much worried about speed over libc or possible breakage on new kernels if the syscall table changes. Thanks for clarifying.
Posted on 2007-11-18 14:21:46 by Carl Hamlin

http://forum.int6.net/index.php?topic=93.0


OK, I got it. Looks like I've got some reading to do. Thank you so much!
Posted on 2007-11-18 14:29:16 by Carl Hamlin


Ultrano already answered that, but let me add that you don't gain anything from using syscalls directly as opposed to the libc interface. You won't be able to measure any speed difference, and you run the risk of app breakage on new kernel version etc.


Makes sense. Mostly I'm just trying to get a hands-on feel for what's going on on the processor when sockets are in play. I'm not so much worried about speed over libc or possible breakage on new kernels if the syscall table changes. Thanks for clarifying.

Ah, so it's the behind-the-scenes stuff you're interested in...

Well, there's a lot of stuff going on, it's a multi-layered architecture. You have the socket abstraction, which can be used for multiple protocols (IP4, IP6, IPX, local/unix sockets, ...), you have the raw transport device driver (ethernet, ATM, FDDI, ...), various parts of the kernel (IRQ handling, memory handling, ...) and so on. It's a pretty big scheme of things :)
Posted on 2007-11-18 14:29:35 by f0dder