All of lore.kernel.org
 help / color / mirror / Atom feed
* [Kernel-janitors] [PATCH] parport/parport_pc: replace
@ 2004-07-27 21:12 Nishanth Aravamudan
  2004-07-28 14:51 ` [Kernel-janitors] [PATCH] parport/parport_pc: Mark Hollomon
  2004-07-28 15:44 ` Re: [Kernel-janitors] [PATCH] parport/parport_pc: replace Nish Aravamudan
  0 siblings, 2 replies; 3+ messages in thread
From: Nishanth Aravamudan @ 2004-07-27 21:12 UTC (permalink / raw)
  To: kernel-janitors

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

I would appreciate any comments from the janitors list. This is one (of
many) cases where I made a decision about replacing

set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(some_time);

with

msleep(jiffies_to_msecs(some_time));

msleep() is not exactly the same as the previous code, but I only did
this replacement where I thought long delays were *desired*. If this is
not the case here, then just disregard this patch. 

Thanks,
Nish



Applys-to: 2.6.7

Description: Uses msleep() instead of schedule_timeout() to guarantee
the task delays the desired time.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>

--- linux-vanilla/drivers/parport/parport_pc.c	2004-06-16 05:20:04.000000000 +0000
+++ linux-dev/drivers/parport/parport_pc.c	2004-07-12 22:09:32.000000000 +0000
@@ -168,8 +168,7 @@ static int change_mode(struct parport *p
 				if (time_after_eq (jiffies, expire))
 					/* The FIFO is stuck. */
 					return -EBUSY;
-				__set_current_state (TASK_INTERRUPTIBLE);
-				schedule_timeout ((HZ + 99) / 100);
+				msleep(10);
 				if (signal_pending (current))
 					break;
 			}

[-- Attachment #2: Type: text/plain, Size: 167 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Kernel-janitors] [PATCH] parport/parport_pc:
  2004-07-27 21:12 [Kernel-janitors] [PATCH] parport/parport_pc: replace Nishanth Aravamudan
@ 2004-07-28 14:51 ` Mark Hollomon
  2004-07-28 15:44 ` Re: [Kernel-janitors] [PATCH] parport/parport_pc: replace Nish Aravamudan
  1 sibling, 0 replies; 3+ messages in thread
From: Mark Hollomon @ 2004-07-28 14:51 UTC (permalink / raw)
  To: kernel-janitors

[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]

Nishanth Aravamudan wrote:
> I would appreciate any comments from the janitors list. This is one (of
> many) cases where I made a decision about replacing
> 
> set_current_state(TASK_INTERRUPTIBLE);
> schedule_timeout(some_time);
> 
> with
> 
> msleep(jiffies_to_msecs(some_time));
> 
> msleep() is not exactly the same as the previous code, but I only did
> this replacement where I thought long delays were *desired*. If this is
> not the case here, then just disregard this patch. 
> 
> Thanks,
> Nish
> 
> 
> 
> Applys-to: 2.6.7
> 
> Description: Uses msleep() instead of schedule_timeout() to guarantee
> the task delays the desired time.
> 
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> 
> --- linux-vanilla/drivers/parport/parport_pc.c	2004-06-16 05:20:04.000000000 +0000
> +++ linux-dev/drivers/parport/parport_pc.c	2004-07-12 22:09:32.000000000 +0000
> @@ -168,8 +168,7 @@ static int change_mode(struct parport *p
>  				if (time_after_eq (jiffies, expire))
>  					/* The FIFO is stuck. */
>  					return -EBUSY;
> -				__set_current_state (TASK_INTERRUPTIBLE);
> -				schedule_timeout ((HZ + 99) / 100);
> +				msleep(10);
>  				if (signal_pending (current))
>  					break;
>  			}

Wouldn't the check of signal_pending indicate that the interruptability 
was intentional?


-- 
--------------------------
Mark Hollomon

[-- Attachment #2: Type: text/plain, Size: 167 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Re: [Kernel-janitors] [PATCH] parport/parport_pc: replace
  2004-07-27 21:12 [Kernel-janitors] [PATCH] parport/parport_pc: replace Nishanth Aravamudan
  2004-07-28 14:51 ` [Kernel-janitors] [PATCH] parport/parport_pc: Mark Hollomon
@ 2004-07-28 15:44 ` Nish Aravamudan
  1 sibling, 0 replies; 3+ messages in thread
From: Nish Aravamudan @ 2004-07-28 15:44 UTC (permalink / raw)
  To: kernel-janitors

[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

You are very right, Mark. I had tried to catch these misses on my part
as I was submitting but must have looked right past this one. This
patch should not be applied.

-Nish

On Wed, 28 Jul 2004 10:51:05 -0400, Mark Hollomon
<markhollomon@comcast.net> wrote:
> 
> 
> Nishanth Aravamudan wrote:
> > I would appreciate any comments from the janitors list. This is one (of
> > many) cases where I made a decision about replacing
> >
> > set_current_state(TASK_INTERRUPTIBLE);
> > schedule_timeout(some_time);
> >
> > with
> >
> > msleep(jiffies_to_msecs(some_time));
> >
> > msleep() is not exactly the same as the previous code, but I only did
> > this replacement where I thought long delays were *desired*. If this is
> > not the case here, then just disregard this patch.
> >
> > Thanks,
> > Nish
> >
> >
> >
> > Applys-to: 2.6.7
> >
> > Description: Uses msleep() instead of schedule_timeout() to guarantee
> > the task delays the desired time.
> >
> > Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> >
> > --- linux-vanilla/drivers/parport/parport_pc.c        2004-06-16 05:20:04.000000000 +0000
> > +++ linux-dev/drivers/parport/parport_pc.c    2004-07-12 22:09:32.000000000 +0000
> > @@ -168,8 +168,7 @@ static int change_mode(struct parport *p
> >                               if (time_after_eq (jiffies, expire))
> >                                       /* The FIFO is stuck. */
> >                                       return -EBUSY;
> > -                             __set_current_state (TASK_INTERRUPTIBLE);
> > -                             schedule_timeout ((HZ + 99) / 100);
> > +                             msleep(10);
> >                               if (signal_pending (current))
> >                                       break;
> >                       }
> 
> Wouldn't the check of signal_pending indicate that the interruptability
> was intentional?
> 
> --
> --------------------------
> Mark Hollomon
> 
> 
>

[-- Attachment #2: Type: text/plain, Size: 167 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-07-28 15:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-27 21:12 [Kernel-janitors] [PATCH] parport/parport_pc: replace Nishanth Aravamudan
2004-07-28 14:51 ` [Kernel-janitors] [PATCH] parport/parport_pc: Mark Hollomon
2004-07-28 15:44 ` Re: [Kernel-janitors] [PATCH] parport/parport_pc: replace Nish Aravamudan

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.