I am sorry for top posting, but I could not figure out a proper place to inline my comments. I explored this topic myself some time back and wrote an article to explain this. In fact, I had announced the article on kernlenewbies: http://thread.gmane.org/gmane.linux.kernel.kernelnewbies/17323/focus=17469 Here is the direct link to the article: http://articles.manugarg.com/systemcallinlinux2_6.html I think the article is quite explanatory. But feel free to point out if something is not clear. Cheers, Manu On Sat, Aug 14, 2010 at 10:44 PM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote: > Hi > > You forgot to cc: to the list previously, I am afraid :) > > On Sat, Aug 14, 2010 at 18:16, javad karabi <snkcld1@xxxxxxxxx> wrote: >> But, I dont really have my own computer at home, so I have to get a VPS >> online. > > as long as you don't hack somebody else system and get into their > shell access just for your kernel adventure, I think it's ok :D > >> But I can boot in to my own kernel, so, its fine... >> I am not trying to code for AMD specific arch, however, I am trying to learn >> coding for amd64 / x86-64. >> Essentially, I dont want to learn the 32bit architecture if the 64 bit is >> the way of the future. > > I'm ok with that, but certainly it would be easier if we know about 32 > bit arch first, right? Since actually large part of 64 bit arch (both > IA 64 and AMD64) are based on 32 bit..... > >> Essentially, whats the point of learning int 0x80 for system call, whenever >> the future is syscall? >> Am I right? > > Without claiming that I am an expert about it, I think both int x80h > and syscall are about the same, trigerring exception and doing switch > from user mode and kernel mode....the difference is in the detail... > >> Of course, learning architecture neutral components is always good to know, >> so I will definitely look into the >> "jump to vsyscall page". Could you elaborate on that? > > Perhaps this page could explain to you better http://lwn.net/Articles/30258/ > > But in essence, it's a VDSO (Virtual Dynamic Shared Object--a soooo > techie term...a "virtual library file" would be easier to understand I > guess. > > So you jump to it, which is usually mapped at such high virtual > address, put certain values in registers first..and this page will > decide, whether it will be translated as int 80h, or syscall/sysenter. > > I hope my memory still serve me well :D > >> Regarding Xen, I think it is interfering with my kernel hacking. >> I booted into a kernel which had my system call sys_snkcld in the >> system_call_table_32.S file (I believe thats the name...), >> then, created my function, which is essentially the following: >> DEFINE_SYSCALL0(snkcld) >> { >> return 4; >> } > > This syscall is already assigned syscall number, right? > >> However, I use inline asm in user space to do the following: >> mov 338, %rax >> sysenter >> Then, I use gdb to find the value of rax after sysenter. >> In all cases, the value of rax was always -1, which I believe is >> "permission denied". > > Is your Xen VPS operates in paravirtualized mode? or full virtualization mode? > > There is a chance it's the first...thus the guest kernel is actually > doing a .....uhm, crap I forgot the name....hypercall. It's actually a > jmp/call to the hypervisor to do the "syscall". > > So, maybe...just maybe....your "syscall" is intercepted by the > hypervisor..but it replied "s**t, it's not in my defined hypercall > table...get back!" > >> Also, regarding syscall being faster because of doing other things in >> advance... >> How does the opcode know the location in memory of the kernel stack for the >> task? > > Not sure, so I think you need to research it by your own. But i > believe it's not predetermined.. > >> Also, and this is one of my biggest questions... The system call number is >> placed in rax, but, how does syscall know >> the location of the system call table? The call number would have to be >> multiplied by... I believe 8... Then added to >> the base address of the system call table to determine the address of the >> system call handler. >> From what I understand, the dispatcher would look into the eax register, >> then multiply that in x86. >> But, if its an opcode which is doing this... how does the opcode know the >> address of the system call table? > > It's the job of the interrupt number 80 handler...or sysenter/sysycall > handler....you do remember about how interrupt is handled in Intel > arch, right? > >> Thank you for your help. It means alot. > > No problem..I am sorry if I cause more noise than help :D > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx > Please read the FAQ at http://kernelnewbies.org/FAQ > > -- Manu Garg http://www.manugarg.com "Journey is the destination of life." -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
