There's a report of touchpad breakage that traced back to this commit: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289353

Committed with a few more cleanups.

In D38047#1177323, @des wrote:

Was this superseded by later reviews?

Looks mostly sane and the issues I remember flagging before have been corrected.

LGTM

Closing this, continuation in https://reviews.freebsd.org/D51568

Was this superseded by later reviews?

May we omit the prompt characters in the examples section of tcopy.1 for copy paste?

i'm not a simh-tapefile expert, so I've not verified that this implements that standard.
I do like the cleanup generally and have only a few questions / suggestions.

rebasing with minor additional changes before I begin the work to split this up

Interim PR changes while I work on splitting this up to different sub PRs. Don't want my work lost

I think the cycle detection patch is fine and should be committed on its own. If you send me (markj@freebsd.org) a patch with that piece of the change, I'll commit it.

Possible to get some eyes on this and see if we can get this across?

With many apologies for the delay, this is now sent.

In D46472#1061633, @sobomax wrote:

Undo damage done in c6d3d601c96f, which shifted failure to allocate large buffer to pipe_create() from pipe_write().

The need for such allocation by itself is questionable since absolute majority of users write less than dozen bytes and out of that majority most write exactly 0.

In D46472#1062498, @kib wrote:

This undoes the fix done in c6d3d601c96f5836df76847, which hurts real users.

Whatever band-aids you would try to put on top of the issue, it cannot solve the fundamental inability of computers to allocate infinite amount of resources. Perhaps, the only clean way to isolate one user from mal-acting neighbor is to implement per-uid pipe limit (RLIMIT_PIPEN), which is not that useless IMO.

This undoes the fix done in c6d3d601c96f5836df76847, which hurts real users.

In D45056#1061365, @allanjude wrote:

In D45056#1058221, @david_crossfamilyweb.com wrote:

How should I submit this to you for the path; I have never used git format-patch before; I tried doing git format-patch main and it generated 21 files (since I have 21 commits). Manpage suggests I email this to you? But it seems rude to just blast you with 21 patches; and I don't know your email.

David, did you still need more help here?

Undo damage done in c6d3d601c96f, which shifted failure to allocate large buffer to pipe_create() from pipe_write().

In D45056#1058221, @david_crossfamilyweb.com wrote:

How should I submit this to you for the path; I have never used git format-patch before; I tried doing git format-patch main and it generated 21 files (since I have 21 commits). Manpage suggests I email this to you? But it seems rude to just blast you with 21 patches; and I don't know your email.

Make harmless.

P.S. I think this whole new "behaviour" is the (unintended?) consequence of the c6d3d601c, which shifted the failure to allocate buffer from the write() call into the popen() call. Which added the whole new failure mode into fork()->exec() mechanism that can be easily triggered by anybody. So no new process can be created even if the new process and/or its parent would never want to write or read to the pipe in a normal conditions.

@kib thanks for the input. Beefed up telemetry, as suggested, removed the reference to tuning. Added option to kill the repeated offender (or an innocent bystander ;-)