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?
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?
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 :)
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.
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.
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 :)
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 :)
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.
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?
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).
http://forum.int6.net/index.php?topic=93.0
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.
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.
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.
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.
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!
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 :)