Hi,
On Wed, 11 Jul 2007, Lennart Sorensen wrote:
> On Wed, Jul 11, 2007 at 03:18:46AM +0200, Roman Zippel wrote:
> > This is really not an API that needs to deal with such large time range.
>
> No one will want to use PPS API to keep accurate time past 2030? Why
> not? Or should we be forced
On Wed, Jul 11, 2007 at 11:24:55AM -0400, Lennart Sorensen wrote:
> For some reason I thought this was for passing the current time of a
> stamp.
And you was right. :)
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver
On Wed, Jul 11, 2007 at 11:22:38AM -0400, Lennart Sorensen wrote:
> On Wed, Jul 11, 2007 at 10:06:34AM +0200, Rodolfo Giometti wrote:
> > My question is: how can I fit a 64 bits number of seconds into
> > timespec structure which, for 32 bits architetures, has a 32 bits bits
> > number of seconds?
On Wed, Jul 11, 2007 at 03:18:46AM +0200, Roman Zippel wrote:
> This is really not an API that needs to deal with such large time range.
No one will want to use PPS API to keep accurate time past 2030? Why
not? Or should we be forced to invent a new PPS API before then to fix
this one?
On Wed, Jul 11, 2007 at 10:06:34AM +0200, Rodolfo Giometti wrote:
> My question is: how can I fit a 64 bits number of seconds into
> timespec structure which, for 32 bits architetures, has a 32 bits bits
> number of seconds?
I imagine you can't. I have no idea if there are any intensions to
On Wed, Jul 11, 2007 at 10:17:47AM +0100, David Woodhouse wrote:
> On Tue, 2007-07-10 at 18:38 +0200, Rodolfo Giometti wrote:
> > On Tue, Jul 10, 2007 at 05:05:47PM +0100, David Woodhouse wrote:
> > >
> > > I'm sure the version with 'volatile' will also be broken then. Sounds
> > > like the right
On Tue, 2007-07-10 at 18:38 +0200, Rodolfo Giometti wrote:
> On Tue, Jul 10, 2007 at 05:05:47PM +0100, David Woodhouse wrote:
> >
> > I'm sure the version with 'volatile' will also be broken then. Sounds
> > like the right answer is to fix the locking.
>
> But wish avoiding locking at all since
On Tue, Jul 10, 2007 at 06:03:10PM -0400, Lennart Sorensen wrote:
>
> 32bit platforms can still work with 64bit values, they may just not be
> quite as efficient about it.
>
> After all we support files with more than 2^32 bytes in them, so the
> file access structures must have more than 32bit
On Tue, Jul 10, 2007 at 06:03:10PM -0400, Lennart Sorensen wrote:
32bit platforms can still work with 64bit values, they may just not be
quite as efficient about it.
After all we support files with more than 2^32 bytes in them, so the
file access structures must have more than 32bit values
On Tue, 2007-07-10 at 18:38 +0200, Rodolfo Giometti wrote:
On Tue, Jul 10, 2007 at 05:05:47PM +0100, David Woodhouse wrote:
I'm sure the version with 'volatile' will also be broken then. Sounds
like the right answer is to fix the locking.
But wish avoiding locking at all since this may
On Wed, Jul 11, 2007 at 10:17:47AM +0100, David Woodhouse wrote:
On Tue, 2007-07-10 at 18:38 +0200, Rodolfo Giometti wrote:
On Tue, Jul 10, 2007 at 05:05:47PM +0100, David Woodhouse wrote:
I'm sure the version with 'volatile' will also be broken then. Sounds
like the right answer is
On Wed, Jul 11, 2007 at 10:06:34AM +0200, Rodolfo Giometti wrote:
My question is: how can I fit a 64 bits number of seconds into
timespec structure which, for 32 bits architetures, has a 32 bits bits
number of seconds?
I imagine you can't. I have no idea if there are any intensions to
change
On Wed, Jul 11, 2007 at 03:18:46AM +0200, Roman Zippel wrote:
This is really not an API that needs to deal with such large time range.
No one will want to use PPS API to keep accurate time past 2030? Why
not? Or should we be forced to invent a new PPS API before then to fix
this one?
On Wed, Jul 11, 2007 at 11:22:38AM -0400, Lennart Sorensen wrote:
On Wed, Jul 11, 2007 at 10:06:34AM +0200, Rodolfo Giometti wrote:
My question is: how can I fit a 64 bits number of seconds into
timespec structure which, for 32 bits architetures, has a 32 bits bits
number of seconds?
I
On Wed, Jul 11, 2007 at 11:24:55AM -0400, Lennart Sorensen wrote:
For some reason I thought this was for passing the current time of a
stamp.
And you was right. :)
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver
Hi,
On Wed, 11 Jul 2007, Lennart Sorensen wrote:
On Wed, Jul 11, 2007 at 03:18:46AM +0200, Roman Zippel wrote:
This is really not an API that needs to deal with such large time range.
No one will want to use PPS API to keep accurate time past 2030? Why
not? Or should we be forced to
Hi,
On Tuesday 10 July 2007, Lennart Sorensen wrote:
> On Sun, Jul 01, 2007 at 09:24:41PM +0200, Rodolfo Giometti wrote:
> > struct pps_timedata_s {
> >__32 sec;
> >__32 nsec;
> > }
> >
> > Ok? I think 32 bits are enought for keeping seconds... :)
>
> You want to
On Tue, Jul 10, 2007 at 06:36:25PM +0200, Rodolfo Giometti wrote:
> Sorry I wrote wrong. I meant __u32.
>
> I can use __u64 for seconds but doing this there could be problems for
> 32 bits platforms? =:-o
32bit platforms can still work with 64bit values, they may just not be
quite as efficient
On Tue, Jul 10, 2007 at 05:36:16PM +0100, David Woodhouse wrote:
>
> Why would there be problems?
I'm just asking since I don't know well 64 bits architectures. :)
However, how can I fix 64 bits seconds into struct timespec?
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail:
On Tue, Jul 10, 2007 at 05:05:47PM +0100, David Woodhouse wrote:
>
> I'm sure the version with 'volatile' will also be broken then. Sounds
> like the right answer is to fix the locking.
But wish avoiding locking at all since this may delay the time stamp
recording. We (the LinuxPPS guys) niticed
On Tue, Jul 10, 2007 at 12:01:51PM -0400, Lennart Sorensen wrote:
> On Sun, Jul 01, 2007 at 09:24:41PM +0200, Rodolfo Giometti wrote:
> > struct pps_timedata_s {
> >__32 sec;
> >__32 nsec;
> > }
> >
> > Ok? I think 32 bits are enought for keeping seconds... :)
>
> You
On Tue, 2007-07-10 at 18:36 +0200, Rodolfo Giometti wrote:
> Sorry I wrote wrong. I meant __u32.
We guessed that much.
> I can use __u64 for seconds but doing this there could be problems for
> 32 bits platforms? =:-o
Why would there be problems?
--
dwmw2
-
To unsubscribe from this list:
On Mon, 2007-07-09 at 15:19 +0200, Rodolfo Giometti wrote:
>
> > Also read Documentation/volatile-considered-harmful.txt and ponder
> > deeply your use of 'volatile' on certain members of struct pps_s.
>
> I read such document but I'm still convinced that the attribute
> volatile is needed for
On Sun, Jul 01, 2007 at 09:24:41PM +0200, Rodolfo Giometti wrote:
> struct pps_timedata_s {
>__32 sec;
>__32 nsec;
> }
>
> Ok? I think 32 bits are enought for keeping seconds... :)
You want to purposely define an API that will break in 23 years (or is
that 83 years since
On Sun, Jul 01, 2007 at 09:24:41PM +0200, Rodolfo Giometti wrote:
struct pps_timedata_s {
__32 sec;
__32 nsec;
}
Ok? I think 32 bits are enought for keeping seconds... :)
You want to purposely define an API that will break in 23 years (or is
that 83 years since you
On Mon, 2007-07-09 at 15:19 +0200, Rodolfo Giometti wrote:
Also read Documentation/volatile-considered-harmful.txt and ponder
deeply your use of 'volatile' on certain members of struct pps_s.
I read such document but I'm still convinced that the attribute
volatile is needed for
On Tue, Jul 10, 2007 at 12:01:51PM -0400, Lennart Sorensen wrote:
On Sun, Jul 01, 2007 at 09:24:41PM +0200, Rodolfo Giometti wrote:
struct pps_timedata_s {
__32 sec;
__32 nsec;
}
Ok? I think 32 bits are enought for keeping seconds... :)
You want to purposely
On Tue, 2007-07-10 at 18:36 +0200, Rodolfo Giometti wrote:
Sorry I wrote wrong. I meant __u32.
We guessed that much.
I can use __u64 for seconds but doing this there could be problems for
32 bits platforms? =:-o
Why would there be problems?
--
dwmw2
-
To unsubscribe from this list: send
On Tue, Jul 10, 2007 at 05:05:47PM +0100, David Woodhouse wrote:
I'm sure the version with 'volatile' will also be broken then. Sounds
like the right answer is to fix the locking.
But wish avoiding locking at all since this may delay the time stamp
recording. We (the LinuxPPS guys) niticed
On Tue, Jul 10, 2007 at 05:36:16PM +0100, David Woodhouse wrote:
Why would there be problems?
I'm just asking since I don't know well 64 bits architectures. :)
However, how can I fix 64 bits seconds into struct timespec?
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail:
On Tue, Jul 10, 2007 at 06:36:25PM +0200, Rodolfo Giometti wrote:
Sorry I wrote wrong. I meant __u32.
I can use __u64 for seconds but doing this there could be problems for
32 bits platforms? =:-o
32bit platforms can still work with 64bit values, they may just not be
quite as efficient about
Hi,
On Tuesday 10 July 2007, Lennart Sorensen wrote:
On Sun, Jul 01, 2007 at 09:24:41PM +0200, Rodolfo Giometti wrote:
struct pps_timedata_s {
__32 sec;
__32 nsec;
}
Ok? I think 32 bits are enought for keeping seconds... :)
You want to purposely define an API
On Tue, Jul 03, 2007 at 09:09:50AM -0400, David Woodhouse wrote:
>
> Looks relatively sane at first glance; busy this week so haven't looked
> very hard yet. Two thing though... you're mixing proper C types
> (uint32_t) and the Linux-specific legacy crap types (__u32). Pick one. I
> won't
On Mon, Jul 09, 2007 at 12:56:11PM +0200, Oleg Verych wrote:
> On Mon, Jul 09, 2007 at 11:16:43AM +0200, Rodolfo Giometti wrote:
> > On Sun, Jul 08, 2007 at 11:05:32AM +0200, Oleg Verych wrote:
> > > * Rodolfo Giometti (Thu, 28 Jun 2007 18:14:50 +0200)
> > > * Organization: GNU/Linux Device
On Mon, Jul 09, 2007 at 11:16:43AM +0200, Rodolfo Giometti wrote:
> On Sun, Jul 08, 2007 at 11:05:32AM +0200, Oleg Verych wrote:
> > * Rodolfo Giometti (Thu, 28 Jun 2007 18:14:50 +0200)
> > * Organization: GNU/Linux Device Drivers, Embedded Systems and Courses
> >
> > > +.PHONY : all depend dep
>
On Sun, Jul 08, 2007 at 11:05:32AM +0200, Oleg Verych wrote:
> * Rodolfo Giometti (Thu, 28 Jun 2007 18:14:50 +0200)
> * Organization: GNU/Linux Device Drivers, Embedded Systems and Courses
>
> > +.PHONY : all depend dep
> > +
> > +all : .depend $(TARGETS)
> > +
> > +.depend depend dep :
> > +
On Sun, Jul 08, 2007 at 11:05:32AM +0200, Oleg Verych wrote:
* Rodolfo Giometti (Thu, 28 Jun 2007 18:14:50 +0200)
* Organization: GNU/Linux Device Drivers, Embedded Systems and Courses
+.PHONY : all depend dep
+
+all : .depend $(TARGETS)
+
+.depend depend dep :
+ $(CC) $(CFLAGS)
On Mon, Jul 09, 2007 at 11:16:43AM +0200, Rodolfo Giometti wrote:
On Sun, Jul 08, 2007 at 11:05:32AM +0200, Oleg Verych wrote:
* Rodolfo Giometti (Thu, 28 Jun 2007 18:14:50 +0200)
* Organization: GNU/Linux Device Drivers, Embedded Systems and Courses
+.PHONY : all depend dep
+
On Mon, Jul 09, 2007 at 12:56:11PM +0200, Oleg Verych wrote:
On Mon, Jul 09, 2007 at 11:16:43AM +0200, Rodolfo Giometti wrote:
On Sun, Jul 08, 2007 at 11:05:32AM +0200, Oleg Verych wrote:
* Rodolfo Giometti (Thu, 28 Jun 2007 18:14:50 +0200)
* Organization: GNU/Linux Device Drivers,
On Tue, Jul 03, 2007 at 09:09:50AM -0400, David Woodhouse wrote:
Looks relatively sane at first glance; busy this week so haven't looked
very hard yet. Two thing though... you're mixing proper C types
(uint32_t) and the Linux-specific legacy crap types (__u32). Pick one. I
won't recommend
* Rodolfo Giometti (Thu, 28 Jun 2007 18:14:50 +0200)
* Organization: GNU/Linux Device Drivers, Embedded Systems and Courses
> +.PHONY : all depend dep
> +
> +all : .depend $(TARGETS)
> +
> +.depend depend dep :
> + $(CC) $(CFLAGS) -M $(TARGETS:=.c) > .depend
[]
> +# -- Clean section
>
* Rodolfo Giometti (Thu, 28 Jun 2007 18:14:50 +0200)
* Organization: GNU/Linux Device Drivers, Embedded Systems and Courses
+.PHONY : all depend dep
+
+all : .depend $(TARGETS)
+
+.depend depend dep :
+ $(CC) $(CFLAGS) -M $(TARGETS:=.c) .depend
[]
+# -- Clean section
On Tue, Jul 03, 2007 at 09:09:50AM -0400, David Woodhouse wrote:
> On Tue, 2007-07-03 at 11:48 +0200, Rodolfo Giometti wrote:
> > On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote:
> > >
> > > Seems reasonable enough in principle -- but whatever you do, don't use
> > > "long" for
On Tue, 2007-07-03 at 11:48 +0200, Rodolfo Giometti wrote:
> On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote:
> >
> > Seems reasonable enough in principle -- but whatever you do, don't use
> > "long" for it. That would definitely need different behaviour for 32-bit
> > vs. 64-bit.
On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote:
>
> Seems reasonable enough in principle -- but whatever you do, don't use
> "long" for it. That would definitely need different behaviour for 32-bit
> vs. 64-bit. Use explicitly sized types such as uint32_t or uint64_t.
Here the
On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote:
Seems reasonable enough in principle -- but whatever you do, don't use
long for it. That would definitely need different behaviour for 32-bit
vs. 64-bit. Use explicitly sized types such as uint32_t or uint64_t.
Here the patch
On Tue, 2007-07-03 at 11:48 +0200, Rodolfo Giometti wrote:
On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote:
Seems reasonable enough in principle -- but whatever you do, don't use
long for it. That would definitely need different behaviour for 32-bit
vs. 64-bit. Use
On Tue, Jul 03, 2007 at 09:09:50AM -0400, David Woodhouse wrote:
On Tue, 2007-07-03 at 11:48 +0200, Rodolfo Giometti wrote:
On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote:
Seems reasonable enough in principle -- but whatever you do, don't use
long for it. That would
On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote:
>
> Seems reasonable enough in principle -- but whatever you do, don't use
> "long" for it. That would definitely need different behaviour for 32-bit
> vs. 64-bit. Use explicitly sized types such as uint32_t or uint64_t.
Which is
On Sun, Jul 01, 2007 at 05:13:25PM +1000, Stephen Rothwell wrote:
> On Sat, 30 Jun 2007 19:13:40 +0200 Rodolfo Giometti <[EMAIL PROTECTED]> wrote:
> >
> > Maybe I can define a special struct for exchanging time data as:
> >
> >struct pps_timedata_s {
> > long sec;
> > long nsec;
>
On Sat, 2007-06-30 at 19:13 +0200, Rodolfo Giometti wrote:
> Maybe I can define a special struct for exchanging time data as:
>
>struct pps_timedata_s {
> long sec;
> long nsec;
>}
Seems reasonable enough in principle -- but whatever you do, don't use
"long" for it. That
On Sat, 30 Jun 2007 19:13:40 +0200 Rodolfo Giometti <[EMAIL PROTECTED]> wrote:
>
> Maybe I can define a special struct for exchanging time data as:
>
>struct pps_timedata_s {
> long sec;
> long nsec;
>}
>
> and managing time data conversions at userland...
>
> What do you
On Sat, 30 Jun 2007 19:13:40 +0200 Rodolfo Giometti [EMAIL PROTECTED] wrote:
Maybe I can define a special struct for exchanging time data as:
struct pps_timedata_s {
long sec;
long nsec;
}
and managing time data conversions at userland...
What do you think about
On Sat, 2007-06-30 at 19:13 +0200, Rodolfo Giometti wrote:
Maybe I can define a special struct for exchanging time data as:
struct pps_timedata_s {
long sec;
long nsec;
}
Seems reasonable enough in principle -- but whatever you do, don't use
long for it. That would
On Sun, Jul 01, 2007 at 05:13:25PM +1000, Stephen Rothwell wrote:
On Sat, 30 Jun 2007 19:13:40 +0200 Rodolfo Giometti [EMAIL PROTECTED] wrote:
Maybe I can define a special struct for exchanging time data as:
struct pps_timedata_s {
long sec;
long nsec;
}
and
On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote:
Seems reasonable enough in principle -- but whatever you do, don't use
long for it. That would definitely need different behaviour for 32-bit
vs. 64-bit. Use explicitly sized types such as uint32_t or uint64_t.
Which is the
On Fri, Jun 29, 2007 at 05:40:52PM +0100, David Woodhouse wrote:
>
> Remember you have to support _both_ 32-bit and 64-bit system calls. You
> need to define struct compat_pps_info and struct compat_pps_params, and
> you'll have to provide a compat wrapper for sys_time_pps_getparams() and
>
On Sat, Jun 30, 2007 at 09:38:27AM +0100, Christoph Hellwig wrote:
>
> Sorry for coming in that late, but using syscalls for something as
> periphal sounds like a very bad idea to me, and the syscalls aren't
> defined nicely either (e.g. you have an ioctl lookalike). I'd say
> back to the
On Thu, Jun 28, 2007 at 06:14:50PM +0200, Rodolfo Giometti wrote:
> Hello,
>
> here my new LinuxPPS patch.
>
> What to do now for kernel inclusion? Should I provide several patches?
> If so how should I divide them?
>
> Thanks a lot,
Sorry for coming in that late, but using syscalls for
On Thu, Jun 28, 2007 at 06:14:50PM +0200, Rodolfo Giometti wrote:
Hello,
here my new LinuxPPS patch.
What to do now for kernel inclusion? Should I provide several patches?
If so how should I divide them?
Thanks a lot,
Sorry for coming in that late, but using syscalls for something as
On Sat, Jun 30, 2007 at 09:38:27AM +0100, Christoph Hellwig wrote:
Sorry for coming in that late, but using syscalls for something as
periphal sounds like a very bad idea to me, and the syscalls aren't
defined nicely either (e.g. you have an ioctl lookalike). I'd say
back to the
On Fri, Jun 29, 2007 at 05:40:52PM +0100, David Woodhouse wrote:
Remember you have to support _both_ 32-bit and 64-bit system calls. You
need to define struct compat_pps_info and struct compat_pps_params, and
you'll have to provide a compat wrapper for sys_time_pps_getparams() and
On Fri, 2007-06-29 at 18:34 +0200, Rodolfo Giometti wrote:
> Gulp! Can you please give me some advices in order to solve also this
> problem? Should I use some "ifdef CONFIG_COMPAT" into those
> structures? :-o
Remember you have to support _both_ 32-bit and 64-bit system calls. You
need to
On Fri, 2007-06-29 at 18:36 +0200, Rodolfo Giometti wrote:
> On Fri, Jun 29, 2007 at 05:23:28PM +0100, David Woodhouse wrote:
> >
> > You'll need to put it in an #else case, not in #ifndef __KERNEL__.
>
> Sorry. :)
That matches what I built with earlier.
--
dwmw2
-
To unsubscribe from this
On Fri, Jun 29, 2007 at 05:23:28PM +0100, David Woodhouse wrote:
>
> You'll need to put it in an #else case, not in #ifndef __KERNEL__.
Sorry. :)
diff --git a/include/linux/pps.h b/include/linux/pps.h
index 6b53864..9e3af51 100644
--- a/include/linux/pps.h
+++ b/include/linux/pps.h
@@ -34,6
On Fri, Jun 29, 2007 at 04:55:47PM +0100, David Woodhouse wrote:
> You missed one. This should be -EFAULT too. And there's not a huge
> amount of point in keeping the access_ok() checks elsewhere, since
> copy_to_user() does that for itself.
Ok, fixed.
> Oh, and I think you do need compat magic
On Fri, 2007-06-29 at 18:23 +0200, Rodolfo Giometti wrote:
> On Fri, Jun 29, 2007 at 04:41:33PM +0100, David Woodhouse wrote:
> >
> > includes , for some reason.
> > doesn't.
> >
> > You shouldn't rely on being pulled in like that -- you
> > either need a forward declaration of struct
On Fri, Jun 29, 2007 at 04:41:33PM +0100, David Woodhouse wrote:
>
> includes , for some reason.
> doesn't.
>
> You shouldn't rely on being pulled in like that -- you
> either need a forward declaration of struct timespec, or to include
> for yourself from
Can you please check if this
On Fri, 2007-06-29 at 17:08 +0200, Rodolfo Giometti wrote:
>
> +asmlinkage long sys_time_pps_fetch(int source, const int tsformat,
> + struct pps_info __user *info,
> + const struct timespec __user *timeout)
> +{
> +
On Fri, 2007-06-29 at 17:38 +0200, Rodolfo Giometti wrote:
> How is that possible??? I just git pull the linux code... maybe you
> have a bit older version?
includes , for some reason.
doesn't.
You shouldn't rely on being pulled in like that -- you
either need a forward declaration of struct
On Fri, Jun 29, 2007 at 04:25:16PM +0100, David Woodhouse wrote:
> On Fri, 2007-06-29 at 17:08 +0200, Rodolfo Giometti wrote:
> > On Fri, Jun 29, 2007 at 12:38:02PM +0100, David Woodhouse wrote:
> > >
> > > It doesn't apply to the current git tree, which has already had some new
> > > system
On Fri, 2007-06-29 at 17:08 +0200, Rodolfo Giometti wrote:
> On Fri, Jun 29, 2007 at 12:38:02PM +0100, David Woodhouse wrote:
> >
> > It doesn't apply to the current git tree, which has already had some new
> > system calls added.
>
> Ok, here the patch against latest git commit.
CC
On Thu, 2007-06-28 at 18:14 +0200, Rodolfo Giometti wrote:
> here my new LinuxPPS patch.
>
> What to do now for kernel inclusion? Should I provide several patches?
> If so how should I divide them?
It doesn't apply to the current git tree, which has already had some new
system calls added.
--
On Thu, 2007-06-28 at 18:14 +0200, Rodolfo Giometti wrote:
here my new LinuxPPS patch.
What to do now for kernel inclusion? Should I provide several patches?
If so how should I divide them?
It doesn't apply to the current git tree, which has already had some new
system calls added.
--
On Fri, 2007-06-29 at 17:08 +0200, Rodolfo Giometti wrote:
On Fri, Jun 29, 2007 at 12:38:02PM +0100, David Woodhouse wrote:
It doesn't apply to the current git tree, which has already had some new
system calls added.
Ok, here the patch against latest git commit.
CC fs/fcntl.o
In
On Fri, Jun 29, 2007 at 04:25:16PM +0100, David Woodhouse wrote:
On Fri, 2007-06-29 at 17:08 +0200, Rodolfo Giometti wrote:
On Fri, Jun 29, 2007 at 12:38:02PM +0100, David Woodhouse wrote:
It doesn't apply to the current git tree, which has already had some new
system calls added.
On Fri, 2007-06-29 at 17:38 +0200, Rodolfo Giometti wrote:
How is that possible??? I just git pull the linux code... maybe you
have a bit older version?
asm-i386/signal.h includes linux/time.h, for some reason.
asm-powerpc/signal.h doesn't.
You shouldn't rely on linux/time.h being pulled in
On Fri, 2007-06-29 at 17:08 +0200, Rodolfo Giometti wrote:
+asmlinkage long sys_time_pps_fetch(int source, const int tsformat,
+ struct pps_info __user *info,
+ const struct timespec __user *timeout)
+{
+ int
On Fri, Jun 29, 2007 at 04:41:33PM +0100, David Woodhouse wrote:
asm-i386/signal.h includes linux/time.h, for some reason.
asm-powerpc/signal.h doesn't.
You shouldn't rely on linux/time.h being pulled in like that -- you
either need a forward declaration of struct timespec, or to include
On Fri, 2007-06-29 at 18:23 +0200, Rodolfo Giometti wrote:
On Fri, Jun 29, 2007 at 04:41:33PM +0100, David Woodhouse wrote:
asm-i386/signal.h includes linux/time.h, for some reason.
asm-powerpc/signal.h doesn't.
You shouldn't rely on linux/time.h being pulled in like that -- you
On Fri, 2007-06-29 at 18:36 +0200, Rodolfo Giometti wrote:
On Fri, Jun 29, 2007 at 05:23:28PM +0100, David Woodhouse wrote:
You'll need to put it in an #else case, not in #ifndef __KERNEL__.
Sorry. :)
That matches what I built with earlier.
--
dwmw2
-
To unsubscribe from this list:
On Fri, Jun 29, 2007 at 04:55:47PM +0100, David Woodhouse wrote:
You missed one. This should be -EFAULT too. And there's not a huge
amount of point in keeping the access_ok() checks elsewhere, since
copy_to_user() does that for itself.
Ok, fixed.
Oh, and I think you do need compat magic for
On Fri, Jun 29, 2007 at 05:23:28PM +0100, David Woodhouse wrote:
You'll need to put it in an #else case, not in #ifndef __KERNEL__.
Sorry. :)
diff --git a/include/linux/pps.h b/include/linux/pps.h
index 6b53864..9e3af51 100644
--- a/include/linux/pps.h
+++ b/include/linux/pps.h
@@ -34,6 +34,8
On Fri, 2007-06-29 at 18:34 +0200, Rodolfo Giometti wrote:
Gulp! Can you please give me some advices in order to solve also this
problem? Should I use some ifdef CONFIG_COMPAT into those
structures? :-o
Remember you have to support _both_ 32-bit and 64-bit system calls. You
need to define
84 matches
Mail list logo
