Re: POSIX.1 semaphores vs message queues

[Paul Goyette <paul%vps1.whooppee.com@localhost>]

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.




+------------------+--------------------------+-------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org  |
+------------------+--------------------------+-------------------------+