Hi,
On Wed, 1 Aug 2007, Christopher Hoover wrote:
> Satyam Sharma infradead.org> writes:
> > On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
> >
> > > On Mon, Jul 30, 2007 at 10:33:35AM +0530, Satyam Sharma wrote:
> > > Currently the RFC says to you that you should open the serial port:
> > >
>
Satyam Sharma infradead.org> writes:
> On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
>
> > On Mon, Jul 30, 2007 at 10:33:35AM +0530, Satyam Sharma wrote:
> > Currently the RFC says to you that you should open the serial port:
> >
> > fd = open("/dev/ttyS0", ...);
>
> No, it does *NOT*. All
Satyam Sharma satyam at infradead.org writes:
On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
On Mon, Jul 30, 2007 at 10:33:35AM +0530, Satyam Sharma wrote:
Currently the RFC says to you that you should open the serial port:
fd = open(/dev/ttyS0, ...);
No, it does *NOT*. All it
Hi,
On Wed, 1 Aug 2007, Christopher Hoover wrote:
Satyam Sharma satyam at infradead.org writes:
On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
On Mon, Jul 30, 2007 at 10:33:35AM +0530, Satyam Sharma wrote:
Currently the RFC says to you that you should open the serial port:
fd
Hi,
On Tue, 31 Jul 2007, Rodolfo Giometti wrote:
> Sorry for wasting your time. :'( Maybe you can provide your solution
> for PPS support and get it included into kernel tree so we can use it
> and live happy! :)
Please stop embarrassing me (and yourself).
Sorry, I did lose my patience
On Wed, Aug 01, 2007 at 12:19:48AM +0530, Satyam Sharma wrote:
> That's just absolute bullshit.
...
> I'm sorry to say this, Rodolfo, but _all_ your arguments above are
> *totally* nonsensical and factually incorrect -- and I have had enough of
> trying to talk sense to you, it's been ~15 mails
On Tue, 31 Jul 2007, Rodolfo Giometti wrote:
> On Tue, Jul 31, 2007 at 03:31:22AM +0530, Satyam Sharma wrote:
> > Yup, this would avoid races, but then we will lose events. Why is that
> > acceptable, when better alternative (above) exists?
>
> Because is better lossign events then recording
On Tue, Jul 31, 2007 at 03:31:22AM +0530, Satyam Sharma wrote:
> Hi Rodolfo,
Hi :)
> Yup, this would avoid races, but then we will lose events. Why is that
> acceptable, when better alternative (above) exists?
Because is better lossign events then recording them delayed. In the
past we
On Tue, Jul 31, 2007 at 03:31:22AM +0530, Satyam Sharma wrote:
Hi Rodolfo,
Hi :)
Yup, this would avoid races, but then we will lose events. Why is that
acceptable, when better alternative (above) exists?
Because is better lossign events then recording them delayed. In the
past we (LinuxPPS
On Tue, 31 Jul 2007, Rodolfo Giometti wrote:
On Tue, Jul 31, 2007 at 03:31:22AM +0530, Satyam Sharma wrote:
Yup, this would avoid races, but then we will lose events. Why is that
acceptable, when better alternative (above) exists?
Because is better lossign events then recording them
On Wed, Aug 01, 2007 at 12:19:48AM +0530, Satyam Sharma wrote:
That's just absolute bullshit.
...
I'm sorry to say this, Rodolfo, but _all_ your arguments above are
*totally* nonsensical and factually incorrect -- and I have had enough of
trying to talk sense to you, it's been ~15 mails in
Hi,
On Tue, 31 Jul 2007, Rodolfo Giometti wrote:
Sorry for wasting your time. :'( Maybe you can provide your solution
for PPS support and get it included into kernel tree so we can use it
and live happy! :)
Please stop embarrassing me (and yourself).
Sorry, I did lose my patience (others
Hi Rodolfo,
On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
> On Mon, Jul 30, 2007 at 02:37:26PM +0530, Satyam Sharma wrote:
>
> > > Maybe you meant I should using spin_lock_irqsave/restore() in user
> > > context, but doing like this I will disable interrupts
> >
> > Yup, but the goal is to
On Mon, Jul 30, 2007 at 02:37:26PM +0530, Satyam Sharma wrote:
> On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
> >
> > In pps_event() is not useful using spin_lock_irqsave/restore() since
> > the only difference between spin_lock_irqsave() and spin_lock() is
> > that the former will turn off
Hi Rodolfo,
On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
> On Mon, Jul 30, 2007 at 10:39:38AM +0530, Satyam Sharma wrote:
> >
> > Nopes, this isn't quite correct/safe. I suggest you should read:
> >
> > http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/
>
> I read it but
On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
> On Mon, Jul 30, 2007 at 10:33:35AM +0530, Satyam Sharma wrote:
> >
> > Fair enough, but I think the code could become a trifle simpler/easier
> > after the conversion, so probably greater chances of getting merged :-)
>
> I see. I'll start
Hi,
On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
> On Mon, Jul 30, 2007 at 09:49:20AM +0530, Satyam Sharma wrote:
> >
> > Hmm? I still don't see why you can't introduce spin_lock_irqsave/restore()
> > in pps_event() around the access to pps_source.
>
> In pps_event() is not useful using
On Mon, Jul 30, 2007 at 10:39:38AM +0530, Satyam Sharma wrote:
>
> Nopes, this isn't quite correct/safe. I suggest you should read:
>
> http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/
I read it but still I don't see why my solution isn't correct/safe. :)
Can you please
On Mon, Jul 30, 2007 at 10:33:35AM +0530, Satyam Sharma wrote:
>
> Fair enough, but I think the code could become a trifle simpler/easier
> after the conversion, so probably greater chances of getting merged :-)
I see. I'll start thinging about it.
> But that's alright -- see, as I said, you're
On Mon, Jul 30, 2007 at 09:49:20AM +0530, Satyam Sharma wrote:
>
> Hmm? I still don't see why you can't introduce spin_lock_irqsave/restore()
> in pps_event() around the access to pps_source.
In pps_event() is not useful using spin_lock_irqsave/restore() since
the only difference between
On Mon, Jul 30, 2007 at 09:49:20AM +0530, Satyam Sharma wrote:
Hmm? I still don't see why you can't introduce spin_lock_irqsave/restore()
in pps_event() around the access to pps_source.
In pps_event() is not useful using spin_lock_irqsave/restore() since
the only difference between
On Mon, Jul 30, 2007 at 10:33:35AM +0530, Satyam Sharma wrote:
Fair enough, but I think the code could become a trifle simpler/easier
after the conversion, so probably greater chances of getting merged :-)
I see. I'll start thinging about it.
But that's alright -- see, as I said, you're
On Mon, Jul 30, 2007 at 10:39:38AM +0530, Satyam Sharma wrote:
Nopes, this isn't quite correct/safe. I suggest you should read:
http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/
I read it but still I don't see why my solution isn't correct/safe. :)
Can you please propose
Hi,
On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
On Mon, Jul 30, 2007 at 09:49:20AM +0530, Satyam Sharma wrote:
Hmm? I still don't see why you can't introduce spin_lock_irqsave/restore()
in pps_event() around the access to pps_source.
In pps_event() is not useful using
On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
On Mon, Jul 30, 2007 at 10:33:35AM +0530, Satyam Sharma wrote:
Fair enough, but I think the code could become a trifle simpler/easier
after the conversion, so probably greater chances of getting merged :-)
I see. I'll start thinging about
Hi Rodolfo,
On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
On Mon, Jul 30, 2007 at 10:39:38AM +0530, Satyam Sharma wrote:
Nopes, this isn't quite correct/safe. I suggest you should read:
http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/
I read it but still I don't
On Mon, Jul 30, 2007 at 02:37:26PM +0530, Satyam Sharma wrote:
On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
In pps_event() is not useful using spin_lock_irqsave/restore() since
the only difference between spin_lock_irqsave() and spin_lock() is
that the former will turn off interrupts if
Hi Rodolfo,
On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
On Mon, Jul 30, 2007 at 02:37:26PM +0530, Satyam Sharma wrote:
Maybe you meant I should using spin_lock_irqsave/restore() in user
context, but doing like this I will disable interrupts
Yup, but the goal is to avoid races.
Hi Rodolfo,
On Sun, 29 Jul 2007, Rodolfo Giometti wrote:
> On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
>
> > Take the race between the time_pps_setparams() syscall and a concurrent
> > pps_event() from an interrupt for instance. From sys_time_pps_setparams,
> > the
Hi,
On Sun, 29 Jul 2007, Rodolfo Giometti wrote:
> On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
>
> > > [ Also, have you considered making pps_source a list and not an array?
> > > It'll help you lose a whole lot of MAX_SOURCES, pps_is_allocated, etc
> > > kind of gymnastics
Hi Rodolfo,
On Sun, 29 Jul 2007, Rodolfo Giometti wrote:
> On Sat, Jul 28, 2007 at 02:17:24AM +0530, Satyam Sharma wrote:
> >
> > I only glanced through the code, so could be wrong, but I noticed that
> > the only global / shared data you have in there is a global "pps_source"
> > array of
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
> Take the race between the time_pps_setparams() syscall and a concurrent
> pps_event() from an interrupt for instance. From sys_time_pps_setparams,
> the parameters for an existing source are not modified / set atomically,
> which
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
>
> Ok, I've looked through (most of) the RFC and code now, and am only
> commenting on a design-level for now. Anyway, I didn't like the way
> you've significantly drifted from the RFC in several ways:
Please, read documentation
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
>
> Take the race between the time_pps_setparams() syscall and a concurrent
> pps_event() from an interrupt for instance. From sys_time_pps_setparams,
> the parameters for an existing source are not modified / set atomically,
> which
On Sat, Jul 28, 2007 at 02:17:24AM +0530, Satyam Sharma wrote:
>
> I only glanced through the code, so could be wrong, but I noticed that
> the only global / shared data you have in there is a global "pps_source"
> array of pps_s structs. That's accessed / modified from the various
> syscalls
On Sat, Jul 28, 2007 at 02:17:24AM +0530, Satyam Sharma wrote:
I only glanced through the code, so could be wrong, but I noticed that
the only global / shared data you have in there is a global pps_source
array of pps_s structs. That's accessed / modified from the various
syscalls introduced
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
Take the race between the time_pps_setparams() syscall and a concurrent
pps_event() from an interrupt for instance. From sys_time_pps_setparams,
the parameters for an existing source are not modified / set atomically,
which means
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
Ok, I've looked through (most of) the RFC and code now, and am only
commenting on a design-level for now. Anyway, I didn't like the way
you've significantly drifted from the RFC in several ways:
Please, read documentation file
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
Take the race between the time_pps_setparams() syscall and a concurrent
pps_event() from an interrupt for instance. From sys_time_pps_setparams,
the parameters for an existing source are not modified / set atomically,
which means
Hi Rodolfo,
On Sun, 29 Jul 2007, Rodolfo Giometti wrote:
On Sat, Jul 28, 2007 at 02:17:24AM +0530, Satyam Sharma wrote:
I only glanced through the code, so could be wrong, but I noticed that
the only global / shared data you have in there is a global pps_source
array of pps_s structs.
Hi,
On Sun, 29 Jul 2007, Rodolfo Giometti wrote:
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
[ Also, have you considered making pps_source a list and not an array?
It'll help you lose a whole lot of MAX_SOURCES, pps_is_allocated, etc
kind of gymnastics in there,
Hi Rodolfo,
On Sun, 29 Jul 2007, Rodolfo Giometti wrote:
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
Take the race between the time_pps_setparams() syscall and a concurrent
pps_event() from an interrupt for instance. From sys_time_pps_setparams,
the parameters for an
Hi,
On 7/28/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> Hi Rodolfo,
>
> On 7/28/07, Rodolfo Giometti <[EMAIL PROTECTED]> wrote:
> > On Fri, Jul 27, 2007 at 01:40:14PM -0600, Chris Friesen wrote:
> > >
> > > My point is that the lock should be used to protect specific data. Thus,
> > > it
> >
Hi Rodolfo,
On 7/28/07, Rodolfo Giometti <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 27, 2007 at 01:40:14PM -0600, Chris Friesen wrote:
> >
> > My point is that the lock should be used to protect specific data. Thus, it
> > would be more correct to say, "spinlock foo is taken because
> >
On Fri, Jul 27, 2007 at 01:40:14PM -0600, Chris Friesen wrote:
>
> My point is that the lock should be used to protect specific data. Thus, it
> would be more correct to say, "spinlock foo is taken because
> pps_register_source() accesses variable bar".
>
> That way, if someone else wants to
Rodolfo Giometti wrote:
What do you mean? Did you find an error into my patch? :-o
Functions pps_event() and
pps_register_source()/pps_unregister_source() take accesso to shared
data, that's why I used spinlocks.
My point is that the lock should be used to protect specific data.
Thus, it
On Fri, Jul 27, 2007 at 01:08:58PM -0600, Chris Friesen wrote:
> Rodolfo Giometti wrote:
>
>> The pps_event() is now protected by a spinlock against
>> pps_register_source() and pps_unregister_source()...
>
> Locks protect data, not code. It may make more sense to identify the
> specific data
Rodolfo Giometti wrote:
The pps_event() is now protected by a spinlock against
pps_register_source() and pps_unregister_source()...
Locks protect data, not code. It may make more sense to identify the
specific data being protected by the spinlock.
Chris
-
To unsubscribe from this list:
Rodolfo Giometti wrote:
The pps_event() is now protected by a spinlock against
pps_register_source() and pps_unregister_source()...
Locks protect data, not code. It may make more sense to identify the
specific data being protected by the spinlock.
Chris
-
To unsubscribe from this list:
Rodolfo Giometti wrote:
What do you mean? Did you find an error into my patch? :-o
Functions pps_event() and
pps_register_source()/pps_unregister_source() take accesso to shared
data, that's why I used spinlocks.
My point is that the lock should be used to protect specific data.
Thus, it
On Fri, Jul 27, 2007 at 01:40:14PM -0600, Chris Friesen wrote:
My point is that the lock should be used to protect specific data. Thus, it
would be more correct to say, spinlock foo is taken because
pps_register_source() accesses variable bar.
That way, if someone else wants to access bar,
On Fri, Jul 27, 2007 at 01:08:58PM -0600, Chris Friesen wrote:
Rodolfo Giometti wrote:
The pps_event() is now protected by a spinlock against
pps_register_source() and pps_unregister_source()...
Locks protect data, not code. It may make more sense to identify the
specific data being
Hi Rodolfo,
On 7/28/07, Rodolfo Giometti [EMAIL PROTECTED] wrote:
On Fri, Jul 27, 2007 at 01:40:14PM -0600, Chris Friesen wrote:
My point is that the lock should be used to protect specific data. Thus, it
would be more correct to say, spinlock foo is taken because
pps_register_source()
Hi,
On 7/28/07, Satyam Sharma [EMAIL PROTECTED] wrote:
Hi Rodolfo,
On 7/28/07, Rodolfo Giometti [EMAIL PROTECTED] wrote:
On Fri, Jul 27, 2007 at 01:40:14PM -0600, Chris Friesen wrote:
My point is that the lock should be used to protect specific data. Thus,
it
would be more
54 matches
Mail list logo
