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 i
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 (other
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 t
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
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 avoi
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 interr
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 stil
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 thingin
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 spin_l
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 propo
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 spin_loc
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
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 i
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_
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 mea
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 m
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 intr
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
> > pps_register
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 acce
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 wou
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 bei
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: sen
27 matches
Mail list logo
