Re: New PAGG patch for 2.6.10, new functionality

I copied linux-2.6.10-pagg.patch-3 to the ftp site just now.  This
implements what you requested.

http://oss.sgi.com/projects/pagg/
Click 'Download' on the left.

Thanks!

On Wed, 12 Jan 2005, Erik Jacobson wrote:

> Sounds worth doing.  I'll have a new patch tomorrow (or I hope to).
>
> Thanks!
>
> On Wed, 12 Jan 2005 [email protected] wrote:
>
> > On Tue, Jan 11, 2005 at 09:11:25AM -0600, Erik Jacobson wrote:
> > > Just to make sure I understand --
> > >
> > > You'd use this in case you want to be notified about each task but you
> > > don't necessarily want paggs allocated for each task as you have no
> > > desire to group them.  Is that right?
> >
> > Yes.
> >
> > >
> > > If so, I just didn't think of that use.  I thought people who wanted the init
> > > function would also want pagg associations.  Could a person who wants
> > > notification of all processes use something like
> > > for_each_process/for_each_task instead?
> >
> > I see. (I'm not sure what you mean by using
> > for_each_process/for_each_task for all processes though).
> >
> > I had the impression that the only difference between init and attach
> > was that init served to catch all existing tasks and attach all tasks
> > during a fork.
> >
> > As for skipping pagg associations, my thought was that there might be
> > users who would choose to skip a task simply because that task did not
> > interest him based on some set criteria.  Some of the existing tasks
> > in the system at the time of the user's registration could fall under
> > the category of being skipped.  For example, "do not do a pagg
> > association for all real time tasks in both init and attach".  If only
> > attach allowed for associations to be skipped then users would not be
> > able to apply their criteria for existing tasks.
> >
> > >
> > > So is the reason you suggest this just to be consistent like you said in
> > > your note?   Or is there a use you had in mind that I didn't think of?
> >
> > I'm not sure - perhaps I wasn't clear enough earlier. Does the above
> > make my reasoning clearer?
> >
> > >
> > > One thing I'd say is that it isn't possible to be fully consistent with
> > > attach anyway.  If the init function pointer fails, it isn't like we can
> > > propegate the error to fork like we do in attach. And I doubt we'd want to
> > > kill the running task :)
> >
> > Absolutely ;) Full consistency isn't possible.  I was only thinking
> > about skipping pagg associations.  A failure during init would have to
> > be different to a failure in attach.  Hence the explanation of what
> > happens with a <0 error return: the registration function fails but
> > the task is not killed.
> >
> >   <0 Error which is propagated back to copy_process so
> >      the registration function fails completely.
> >
> >   =0 success, attach to same container as parent
> >
> >   >0 success, but don't attach to a container
> >
> > >
> > > Let me know your thoughts on this...
> >
> > Thanks for listening,
> > --
> > 		Kingsley
> >
>
> --
> Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota
>

--
Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota