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

Reply via email to