Re: POSIX.1 semaphores vs message queues

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Nov 9,  8:05am, Paul Goyette wrote:
} On Sun, 8 Nov 2015, Masao Uebayashi wrote:
} 
} >> I don't see the point in having options for every single system call or
} >> the like. At best, it is a form of modularity masturbation and at worst,
} >> it is asking for difficult to analyze bugs when someone actually insists
} >> on removing them.
} >
} > You need subsystem dependency information for decent initialization
} > (a.k.a. kctors) ordering anyway.
} >
} > I also think that creating (practically useless) reduced kernel helps
} > unit-testing.
} 
} I'm not sure about helping unit testing, but it definitely helps to
} keep the code organized.
} 
} If any bugs do arise, they should be fixed, just like any other bugs.
} One might argue that having this code as optional/removeable offers
} new opportunities for finding bugs which affect other modules and/or
} the loadable module mechanisms, and exposing and fixing these bugs
} is beneficial to the project as a whole.
} 
} So far, the only objections seem to be:
} 
}  	* semaphores are pretty common, just about everyone will use
}  	  them, so there's no reason for them to be optional or
}  	  removeable
} 
}  	* the semaphore code is fairly small, and having it as an
}  	  optional/removable module doesn't gain very much, and
}  	  isn't worth the effort.
} 
} Well, both EXEC_SCRIPT and COREDUMP are modularized, and they _are_ 
} optional.  I would contend that EXEC_SCRIPT is much more widely used
} than the semaphore code, and much more critical to operation of nearly
} every NetBSD kernel, yet we still build them as optional/removable
} modules.  (And yes, I actually run my "production" machine with these
} two modules - as well as AOI, MQUEUE, and EXEC_ELF64! - removed from
} the baseline kernel;  they all get auto-loaded as needed.)
} 
} Both EXEC_SCRIPT and COREDUMP are also much smaller than the ksem code;
} these two optional/removeable modules together add up to just about
} the size of a SEMAPHORE module.  (On amd64 we have exec_script weighing
} in at 1285 bytes and coredump at 3895 bytes, while ksem tips the scales
} at 5186 bytes).  There are numerous other modules which are similar in
} size to the SEMAPHORE module.
} 
} So, unless there are strenuous objections, I'm planning to resurrect
} the SEMAPHORE module in about a week.

     You've had objections.  It serves no purpose.

}-- End of excerpt from Paul Goyette