Messaging

[mr. xsism]

this is a seldom discussed topic it seems. What is the point of messaging? If we can define that then we can find the best method.

What therefore is the best method?

[mr. xsism]

i know you can use shared memory, registers, and even stack. Are those the only ways? Which is more important speed & efficiency or security?

Is shared memory insecure? is it slower?


messaging is basically just used to pass function params to other threads right? Not entire buffers. or no?

[Tim]

i know you can use shared memory, registers, and even stack. Are those the only ways?

Everything comes down to one of these methods in the end. It just depends on how you wrap it.

Which is more important speed & efficiency or security?

You should answer that yourself -- it's up to you.

Is shared memory insecure?

Depends how secure you make it. Remember the kernel is in charge of everything, especially memory mapping.

is it slower?

Than what? Shared memory is memory.

messaging is basically just used to pass function params to other threads right? Not entire buffers. or no?

You can pass what you like. TCP/IP is a form of messaging, which can range from communication between threads in a process, to communication between computers across the world. Alternatively, you can communicate between two threads using a single integer, i.e. a semaphore.

[dthn]

Translation -- we write in prose on this message board, not poetry. We also use uppercase and punctuation.
The problem you are looking for is multi processors. Handling context switches, interrupt blocking, interprocess etc. can be trivia on a single processor. When there are 8 of them on a single motherboard (shared memory) -- 128 on separate super computer blocks -- you start having second thoughts.

On Mach OS there is an early presentation of such a tactic.
Each process (or task of processes) declaring a mailbox for incoming a queue of some sort, so that message delivery is transparent for both sender and receiver.

On local isolated machines they say it suggets some kind of overhead which seems rather unacceptable. Writing in Java when you can write in assembly is such a loss.
[hr]
the problem you are looking for is multi processors
handling context switches, interrupt blocking, interprocess irc
can be trivia on a single processor
when there are 8 of them on a single motherboard (shared memory)
128 on separate super computer blocks
you start having second thoughts
on mach os there is an early presentation of such a tactic,
each process (or task of processes) declaring a mailbox for incoming
a queue of some sort
so that message delivery is transparent for both sender and receiver
on local isolated machines they say it suggets some kind of overhead
which seems rather unacceptable
writing in java when you can write in assembly
is such a loss ..

[bubach]

how do u "do" a system call service? i have read somewhere (intel maual) about some assembly commands like sysenter and sysexit, do use them?

/ Christoffer

[BI lazy]

Hmm ... sysenter 'n' sysexit ... I'm not sure whether they are a good idea to use.

I prefer providing a software interrupt with a kind of parameter passing method (some struct to fill in, whose adress is put into a register) and a function which according to the passed parameters invokes the correct service & hands it the parameters. well, I do it that way.

The call of a system service is: "int xx".

Tim may know way more efficient and cool methods to invoke system services and issue system calls.

--> It reminds me of something: I *should* write a text about how to implement a system call interface. At least present one possibility.[gollum] We shall see, my preciousss, oh indeed, we shall see ... *gnarf*where those bagginsess have hidden my system callsess[/gollum]

[Candy]

Hmm ... sysenter 'n' sysexit ... I'm not sure whether they are a good idea to use.

...

--> It reminds me of something: I *should* write a text about how to implement a system call interface. At least present one possibility.[gollum] We shall see, my preciousss, oh indeed, we shall see ... *gnarf*where those bagginsess have hidden my system callsess[/gollum]

*dons a necklace of System Call +1* Come along Smiegol.

I'd use Syscall and sysret, even though they're amd only. They preserve the stack (don't mess with me!) and are /fast/.

Syscall parameter passing? Use a struct or the stack in 32-bit mode, and registers in 64-bit mode. You've got more registers, so it seems a good idea.

[bubach]

but is sysenter and sysexit for both? i don?t want my os to be dependent of intel or amd. it should work on both..

/ Christoffer

[Candy]

but is sysenter and sysexit for both? i don?t want my os to be dependent of intel or amd. it should work on both..
/ Christoffer

sysenter/exit works on intel & amd 32-bits, and intel 64-bits
syscall/ret works on amd 32-bit and intel/amd 64-bit

Neither works everywhere (thank you intel for SCREWING IT UP AGAIN. No thanks.)

[BI lazy]

well, bubach, I canna tell for sure, what you *should* use for maximum compatibility.

But, at lowest level, where hardware tells your processor that work is to be done (data to be fetched from buffer, buffer empty, et cetera), a convenient interface exists already: int [n]. Thats it. the int n, iret instructions do basically what sysenter/sysexit: they provide an interface into the kernel and preserve the stack - by switching to the one indicated in esp0 of the system tss. You have 256 of them. Some are to be preserved for exceptions/traps/faults and 16 are needed for the hardware interupts. The rest is for you to use. Just define the interrupt gate and there you go. (basically)

Look at www.distantvoices.org and check out for my multitasking text. you can find an iSR stub there - which is the bare bone of multitasking.

Stay safe.

[Candy]

a convenient interface exists already: int [n]. Thats it. the int n, iret instructions do basically what sysenter/sysexit: they provide an interface into the kernel and preserve the stack

The /POINT/ of sysenter/sysexit and syscall/sysret is that just about all OSes have one (1) entry point, no need for int0-255, and do not use protection and don't give a d*mn about CPL, RPL, DPL and things like that. They just want a small fast routine to go to the kernel.

Int/iret take at least 10 cycles each. They probably cost more. Let's assume an average of 40 cycles. That takes 80 cycles for each syscall, or with 10000 syscalls/sec (not unrealistic at all) that's 800.000 cycles. That equates to, for a 1ghz processor, an unnecessary overhead of 700000 cycles or 0.07 %. Getting 0.07% better performance while making your life easier sounds like a d*mn good exchange.

I personally like syscall/ret better because you don't need a kernel stack /AND/ a user stack for each process, which keeps down memory allocation. F*ck intel, give me syscall/ret.

(with a compatibility module... ugh...)

[BI lazy]

That's ok, gosh.

But tell me, can the PIC issue a sysenter/syscall?

As far as I know, it just puts High on some Pin of the CPU for that it knows: Oooops, there is hardware in need of attention. That's the 'same' effect as if you issue *int nn* by software. (I 'm doing the micro kernel thing, so nearby every system call leads to a task switch)

