RFD: Rework/extending functionality of mdev

[Laurent Bercot]

On 15/03/2015 22:47, James Bowlin wrote:
>>>> kernel guaranties not only atomicity for write operations, but
>>>> also for read operations (not in POSIX, AFAIK).
>>>>                            ^^^^^^^^^^^^^^^^^^^^
>
> The post you were replying to already admitted that multiple fifo
> readers was not POSIX compliant.
>
> 1) Why argue over something that has already been admitted?

  I was not arguing over that.

  What you quoted is about the guarantee of *atomicity*. Yeah,
guarantee of atomicity is important, but what's even more important
is who's actually going to read the data. All readers ? One reader ?
A subset of all readers selected according to their PID, the uptime
of the system and the phase of the moon ? It is not specified, neither
in POSIX nor anywhere else, and until it is, you *cannot* write
software that assumes one of those behaviours. That is why a
"fifo superserver" does not exist, and why it should remain so.


>     It does not bolster your argument and it does not put in you
>     a good light.

  I am doing my best in this giant waste of time of a bikeshedding
thread to ignore personal attacks; constant assumptions and
innuendos that I don't know what I'm talking about; minor errors
that should in principle be corrected but that would 1. distract us
even more from the subject and 2. rustle some jimmies; and the
failings of others to understand the simple points I am making
and what I am exactly answering to. I'm attempting to remain
strictly focused on the main technical aspects of the question,
which is the only thing we should be discussing here.
  Please don't make it any more difficult than it already is.


> 2) While violating POSIX is usually not a good idea, it is well
>    known that POSIX is woefully incomplete and there are
>    long-standing extensions to POSIX on all real-world system
>    including busybox.  I propose an extension to Godwin's law
>    that if someone objects to something because it relies on a
>    long-standing extension to a POSIX standard then that person
>    automatically loses the argument.

  Of course every system has its own extensions to POSIX. It does
not mean that it's a good idea to rely on them when it can be
avoided. It also does not mean that "reader selection in the case
of multiple pipes" is a documented extension.

  Your argument can be used to justify things as bashisms (because
everyone uses bash, /bin/sh is so old and incomplete), GNUisms
(what ? "/bin/cp -a" is not standard ? but everyone has GNU
coreutils !), and other cases of gratuitous disregard for
portability.

  In my experience - but I have no solid evidence to back it up,
so you may very well ignore that - people who take POSIX lightly
rarely are good designers or programmers, and non-portable software
also tends to be badly written.

  When you're close to "proprietary" system interfaces, such as
system-specific filesystems, ioctls, /dev organization and so on,
of course you have to depend on more than POSIX. But when you're
using generic APIs, for instance pipes - example chosen totally at
random - there's no good reason to deviate from POSIX.


> I think your suggestions have been very valuable and your
> proposals may well represent a superior solution technically.
> I am a little frustrated by the silly arguments because I am
> so looking forward to seeing the fruition of your ideas.

  Among all the participants in the discussion: Isaac has produced
pseudo-code, Natanael has produced a proof of concept, and I have
produced real, working, available code. And all the rest is mainly
noise. Am I really the one you should be frustrated at ?

-- 
  Laurent