Erik wrote:
> I feel one reason PAGG didn't get attention was because it's true function
> was obscured by its name and the names of functions and variables within.
I tend to agree.
> Finally, there is an init event.
When does this init event occur - at the beginning of something,
I presume. I'm just not clear of what.
> fork event is a spot in copy_process when a parent forks.
So this event is in the parent, not the child? That seems
slightly odd.
> The init event is specified, so all processes on the system will
> be associated with this kernel module and the test_init function
> will be run for each.
Ah .. run when? Perhaps the last line above would be clearer as:
> will be run for each process in the system when the module is loaded.
> int rc = pn_register(&pn_service_request);
> if (rc < 0) {
> return -1;
> }
Should that "return -1" be a "return -ERRNO" for some error number?
> unrelated processes together to be tracked and signaled as ia set
Is that "ia" a typo?
> /* We have a valid task now */
> get_task_struct(task); /* Ensure the task doesn't vanish on us */
> read_unlock(&tasklist_lock); /* Unlock the tasklist */
> ...
What is the piece of code, beginning with these three lines, doing?
> In a world where all customers need to run on standard distributions to
> be supported by the distributor, we're left in a situation where:
Can this section be turned around into something more positive, and
less SGI specific.
And can the problems that seem to be associated with this be
directly addressed:
1) It could be abused by competitors of Open Source, to leverage
Linux kernel work while avoiding GPL constraints on their
key code (much as happens with device drivers now, e.g. Nvidia).
2) It opens up a Pandoras box of opportunities for poor quality
(or at least inadequately tested) code compromising the stability
of the system, with attendant support nightmares. For example,
"user exit" code for IBM operating systems was one of the areas
that had the greatest difficulty adapting to Y2K.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@xxxxxxx> 1.925.600.0401
|