Hi!
On 2023-07-15 20:49, наб wrote:
> FreeBSD, OpenBSD, and Linux (/dev/ptmx) do all intialisation in open(2),
> and grantpt(3) is a no-op (that checks whether the fd is a pty, except on
> musl).
>
> The illumos gate and NetBSD do a ioctl (and, indeed, illumos-gate commit
> facf4a8d7b59fde89a8662b4f4c73a758e6c402c ("PSARC/2003/246 Filesystem
> Driven Device Naming"), which kills pt_chmod, notes that it's been
> "6464196 bfu should remove pt_chmod, obsoleted by /dev filesystem").
>
> glibc 2.33 completely kills BSD PTY support on Linux
> (Debian hasn't configured with them on any architecture since 2007:
> https://bugs.debian.org/338404
> and even earlier on some arches; they're really just trivia under
> Linux ‒ this may be better served stuffed into HISTORY as an explainer
> for the SIGCHLD thing, since regardless of the "version", the behaviour
> is well-defined and consistent).
>
> Cc: Jakub Wilk <jwilk@xxxxxxxxx>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@xxxxxxxxxxxxxxxxxx>
> ---
>> The illumos gate and NetBSD do a ioctl (and, indeed, illumos-gate commit
> paren level 1
> v
>> facf4a8d7b59fde89a8662b4f4c73a758e6c402c ("PSARC/2003/246 Filesystem
> paren level 2
> v
>> Driven Device Naming"), which kills pt_chmod, notes that it's been
> this is an in-line 2-column quote of the commit message
> (which I've misindented to 3)
> vvv
>> 6464196 bfu should remove pt_chmod, obsoleted by /dev filesystem).
>
> So it works by "it doesn't", it's psycho indent, probably related to
> Date: Mon Jun 19 02:01:46 2023 +0200
> I turned the blockquote into a ""-quote, which should make more sense.
Makes sense. Or should I say it doesn't... :-)
Thanks! Just a minor comment below.
>
> Numberised open() and grantpt().
>
> man3/grantpt.3 | 18 ++++++++----------
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/man3/grantpt.3 b/man3/grantpt.3
> index a19172a3e..e3d4e4aaa 100644
> --- a/man3/grantpt.3
> +++ b/man3/grantpt.3
> @@ -84,17 +84,15 @@ .SH ATTRIBUTES
> .ad
> .sp 1
> .SH VERSIONS
> -Many systems implement this function via a set-user-ID helper binary
> +Historical systems implemented this function via a set-user-ID helper binary
> called "pt_chown".
> -On Linux systems with a devpts filesystem (present since Linux 2.2),
> -the kernel normally sets the correct ownership and permissions
> -for the pseudoterminal slave when the master is opened
> -.RB ( posix_openpt (3)),
> -so that nothing must be done by
> -.BR grantpt ().
> -Thus, no such helper binary is required
> -(and indeed it is configured to be absent during the
> -glibc build that is typical on many systems).
> +glibc on Linux before glibc 2.33 could do so as well,
> +in order to support configurations with only BSD pseudoterminals;
> +this support has been removed.
> +On modern systems this is either a no-op\[em]with
> +permissions configured on pty allocation,
> +as is the case on Linux\[em]or an
> +.BR ioctl (2).
This still didn't address the following comment of mine to v2:
On 2023-07-08 17:54, Alejandro Colomar wrote:
>> +in order to support configurations with only BSD pseudoterminals;
>> +this support has been removed.
>> +On modern systems this is either a no-op\[em]with
> \[em] clearly breaks/interrupts a clause or phrase.
> Semantic newlines should apply here --I guess that you probably put the
> two words together to not add an extra space, but I do like that space
> (and I know this may be controversial)--.
>
> Cheers,
> Alex
>
>> +permissions configured on pty allocation,
>> +as is the case on Linux\[em]or an
>> +.BR ioctl (2).
>> .SH STANDARDS
I wonder if you confirm your intention to have it this way, or if you
just missed that comment. Please document your intention. I don't feel
strong about it. It's just that using '--' next to the "parenthesised"
part and with a space at the other side makes it more straightforward to
parse, even if some Powers might be against it. It also fits better with
semantic newlines.
Branden, any opinion on this?
Cheers,
Alex
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
