Andrew Morton <[email protected]> wrote:
> waaaaaaaay too many rejects for me, sorry. This is quite the worst time in
> the kernel cycle to be preparing patches like this. Especially when they're
> against mainline when everyone has so much material pending.
Actually... there is a way to do this sort of incrementally, I think:
(1) Turn this sort of thing:
do_work(struct x *x)
{
...
}
queue_x(struct x *x)
{
INIT_WORK(&x->work, do_work, x);
schedule_work(&x->work)
}
Into this sort of thing:
#define DECLARE_IMMEDIATE_WORK(w, f) DECLARE_WORK((w), (f), (w))
#define DECLARE_DELAYED_WORK(w, f) DECLARE_WORK((w), (f), (w))
#define INIT_IMMEDIATE_WORK(w, f) INIT_WORK((w), (f), (w))
#define INIT_DELAYED_WORK(w, f) INIT_WORK((w), (f), (w))
do_work(struct work_struct *work)
{
struct x *x = container_of(work, struct x, work);
...
}
queue_x(struct x *x)
{
INIT_IMMEDIATE_WORK(&x->work, do_work); //or
INIT_DELAYED_WORK(&x->work, do_work);
schedule_work(&x->work)
}
(2) Make delayed_work equivalent to work_struct:
#define delayed_work work_struct
(3) Then apply the rest of the patches such that they remove the #defines as
appropriate.
Might that help?
David
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