I have only two entry points into the kernel: the message passing trap and the 'other_syscalls_trap', which I use for things like semaphores & signals. For a message send/receive, you just say "int 50", for a semaphore-up you just say "int 51". Of course you have to provide the parameters - but everything else runs automagically - from state saving to task restarting.

The kernel stack you mention: for a Userprocess, it is not much more than the size of the context saved by the ISR-Stub. After Saving, I f. m. part switch to a dedicated kernel stack.

I 've done some stfw on SYSENTER/SYSEXIT but it's not very elucidating. rather vague documentation. Do you have som elinks at hands to lift the veil?

[Candy]

But tell me, can the PIC issue a sysenter/syscall?

would an interrupt controller issue system calls or interrupts?

Would a user program issue system calls or interrupts?

What sounds logical?

As far as I know, it just puts High on some Pin of the CPU for that it knows: Oooops, there is hardware in need of attention. That's the 'same' effect as if you issue *int nn* by software. (I 'm doing the micro kernel thing, so nearby every system call leads to a task switch)

I have only two entry points into the kernel: the message passing trap and the 'other_syscalls_trap', which I use for things like semaphores & signals. For a message send/receive, you just say "int 50", for a semaphore-up you just say "int 51". Of course you have to provide the parameters - but everything else runs automagically - from state saving to task restarting.

Which you could do with a single 2-cycle test as well (test edi, 1; je least_called_int), saving you something like 68 cycles a call. Aside from that, use a function table so you could do mov eax, [edi*4+base_of_table]; call *eax instead, giving linear calling speed to a near-infinite number of system calls (and there go the guts of my trampoline module).

The kernel stack you mention: for a Userprocess, it is not much more than the size of the context saved by the ISR-Stub. After Saving, I f. m. part switch to a dedicated kernel stack.

Saving registers makes sense for ISR's. It does certainly not for system calls. You expect something to be done at that moment, you might as well wreck the registers.

I 've done some stfw on SYSENTER/SYSEXIT but it's not very elucidating. rather vague documentation. Do you have som elinks at hands to lift the veil?

AMD #24593 page 181, chapter 6.1 lists them, their msr's and how to use them. There's not that much to them actually

syscall/ret
They take 4 cycles each, put cs_base in cs, cs_base + 8 in ss, the target pointer in eip, the old eip in ecx and continue executing. No other checks, just the jump. The return is by putting the return-csbase in cs, return-csbase+8 in ss and jumping back to whatever is in ecx.
Doing a 64-bit prefixed sysret takes cs = csbase+16, ss=csbase+8 instead of just csbase. Syscall is identical. They both save / restore rflags to/from r11.

Sysenter/exit work more or less the same, but they do switch stacks. You have a target cs, target eip and target esp. Don't know about that one actually, but it should work identically. Stack & eip stored in ecx/edx. Check intel manual for this one, AMD's is incomplete & confusing (why would they? they like syscall).

Try also the instruction set reference at 24594 PDF page references 377 and on.

[BI lazy]

re: what sounds logical: If you've read farther, you'd 've found the response for your question. *gg*

Well, have I told already, that I do the micro kernel way? Imagine a micro kernel trashing the user process registers wi'out saving them just for fetching a message and passing it to the responsible service process (fs, mm, gui). It won't do any good to trash user process stack or registers in a microkernel, where you have many more context switches than in a monolithic kernel.

In microkernel context, issueing a system call means: hey, service fs, gimme file "xy", and receive the response (usually, one gets a nice file handle). It works, and it works well.

If you have a task switch upon syscall, why bother putting the mechanism somewhere extra if there is the convenient way to wrap it around the ISR stubs? Do I miss something crucial there in the concept of micro kernels?

Or put it more bluntly: can you issue a potentially blocking semop(sem_id,DOWN,-1) without doing the register save thing?

ad function table: this one sounds good. Would save me a huuuge switch block. But ... how the hell to decide where the parameters go? do some wrappers which fetch the parameter struct? or do it the stack way? aaach, I should drink some coffee, being tired like hell...

[bubach]

sysenter/exit works on intel & amd 32-bits, and intel 64-bits
syscall/ret works on amd 32-bit and intel/amd 64-bit

it does?nt seem that hard.. u just use sysenter/exit if your os is 32 bit and syscall/ret on 64 bit..
Should i start another topic to discuss 64 bit? I would like to hear what u guys know about programming it.

/ Christoffer