Re: [PATCH] re-export cancel_rearming_delayed_workqueue
On Sun, 2005-04-10 at 21:48 +0200, Arjan van de Ven wrote: > I have absolutely no problem with such an export / unstatic if there are > users... could you just send them in one go ? Actually, no ... this is a nasty cross tree dependency. The piece of code is queued in the parisc tree, but Matthew can't really send it to Linus until the interface it uses is in the tree. It's someone else's code, I just fixed its problems. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] re-export cancel_rearming_delayed_workqueue
On Sun, 2005-04-10 at 14:07 -0500, James Bottomley wrote: > This was unexported by Arjan because we have no current users. > > However, during a conversion from tasklets to workqueues of the parisc > led functions, we ran across a case where this was needed. In > particular, the open coded equivalent of > cancel_rearming_delayed_workqueue was implemented incorrectly, which is, > I think, all the evidence necessary that this is a useful API. I have absolutely no problem with such an export / unstatic if there are users... could you just send them in one go ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] re-export cancel_rearming_delayed_workqueue
This was unexported by Arjan because we have no current users.
However, during a conversion from tasklets to workqueues of the parisc
led functions, we ran across a case where this was needed. In
particular, the open coded equivalent of
cancel_rearming_delayed_workqueue was implemented incorrectly, which is,
I think, all the evidence necessary that this is a useful API.
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
= include/linux/workqueue.h 1.10 vs edited =
--- 1.10/include/linux/workqueue.h 2005-02-15 15:56:55 -06:00
+++ edited/include/linux/workqueue.h2005-04-05 11:13:50 -05:00
@@ -71,6 +71,8 @@
extern void init_workqueues(void);
void cancel_rearming_delayed_work(struct work_struct *work);
+void cancel_rearming_delayed_workqueue(struct workqueue_struct *,
+ struct work_struct *);
/*
* Kill off a pending schedule_delayed_work(). Note that the work callback
= kernel/workqueue.c 1.33 vs edited =
--- 1.33/kernel/workqueue.c 2005-02-22 21:23:08 -06:00
+++ edited/kernel/workqueue.c 2005-04-05 11:13:52 -05:00
@@ -429,12 +429,13 @@
* @wq: the controlling workqueue structure
* @work: the delayed work struct
*/
-static void cancel_rearming_delayed_workqueue(struct workqueue_struct *wq,
- struct work_struct *work)
+void cancel_rearming_delayed_workqueue(struct workqueue_struct *wq,
+ struct work_struct *work)
{
while (!cancel_delayed_work(work))
flush_workqueue(wq);
}
+EXPORT_SYMBOL(cancel_rearming_delayed_workqueue);
/**
* cancel_rearming_delayed_work - reliably kill off a delayed keventd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] re-export cancel_rearming_delayed_workqueue
This was unexported by Arjan because we have no current users.
However, during a conversion from tasklets to workqueues of the parisc
led functions, we ran across a case where this was needed. In
particular, the open coded equivalent of
cancel_rearming_delayed_workqueue was implemented incorrectly, which is,
I think, all the evidence necessary that this is a useful API.
Signed-off-by: James Bottomley [EMAIL PROTECTED]
= include/linux/workqueue.h 1.10 vs edited =
--- 1.10/include/linux/workqueue.h 2005-02-15 15:56:55 -06:00
+++ edited/include/linux/workqueue.h2005-04-05 11:13:50 -05:00
@@ -71,6 +71,8 @@
extern void init_workqueues(void);
void cancel_rearming_delayed_work(struct work_struct *work);
+void cancel_rearming_delayed_workqueue(struct workqueue_struct *,
+ struct work_struct *);
/*
* Kill off a pending schedule_delayed_work(). Note that the work callback
= kernel/workqueue.c 1.33 vs edited =
--- 1.33/kernel/workqueue.c 2005-02-22 21:23:08 -06:00
+++ edited/kernel/workqueue.c 2005-04-05 11:13:52 -05:00
@@ -429,12 +429,13 @@
* @wq: the controlling workqueue structure
* @work: the delayed work struct
*/
-static void cancel_rearming_delayed_workqueue(struct workqueue_struct *wq,
- struct work_struct *work)
+void cancel_rearming_delayed_workqueue(struct workqueue_struct *wq,
+ struct work_struct *work)
{
while (!cancel_delayed_work(work))
flush_workqueue(wq);
}
+EXPORT_SYMBOL(cancel_rearming_delayed_workqueue);
/**
* cancel_rearming_delayed_work - reliably kill off a delayed keventd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] re-export cancel_rearming_delayed_workqueue
On Sun, 2005-04-10 at 14:07 -0500, James Bottomley wrote: This was unexported by Arjan because we have no current users. However, during a conversion from tasklets to workqueues of the parisc led functions, we ran across a case where this was needed. In particular, the open coded equivalent of cancel_rearming_delayed_workqueue was implemented incorrectly, which is, I think, all the evidence necessary that this is a useful API. I have absolutely no problem with such an export / unstatic if there are users... could you just send them in one go ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] re-export cancel_rearming_delayed_workqueue
On Sun, 2005-04-10 at 21:48 +0200, Arjan van de Ven wrote: I have absolutely no problem with such an export / unstatic if there are users... could you just send them in one go ? Actually, no ... this is a nasty cross tree dependency. The piece of code is queued in the parisc tree, but Matthew can't really send it to Linus until the interface it uses is in the tree. It's someone else's code, I just fixed its problems. James - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
