• Welcome to Valhalla Legends Archive.
 

Networking with assembler?

Started by BlackLotus, August 10, 2004, 09:26 PM

Previous topic - Next topic

iago

Quote from: MyndFyre on August 12, 2004, 08:26 PM
Quote from: $t0rm on August 12, 2004, 05:50 PM
<newbie>
What's a context switch?
</newbie>

Given the context of the discussion, I believe the context of the running code must switch from user mode to kernel mode.  ;)  Granted, I'm not sure.

Yes, that's correct.  User mode is what most stuff runs in, and it's very restricted.  Kernel mode is also called "supervisor mode" and has access to everything.
This'll make an interesting test for broken AV:
QuoteX5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*


Skywing

#16
The relevant part here would be that you would not need to do things like switch the process context (e.g. reload the page tables and flush tlbs, and so on) to handle a TCP/IP message in kernel mode.

You might see something like this:
Network card -> driver ISR -> DPC -> [intermediate NDIS layers] -> tcpip.sys

If you were doing this in user mode, it would look more like:
Network card -> driver ISR -> DPC -> [intermediate NDIS layers] -> tcpip.sys (yes, for raw sockets) -> afd.sys -> queue a completion notification to waiting user thread -> (thread dispatcher, sometime in the future selects user thread to run, which can now handle incoming data on the raw socket).

Of course, then you also have to route TCP message to whoever was actually associated with that socket, which is probably going to be in a *different* process, so you have to wait for the dispatcher to then run the sleeping application thread before the TCP-utilizing application can receive it's data.

If you were handling TCP in kernel mode, you might be able to go to the right user mode process directly instead of adding a secondary process and thread that has to be woken to handle the TCP protocol itself.