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 t
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?
Actually
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
chang
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 t
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 v
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
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 ab
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 want
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 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 {a
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 y
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 recommen
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 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 :
> > + $(
* 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 it.
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 pa
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 th
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 woul
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 thi
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
> sys_t
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 drawing
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 somethi
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
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 li
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,
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 timespec
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 patch
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 t
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
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/fc
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, Jun 28, 2007 at 12:44:20PM +0100, David Woodhouse wrote:
>
> It's nice if you can do so, but I wouldn't suggest that you _have_ to.
> I have to admit that I rarely bother actually wiring new system calls up
> on anything but PowerPC to start with.
>
> The important thing is that you've _c
On Thu, 2007-06-28 at 10:40 +0200, Rodolfo Giometti wrote:
> On Thu, Jun 28, 2007 at 09:31:14AM +0100, David Woodhouse wrote:
> > On Thu, 2007-06-28 at 10:15 +0200, Rodolfo Giometti wrote:
> > > Do you think I should add these functions into my patch, even if I
> > > cannot test it, or it's enought
On Thu, Jun 28, 2007 at 09:31:14AM +0100, David Woodhouse wrote:
> On Thu, 2007-06-28 at 10:15 +0200, Rodolfo Giometti wrote:
> > Do you think I should add these functions into my patch, even if I
> > cannot test it, or it's enought providing just the
> > compat_sys_time_pps_fetch() function?
>
>
On Thu, 2007-06-28 at 10:15 +0200, Rodolfo Giometti wrote:
> Do you think I should add these functions into my patch, even if I
> cannot test it, or it's enought providing just the
> compat_sys_time_pps_fetch() function?
Probably best to put them in. That way, you make it easier for people to
tes
On Thu, Jun 28, 2007 at 09:08:53AM +0100, David Woodhouse wrote:
> On Thu, 2007-06-28 at 00:46 +0200, Rodolfo Giometti wrote:
> > Just last question: I still don't well understand where I should
> > declare the new compat_sys_time_pps_fetch() syscall... it's
> > automagically defined by the system
On Thu, 2007-06-28 at 00:46 +0200, Rodolfo Giometti wrote:
> Just last question: I still don't well understand where I should
> declare the new compat_sys_time_pps_fetch() syscall... it's
> automagically defined by the system when CONFIG_COMPAT is enabled? :-o
It isn't used on i386. On a 64-bit ar
On Wed, Jun 27, 2007 at 06:49:48PM +0100, David Woodhouse wrote:
>
> Looks better. All I can find to complain about is the fact that you
> return whatever copy_from_user() returns. Don't -- that's the number of
> bytes left to copy. It should be if (copy_from_user(..)) return -EFAULT;
Ok, I'll fi
On Wed, 2007-06-27 at 19:45 +0200, Rodolfo Giometti wrote:
> Ok. Please see the attached patch.
Looks better. All I can find to complain about is the fact that you
return whatever copy_from_user() returns. Don't -- that's the number of
bytes left to copy. It should be if (copy_from_user(..)) retur
On Wed, Jun 27, 2007 at 05:11:00PM +0100, David Woodhouse wrote:
> 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_
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 ru
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 _diffe
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
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-b
David Woodhouse wrote:
On Tue, 2007-06-26 at 19:06 +0200, Rodolfo Giometti wrote:
On Tue, Jun 26, 2007 at 11:57:07AM +0100, David Woodhouse wrote:
Your syscalls blindly dereference userspace pointers instead of using
copy_{to,from} user.
I use access_ok() to test userspace addresses. It should
On Tue, 2007-06-26 at 20:13 +0200, Rodolfo Giometti wrote:
> On Tue, Jun 26, 2007 at 06:38:40PM +0100, David Woodhouse wrote:
>
> > That sounds like you're scared of using goto. Don't be :)
>
> But it's not wrong... should I change it or not?
I would suggest changing it. It makes it more obvious
On Tue, Jun 26, 2007 at 06:38:40PM +0100, David Woodhouse wrote:
> That sounds like you're scared of using goto. Don't be :)
But it's not wrong... should I change it or not?
> I don't see this timepps.h of which you speak. If it's a _userspace_
> file, it cannot include unless you actually add
On Tue, 2007-06-26 at 19:06 +0200, Rodolfo Giometti wrote:
> On Tue, Jun 26, 2007 at 11:57:07AM +0100, David Woodhouse wrote:
> >
> > Your syscalls blindly dereference userspace pointers instead of using
> > copy_{to,from} user.
>
> I use access_ok() to test userspace addresses. It should be ok,
On Tue, Jun 26, 2007 at 11:57:07AM +0100, David Woodhouse wrote:
>
> Your syscalls blindly dereference userspace pointers instead of using
> copy_{to,from} user.
I use access_ok() to test userspace addresses. It should be ok,
shouldn't it?
> Why did you split all your syscalls into two functions
On Tue, 2007-06-26 at 12:06 +0200, Rodolfo Giometti wrote:
> Hello,
>
> here my new version of LinuxPPS with a new syscalls API.
>
> Please take a look at this new patch and report any
> suggestions/modifications so I can prepare a proper patch for kernel
> inclusion.
Your syscalls blindly deref
Hello,
here my new version of LinuxPPS with a new syscalls API.
Please take a look at this new patch and report any
suggestions/modifications so I can prepare a proper patch for kernel
inclusion.
Thanks in advance,
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
62 matches
Mail list logo
