Re: POSIX.1 semaphores vs message queues

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

One final attempt to summarize the objections that have been made:

1. There's no benefit

   Perhaps the benefit is minimal, but it gives people an option to
   reduce the size of their kernel if they don't need semaphores.
   Based on the lack of wide-spread discussion, I would venture to
   guess that the number of people who would avail themselves of this
   option is very small.

2. It's not worth the effort

   The value of the effort should be established by the person who
   is expending the effort.  That would be me.  The effort is not
   large, and I'm quite comfortable with it.

3. Some of the examples given, for which this effort would represent
   consistency, are in fact bugs. (cf EXEC_ELFxx, EXEC_SCRIPT, and
   COREDUMP).

   I don't see anyone racing to file PRs or to change the examples
   to be non-optional.  And in any case, this would seem to be at odds
   with the Sept 20, 2011 "core's decision on modular kernels" which
   stated

	- A port's MODULAR kernel may lack many built-in features ...
	  all features that are necessary for the standard MODULAR
	  kernel to boot and work reasonably must be built-in.  This
	  includes:
	  ...
	    * exec support for the native ELF format, and for scripts
	  ...
	  Users or developers may of course comment out relevant lines
	  if they want to load these items as modules.

   As I read that announcement from core, it was explicitly desired
   that even these critical-to-work-reasonably features should be
   capable of being modularized, in case "... if they want to load
   these items as modules."  (And one might reasonably conclude that
   the original removal of optional-ability of the semaphore code
   actually contravenes the statement/directive from core.)

   (The entire message from core is available in the mail archives
   at [1].)

4. There's no need to make semaphores optional.  Making them optional
   just because you can serves no purpose.

   There was also no need to make them non-optional three-plus years
   ago, yet that change was made.  As far as I can tell, it was made
   with a lot less notice and discussion than my proposal to resurrect
   the "optional-ability" of the semaphore code.  (If there _was_ any
   discussion at that time, please provide a reference/pointer/URL so
   I can review it.)

   (The core announcement, partly quoted above, might also be relevant
   here...)

The changes being proposed are non-intrusive, and impact existing
users only trivially:

* Kernels with embedded configuration text will be marginally larger,
  to include one extra text line.  The in-memory footprint of all
  kernels will be unchanged.

* The amount of disk space occupied by a 'build.sh release' will be
  marginally larger, to accomodate one additional directory entry
  and one extra file modules/ksem/ksem.kmod (total of approximately
  14kb on amd64).

* The on-disk footprint of an installed system would also increase by
  similar amounts.  (Some architectures may have multiple /stand/xxx
  directories, such as amd64 and amd64-xen, so the amount might be
  doubled, from 14kb to 28kb.)

* Build times for 'build.sh modules' or 'build.sh release' will also
  increase slightly, to compile and link the additional module.

* There would be no change in the functioning of existing kernels which
  do not specifically delete the built-in copy of the semaphore code.
  Without any explicit changes, the code will still be built-in and will
  continue operate exactly as it does today.


I've not yet decided whether I'm going to commit these changes.  There
simply hasn't been a wide-enough discussion to convince me either way,
and I doubt that I'd get any pleasure or enjoyment from - to quote
Joerg's puerile metaphor - any associated "modularity masturbation".

I suspect that there are very few people who are actually using modular
load-code-when-needed kernels - the number is probably in the single-
or low-double-digit range at most.  Without a population that would be
affected by (or otherwise care about) the proposed changes, a more wide-
spread discussion is unlikely.


[1] https://mail-index.netbsd.org/tech-kern/2011/09/21/msg011516.html



On Mon, 9 Nov 2015, Paul Goyette wrote:

> On Mon, 9 Nov 2015, Joerg Sonnenberger wrote:
>
> > On Mon, Nov 09, 2015 at 08:05:43AM +0800, Paul Goyette wrote:
> > > Well, both EXEC_SCRIPT and COREDUMP are modularized, and they _are_
> > > optional.
> >
> > See part about modularity masturbation. Making things optional for the
> > sake of making them optional is just as wrong.
> >
> > > 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.
> >
> > Add in the page alignment and the cost becomes even larger. There is
> > nothing to be gained.
>
> The gain is flexibility, for those who may want it.  And possibly
> finding (and eventually fixing) latent bugs, either in the semaphore
> code itself or in the module system, which can be exposed by making
> the code optional and loadable.
>
> We also gain consistency with existing practice, evidenced by the
> various examples I've cited.
>
> There is nothing to be lost for anyone who doesn't explicitly remove
> the semaphore code from their kernel via 'no options'.
>
>
>
> +------------------+--------------------------+-------------------------+
> | 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  |
> +------------------+--------------------------+-------------------------+

+------------------+--------------------------+-------------------------+
| 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  |
+------------------+--------------------------+-------------------------+