[Top] [All Lists]

Re: PAGG ideas for next attempt: new docs, new name?

To: Paul Jackson <pj@xxxxxxx>
Subject: Re: PAGG ideas for next attempt: new docs, new name?
From: Erik Jacobson <erikj@xxxxxxx>
Date: Mon, 19 Sep 2005 08:19:49 -0500
Cc: Erik Jacobson <erikj@xxxxxxx>, pagg@xxxxxxxxxxx
In-reply-to: <20050917104239.26cb7e49.pj@xxxxxxx>
References: <20050917153409.GA17708@xxxxxxx> <20050917104239.26cb7e49.pj@xxxxxxx>
Sender: pagg-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6i
> A couple of random thoughts on first glance now, then I will try to
> give this a closer read later today.

Hi Paul.  I changed over to pnotify, which makes variable names really
long.  But I understand what you're saying here.  

> If the current notifier lists have technical limitations with locking
> and efficiency, then what would it take to fix them up, rather than
> introduce a new mechanism?  Are these limitations inherent and
> unavoidable in any mechanism that has the API of the current notifier
> lists, or are they an internal accident of the implementation?  If the
> latter, can the implementation be fixed?  If the former, can you
> clearly explain why notifier list, or anything so conceived and so
> dedicated with such an API, must necessarily suffer from such technical
> limitations?

I'm still munching on this part.

> A key concern, which you face head on (good!) is that such mechanisms
> as this "allow interesting things to be implemented outside of the
> kernel."  You explain nicely why we need such, but you don't explain

I added a blurb about exporting the symbols with EXPORT_SYMBOL_GPL.
I also changed the Justification quite a bit per your suggestions in a 
separate email.

I'll post a new version a little later.

<Prev in Thread] Current Thread [Next in Thread>