Messages in this thread | | | Subject | Re: [PATCH] LinuxPPS (with new syscalls API) | From | David Woodhouse <> | Date | Wed, 27 Jun 2007 17:11:00 +0100 |
| |
On Wed, 2007-06-27 at 14:58 +0200, Rodolfo Giometti wrote: > On Wed, Jun 27, 2007 at 11:18:30AM +0100, David Woodhouse wrote: > > On Wed, 2007-06-27 at 12:14 +0200, Rodolfo Giometti wrote: > > > On Tue, Jun 26, 2007 at 06:38:40PM +0100, David Woodhouse wrote: > > > > > > > > 64-bit kernels can run 32-bit userspace programs. But some structures > > > > come out _differently_ between 32-bit and 64-bit compilation, so the > > > > system call needs a special 'compat' handler instead of just running the > > > > normal 64-bit system call. > > > > > > > > The 'struct timespec' is one structure which is sometimes different for > > > > 32-bit vs. 64-bit, so any system call taking a 'struct timespec' must > > > > have a separate compat_sys_xxxx() to handle that. See something like > > > > compat_sys_clock_settime() in kernel/compat.c for an example (but don't > > > > use set_fs() like it does; just see how it handles the compat_timespec). > > > > > > Did you mean something like this? > > > > How will 64-bit system calls work if you do it like that? You need to > > provide _both_ sys_time_pps_fetch() and compat_sys_time_pps_fetch(). > > Sorry, I'm new to this 32/64 bits issues... > > Now is it correct?
No, because you're passing a _kernel_ pointer to sys_time_pps_fetch() where it expects a userspace pointer. Use compat_alloc_user_space() to find somewhere to put it in user space, instead. Or change your internal __sys_time_pps_fetch() function to take a number of ticks instead of a pointer to a timespec, then call that directly with appropriate arguments, from both the normal and compat syscall routines. > > Since I have no way to test this code maybe is better add no function > at all and simply using a warning message if someone try compiling > this code with CONFIG_COMPAT enabled...
No. The fact that you cannot test it is no excuse for submitting something which is _known_ to be broken. Once you have it to the point where a casual observer can't point out errors, then people can test it for you.
-- dwmw2
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |