From: Jes Sorensen <jes@trained-monkey.org>
To: Matt Helsley <matthltc@us.ibm.com>
Cc: Shailabh Nagar <nagar@watson.ibm.com>,
Andrew Morton <akpm@osdl.org>, Jay Lan <jlan@engr.sgi.com>,
LKML <linux-kernel@vger.kernel.org>,
elsa-devel@lists.sourceforge.net, lse-tech@lists.sourceforge.net,
CKRM-Tech <ckrm-tech@lists.sourceforge.net>,
Paul Jackson <pj@sgi.com>, Erik Jacobson <erikj@sgi.com>,
Jack Steiner <steiner@sgi.com>, John Hesterberg <jh@sgi.com>
Subject: Re: [Lse-tech] Re: [ckrm-tech] Re: [PATCH 00/01] Move Exit Connectors
Date: 13 Jan 2006 05:38:39 -0500 [thread overview]
Message-ID: <yq03bjs2z0w.fsf@jaguar.mkp.net> (raw)
In-Reply-To: <1137106871.6673.238.camel@stark>
>>>>> "Matt" == Matt Helsley <matthltc@us.ibm.com> writes:
Matt> On Thu, 2006-01-12 at 04:51 -0500, Jes Sorensen wrote:
Matt> Have you looked at Alan Stern's notifier chain fix patch? Could
Matt> that be used in task_notify?
>> No sorry, do you have a pointer?
Matt> No problem. Here it is:
Matt> http://marc.theaimsgroup.com/?l=linux-kernel&m=113407207418475&w=2
Matt> I think it would be ideal if task_notify could simply be a
Matt> notifier chain for notifying users of task events/changes.
Ok, went back and looked at this. I think the core concept is fine,
but there are details such as having a data pointer associated with
the notifier block which is too important to leave out. Otherwise we
have to stick things into the task struct in many cases which is a
waste of space. I also think it needs to be possible to search the
list for special slow path uses to avoid us adding excessive amounts
of callbacks that are only used in one place by one client.
If we can cross-API it for task-group-notifiers then that should be
fine.
Cheers,
Jes
next prev parent reply other threads:[~2006-01-13 10:38 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-03 23:16 [Patch 0/6] Per-task delay accounting Shailabh Nagar
2006-01-03 23:23 ` [Patch 1/6] Delay accounting: timespec diff Shailabh Nagar
2006-01-03 23:26 ` [Patch 2/6] Delay accounting: Initialization, kernel boot option Shailabh Nagar
2006-01-03 23:28 ` [Patch 3/6] Delay accounting: Sync block I/O delays Shailabh Nagar
2006-01-03 23:30 ` [Patch 4/6] Delay accounting: Swap in delays Shailabh Nagar
2006-01-03 23:31 ` [Patch 5/6] Delay accounting: /proc interface Shailabh Nagar
2006-01-03 23:33 ` [Patch 6/6] Delay accounting: Connector interface Shailabh Nagar
2006-01-04 0:21 ` Greg KH
2006-01-04 0:42 ` Shailabh Nagar
2006-01-04 0:51 ` Greg KH
2006-01-04 7:49 ` [Lse-tech] " Shailabh Nagar
2006-01-04 19:04 ` Jay Lan
2006-01-04 21:31 ` Shailabh Nagar
2006-01-04 22:40 ` [ckrm-tech] " Matt Helsley
2006-01-04 23:17 ` Andrew Morton
2006-01-05 18:42 ` [PATCH 00/01] Move Exit Connectors Matt Helsley
2006-01-05 19:17 ` [PATCH 01/01][RFC] " Matt Helsley
2006-01-05 19:20 ` [PATCH 00/01] " Matt Helsley
2006-01-05 23:10 ` Andrew Morton
2006-01-06 0:06 ` [ckrm-tech] " Matt Helsley
2006-01-06 8:57 ` [Lse-tech] " Jes Sorensen
2006-01-06 16:45 ` Shailabh Nagar
2006-01-11 10:36 ` Jes Sorensen
2006-01-11 12:56 ` John Hesterberg
2006-01-11 13:50 ` Jes Sorensen
2006-01-11 21:02 ` Matt Helsley
2006-01-11 21:39 ` John Hesterberg
2006-01-11 22:42 ` Matt Helsley
2006-01-12 10:01 ` Jes Sorensen
2006-01-12 23:20 ` Matt Helsley
2006-01-13 9:35 ` Jes Sorensen
2006-01-14 7:23 ` Matt Helsley
2006-01-12 3:29 ` Keith Owens
2006-01-12 5:04 ` Paul E. McKenney
2006-01-12 5:38 ` Keith Owens
2006-01-12 6:19 ` Keith Owens
2006-01-12 6:51 ` Paul E. McKenney
2006-01-12 7:50 ` Keith Owens
2006-01-12 15:17 ` Paul E. McKenney
2006-01-17 17:26 ` Paul E. McKenney
2006-01-17 23:57 ` Keith Owens
2006-01-18 2:49 ` Paul E. McKenney
2006-01-18 2:55 ` Lee Revell
2006-01-18 6:29 ` Paul E. McKenney
2006-01-12 5:26 ` Matt Helsley
2006-01-12 5:45 ` Keith Owens
2006-01-12 9:51 ` Jes Sorensen
2006-01-12 23:01 ` Matt Helsley
2006-01-13 9:59 ` Jes Sorensen
2006-01-13 10:38 ` Jes Sorensen [this message]
2006-01-13 23:22 ` Matt Helsley
2006-01-12 23:49 ` Matt Helsley
2006-01-05 0:01 ` [ckrm-tech] Re: [Patch 6/6] Delay accounting: Connector interface Shailabh Nagar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yq03bjs2z0w.fsf@jaguar.mkp.net \
--to=jes@trained-monkey.org \
--cc=akpm@osdl.org \
--cc=ckrm-tech@lists.sourceforge.net \
--cc=elsa-devel@lists.sourceforge.net \
--cc=erikj@sgi.com \
--cc=jh@sgi.com \
--cc=jlan@engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=matthltc@us.ibm.com \
--cc=nagar@watson.ibm.com \
--cc=pj@sgi.com \
--cc=steiner@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®