Neo wrote: >> That overwrites (and loses) the pointer assigned to "old_call_c" from >> the sysent[] array. Are you sure you don't want to define an >> "old_call_32_c" variable? > > The "old_call_c" doesn't get overwritten. There are no issues with the given > type of implementation.
Writing two things into the same variable sounds like an overwrite, but, hey, what do I know? > My main problem is, > I have mapped "SYS_mkdir" system call to my customized "new_mkdir" method. > My machine as well as OS are 64bit. So, > 1) If I run a 64 bit application which calls mkdir syscall, it will > successfully get trapped to my new_mkdir method as my machine+OS is 64 bit. > 2) But if I run an 32bit application which does mkdir, it doesn't get trapped > in my new_mkdir method. > > So, tracing 32bit sys calls on 64 bit platform is the basic issue. If tracing really is the basic issue, then stop here: Open Solaris comes with several flexible and usable tracing tools -- dtrace, truss, and kmdb (mdb -K). Use them. They're your friends. Hacking at the syscall table is not your friend. (And, really, is best done from within the kernel sources.) If overriding the mkdir behavior of a known set of applications is your goal, then consider using an LD_PRELOAD to interpose on the higher-level library call. It'll be far less problematic. Otherwise, it doesn't sound like you've adequately described what your "basic issue" really is. >> You might also want to look more closely at the way 'struct sysent' is >> constructed in usr/src/uts/common/os/sysent.c > > I saw the struct sysent and struct sysent32 from sysent.c file. > According to that, I guess the implementation of both the structs are proper > in the code snippet at beginning of this thread. > > When I see code in systrace.c, I can see the implementation of macro "#ifdef > _SYSCALL32_IMPL". > I think that somewhere this macro will help me doing so. > > Can you please provide some more pointer on the same front? The only difference I can see between them (using dtrace to examine the kernel's behavior) is that one goes through unix`syscall_trap and the other through unix`syscall_trap32 on SPARC, and on x86/x64 one goes through unix`sys_syscall and the other through unix`_sys_sysenter_post_swapgs. If that's not what you see, and if you're not willing to take the advice to stay away from hacking the syscall table from within an independent kernel module, then I guess you're on your own. Good luck ... -- James Carlson 42.703N 71.076W <carls...@workingcode.com> _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
