Date: Sat, 6 Nov 2010 19:23:18 -0700 From: Weongyo Jeong <weongyo.jeong@gmail.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming <mdf356@gmail.com>, freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system Message-ID: <20101107022318.GF92881@weongyo> In-Reply-To: <201011051930.38530.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <AANLkTimR7MpZ3nyoWqkCR9a=-S6DR_MCNjPA0q5qg3U4@mail.gmail.com> <201011051836.39697.hselasky@c2i.net> <201011051930.38530.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 05, 2010 at 07:30:38PM +0100, Hans Petter Selasky wrote: > Hi, > > In the patch attached to this e-mail I included Matthew Fleming's patch > aswell. > > 1) I renamed taskqueue_cancel() into taskqueue_stop(), hence that resembles > the words of the callout and USB API's terminology for doing the same. > > 2) I turns out I need to have code in subr_taskqueue.c to be able to make the > operations atomic. > > 3) I did not update the manpage in this patch. Will do that before a commit. > > 4) My patch implements separate state keeping in "struct task_pair", which > avoids having to change any KPI's for now, like suggested by John Baldwin I > think. > > 5) In my implementation I hard-coded the priority argument to zero, so that > enqueuing is fast. > > Comments are welcome! The patch looks almost you moved usb_process.c code into taskqueue(9) that I means it still follows that a entry which enqueued at last should be executed at last. It seems that at least it's not a general for taskqueue(9). In my humble opinion it looks a trick. I think it'd better to find a general solution to solve it though I used sx(9) lock in my patches. regards, Weongyo Jeong
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101107022318.GF92881>