| |
| |
| |
|
Page: 1 2 3 4 5 6 7
Comments:
<0> it seems un-necessary
<1> what seems unnecessary?
<0> yes, it is. but most of the registers are saved into stack before.
<1> and why
<1> yes, but it's not the same values
<0> you ask me a good question.
<1> the interrupt frame stored the status of the cpu at the time the interrupt happened
<1> the switch_to is saving registers at the time it wants to switch threads. the two operations are completely different
<0> but in the code, only push esi, edi, and ebp.
<0> I dont understand why treat them specially.
<1> eax, ecx, edx are all trashed by the call, so there's no point saving them
<0> geist: go ahead
<1> the compiler doesn't expect those registers to survive a function call, so it doesn't matter
<1> but back up a second. you're asking multiple questions here
<1> we need to establish that you understand the answer to the first querstion
<1> which is why does it bother saving any registers at all in switch_to, when there is already an interrupt frame on the stack
<1> do you understand that switch_to and taking an interrupt are two completely different things?
<0> yes
<1> okay good. now, in switch to it's basically saving the state of the kernel thread on the stack
<0> I understand, they are different. though there is context switching in interrupts
<1> yep. switching contexts are completely independent of what state the cpu is in
<1> all that is required is the cpu is in kernel mode and has a stack to save state to
<0> :-)
<1> it might be inside an int handler, might be inside a syscall, might be inside a kernel thread
<0> can I understand in this way ?
<1> can you rephrase the question?
<0> we need backup state of stack, CR3, DS,CS, and other general registers.
<1> nope
<1> you dont
<0> for eax, ebx, ecx, edx are corrupted by compiler, we only need to save esi, edi, ebp ?
<0> and esp ?
<1> right
<0> cool
<0> geist: cool
<1> you need to save esp somewhere, but you can't push it on the stack, that doesn't make any sense
<2> anyone here written a driver for a pci-ide controller?
<1> generally you push that stuff on the stack and save the stack pointer in a per-thread structure
<1> optionally yo ucan save the register state directly to the thread structure
<0> geist: I see.
<1> now, stuff like cs/ds/es/fs/gs might not need to be saved depending on the design of the system
<0> geist: also I can push the esp into stack, and acess it by a pre-defined fixed offset.
<0> geist: might not ? why?
<1> for lots of kernels, when you're in kernel mode you're always using the same segment registers, so there's no point saving them because the next thread will always have the same values
<0> geist: cool !!!
<0> yes
<1> same with eflags
<0> when they returen to user space, the CS can modified by the stack frame.
<1> most of the bits of eflags the compiler ***umed is trashed by a function call, and the only really interesting bit is the interrupt disable bit, but since you're deep in the context switch code, it's implicitly got interrupts disabled
<1> so it doesn't need to save eflags either
<0> but how about DS ? should libc modify the DS and other data segnent stuffs ?
<1> I'm not sure if you've ever used setjmp/longjmp. lots of kernel context switch routines are basically the same thing
<1> we're inside the kernel, remember
<0> geist: you are write
<0> s/write/right
<1> these are kernel segment registers, they dont change
<0> I mean back to user space
<1> and when user code makes a syscall or an interrupt happens from user code, the kernel segment registers are reloaded
<1> the user state of the segment registers are saved on the stack when a syscall or interrupt happens
<1> jrydberg: lot of folks have, I just haven't personally done it myself. never seemed like any fun, so I didn't bother
<0> geist: but only SS, ESP, CS, EIP, EFLAGS on stack, no user space DS in it
<1> I dont know what linux does
<0> geist: so, how do you make it ?
<1> I'm ***uming they do more or less what all the other x86 oses do, but they might do some things slightly differently
<1> how do I make it? what does that mean?
<0> I think you also write your own os
<1> yes, I did
<0> I ask this question just because I try to make one. but really it's difficult for me :-)
<0> so, in your kernel, when application back from kernel space, how can you modify the data segment selector ?
<1> it's just restored from the stack
<0> or, CPU makes it automatically ? or modify the DS to user space manually before return to user space ?
<1> on a syscall or interrupt, the full state of user space is saved
<1> including cs/ds/es/fs/gs
<1> and when it returns it restores it
<1> so user space is allowed to mess with their segment registers as much as they want, though most values are useless
<0> I understand !
<0> geist: I understand, when interrupt comes, the old segment selectors stored in stack (auto or manually), when return to user space, just restore them
<1> right
<0> geist: thank you !
<1> cool, glad I could help
<0> geist: where can I find the documents, for what you told me.
<0> geist: I mean the esi, edi, ebp stuffs.
<0> geist: i remember they are not in the Intel's manual
<1> i do not know. I learned this by figuring it out myself
<0> geist: cool !!really cool
<0> geist: I think if using "lcall TSS_sel", we need not save these registers. isn't it ?
<1> i do not know. I do not use TSS, nor do I recommend it
<0> :-)
<0> thank you geist:-)
<3> geist: you need atleast 1 TSS dont you?
<1> yes, but you're not using it as a task switcher, which is what I really mean when I say 'dont use tss'
<1> but i'd rather not bring it up right now and then have to describe it
<3> mm, i see
<0> bye, every one
<4> good thinking geist
<1> i dont like to lay too much stuff on them at once, it generally just confuses em
<4> did you ever compile newos on gcc 4.x?
<1> yeah, i had to fix a couple of bugs here and there
<4> but nuttin' big upgrading from 3.x?
<4> i'm at 3.4.3 and it's getting embarrasing
<1> not sure why. that's pretty up to date
<4> hm
<1> the biggest pain with upgrading to 4 is some old warnings are now errors
<1> and it's much more pissy about strict typing
<4> i see. fortunately i keep the code warning free (but then again - i'm not --pedantic)
<1> right, if you're -Wall and -W and warning free you're probably okay
<4> i am
<1> there will definitely be new warnings
<4> plus a few others
<4> right... migrating from C to C++ revailed a few actual typing bugs
<4> so it's almost always ok with stricter typing
<1> yeah. I've been using 4.0 for a while for my arm stuffs
<4> ah
<1> well, it's not strict typing it has a problem with (wrong term) it's strict aliasing
<1> and it's a real pain to make it happy, though you can turn it off with -fno-strict-aliases I think
<4> yes
<4> I'm in the need to check an object for self-contention and, if no self-contention, attempt to grab the spinlock. All of which has to be an atomic operation. Turns out to be hard, since protecting spin lock attempts with a spin lock is just dumb, and it is even dumber to use a sleep lock to protect a spin lock attempt.
<4> Every object has a lock(flag_t*) and unlock(flag_t*) pair of spinlock functions. Nice and all. However, to simplify and make the code more robust, I've introduced a AutoLock cl*** that is mean to be an auto object. So the idiom is C::f() { AutoLock l(this); ... other code w/lots of exit points ... } Nice. Alas it doesn't work when f() calls C::g() which also does the AutoLock - it will obviously deadlock. Now, the idea is that the second
<4> AutoLock attempt should be granted, because AutoLocks only protects against external races.
<4> ...and that's probably to long for anybody to care to read...
<5> a recursive mutex ?
<4> almost
<4> but no sleeping allowed
<4> this is a spin lock
<4> recursive sleeplocks are easy, since you can protect the ownership _and_ the lock attempt with a spin lock
<4> ownership check, that is
<5> darn - i feel very awfull atm - its like i need to throw up, but it just wont start
<4> use the finger, mate
<4> if that doesn't help, try the vacuum cleaner
<4> the last resort is listening to country music
<3> if that doesn't help, go to the doctor cause you got a vacuum cleanerr stuck in your throat
<4> yes, there's a slight risk of that happening
<5> lol
<5> finger is no help
<3> r0nny_: been drinking? :P
<6> anyone know a GOOD reference on the GAS syntax? simple things, like, how I call a function whose address is in a register?
<3> tried call (%eax) ?
<5> ate too many salt peanuts
<3> r0nny_: oh..
<5> they where tasty
<4> so neutralize
<5> how ?
<3> water?
<4> sodium
<4> :-)
<3> lol
<5> no more salt - i ate salty peanuts, till my lips where hurting from the salt
<3> r0nny_: drink water!
<3> loads
<3> atleast 10 liters!!
<5> on it
Return to
#osdev
or
Go to some related
logs:
python+context.get()
#linuxhelp
dapper Release: Unknown error executing gpgv
fedora netmd mount
#linux
phpbb exploits
additional emblems gnome
#web
ps/2 mouse udev mice etch
#perl
|
|