[PATCH] grantpt.3: no-op on modern glibc and other UNIXes

[PATCH] grantpt.3: no-op on modern glibc and other UNIXes

[наб]

[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]

FreeBSD, OpenBSD, and Linux (/dev/ptmx) do all intialisation in open,
and grantpt() is a no-op (checking 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 all but 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).

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
 man3/grantpt.3 | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/man3/grantpt.3 b/man3/grantpt.3
index a19172a3e..fda2f9625 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 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 a
+.BR ioctl (2).
 .SH STANDARDS
 POSIX.1-2008.
 .SH HISTORY
-- 
2.39.2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] grantpt.3: no-op on modern glibc and other UNIXes

[Jakub Wilk]

* наб <nabijaczleweli@nabijaczleweli.xyz>, 2023-06-19 02:14:
>+as is the case on Linux\[em]or a
>+.BR ioctl (2).

s/ a/ an/

-- 
Jakub Wilk

[PATCH v2] grantpt.3: no-op on modern glibc and other UNIXes

[наб]

[-- Attachment #1: Type: text/plain, Size: 2248 bytes --]

FreeBSD, OpenBSD, and Linux (/dev/ptmx) do all intialisation in open,
and grantpt() 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 all but 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).

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
Heh, yeah. While writing I read this as "or a br ioctl" so I didn't
notice.

 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 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).
 .SH STANDARDS
 POSIX.1-2008.
 .SH HISTORY
-- 
2.39.2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2] grantpt.3: no-op on modern glibc and other UNIXes

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 3066 bytes --]

Hi!

On 6/20/23 00:11, наб wrote:
> FreeBSD, OpenBSD, and Linux (/dev/ptmx) do all intialisation in open,
> and grantpt() 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 all but trivia under

trivia or trivial?

>   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).
> 
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>

Please add Jakub.

> ---
> Heh, yeah. While writing I read this as "or a br ioctl" so I didn't
> notice.

Heh, you'll soon read "or a mr ioctl".  Hounds do be released.

> 
>   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 2.33 could do so as well,

This can be confusing:  Linux 2.33, or glibc 2.33?
As a solution, I decided to always prefix the version with the software
name, even if it felt a bit redundant sometimes.

> +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
>   POSIX.1-2008.
>   .SH HISTORY

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v3] grantpt.3: no-op on modern glibc and other UNIXes

[наб]

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

FreeBSD, OpenBSD, and Linux (/dev/ptmx) do all intialisation in open,
and grantpt() 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@jwilk.net>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
Trivia, but rephrased slightly to make it more obvious.

 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 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).
 .SH STANDARDS
 POSIX.1-2008.
 .SH HISTORY
-- 
2.39.2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3] grantpt.3: no-op on modern glibc and other UNIXes

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2657 bytes --]

On 2023-07-08 21:59, наб wrote:
> FreeBSD, OpenBSD, and Linux (/dev/ptmx) do all intialisation in open,

I guess you meant open(2).  Please be more precise about it.

> and grantpt() 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).

I can't parse the indentation of this paragraph.  How does it work?

> 
> 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@jwilk.net>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
> Trivia, but rephrased slightly to make it more obvious.

Thanks,
Alex

> 
>  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 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).
>  .SH STANDARDS
>  POSIX.1-2008.
>  .SH HISTORY

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v4] grantpt.3: no-op on modern glibc and other UNIXes

[наб]

[-- Attachment #1: Type: text/plain, Size: 2862 bytes --]

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@jwilk.net>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
> 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.

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).
 .SH STANDARDS
 POSIX.1-2008.
 .SH HISTORY
-- 
2.39.2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v4] grantpt.3: no-op on modern glibc and other UNIXes

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 4298 bytes --]

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@jwilk.net>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
>> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v5] grantpt.3: no-op on modern glibc and other UNIXes

[наб]

[-- Attachment #1: Type: text/plain, Size: 2547 bytes --]

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@jwilk.net>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
I read it but didn't really understand what you were saying, since
you're on record as a text‒text‒text liker.
You can trivially continue the lines with \c like the below, but
  "no-op, with permissions ... on Linux, or an ioctl(2)."
would probably also work just as well,
and I leave that to your editorial sensibilities.

 man3/grantpt.3 | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/man3/grantpt.3 b/man3/grantpt.3
index a19172a3e..363a7aebd 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\c
+\[em]with permissions configured on pty allotion, as is the case on Linux\[em]\c
+or an
+.BR ioctl (2).
 .SH STANDARDS
 POSIX.1-2008.
 .SH HISTORY
-- 
2.39.2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5] grantpt.3: no-op on modern glibc and other UNIXes

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 4180 bytes --]

Hi!

On 2023-07-16 13:55, наб wrote:
[...]

> I read it but didn't really understand what you were saying, since
> you're on record as a text‒text‒text liker.

In this context, I'm not sure if to read that as that being just
emphasis on me being a text liker, which is true-true-true, or if
(more likely) "text" are placeholders for random text, and you claim
that I'm on record liking no spaces between em dashes.  If it's the
latter, I believe I am not, and you might have been confused by some
of those records?  Could you point me to the records?  Maybe I had
some brain-fart and defended that at some point, but I do not like
that style personally.

The reason that I like spaces in (only) one side of em dashes --and I
also like closing em dashes even right before other punctuation-- is
to make parsing the text less complex.  I've seen cases where in a
paragraph, several em-dash asides appear, and it's hard to understand
what is the main text and what are the asides, especially when the
closing em dash of one of them is omitted.

Basically, it is something similar to why we should write punctuation
outside of quotes, unless they belong to them, so if I quote someone
who said "Hello world!", I include '!' in the quote, as it belongs to
the quote, but the ',' belongs to my text.

uri(7) has something about those rules for quotes:

   Writing a URI
       When written, URIs should be placed inside double quotes (e.g.,
       "http://www.kernel.org"), enclosed  in  angle  brackets  (e.g.,
       <http://lwn.net>),  or placed on a line by themselves.  A warn‐
       ing for those who  use  double‐quotes:  never  move  extraneous
       punctuation  (such as the period ending a sentence or the comma
       in a list) inside a URI, since this will change  the  value  of
       the  URI.   Instead, use angle brackets instead, or switch to a
       quoting system that never includes extraneous characters inside
       quotation marks.  This latter system, called the ’new’ or ’log‐
       ical’ quoting system by "Hart’s Rules" and the "Oxford  Dictio‐
       nary  for  Writers and Editors", is preferred practice in Great
       Britain and in various  European  languages.   Older  documents
       suggested  inserting the prefix "URL:" just before the URI, but
       this form has never caught on.

It's not exactly the same for em dashes, but they're both progress
towards a more logical way of punctuating text, which I like.

Cheers,
Alex


> You can trivially continue the lines with \c like the below, but
>   "no-op, with permissions ... on Linux, or an ioctl(2)."
> would probably also work just as well,
> and I leave that to your editorial sensibilities.
> 
>  man3/grantpt.3 | 18 ++++++++----------
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/man3/grantpt.3 b/man3/grantpt.3
> index a19172a3e..363a7aebd 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\c
> +\[em]with permissions configured on pty allotion, as is the case on Linux\[em]\c
> +or an
> +.BR ioctl (2).
>  .SH STANDARDS
>  POSIX.1-2008.
>  .SH HISTORY

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5] grantpt.3: no-op on modern glibc and other UNIXes

[наб]

[-- Attachment #1: Type: text/plain, Size: 6472 bytes --]

Hi!

On Sun, Jul 16, 2023 at 03:46:10PM +0200, Alejandro Colomar wrote:
> On 2023-07-16 13:55, наб wrote:
> [...]
> > I read it but didn't really understand what you were saying, since
> > you're on record as a text‒text‒text liker.
> In this context, I'm not sure if to read that as that being just
> emphasis on me being a text liker, which is true-true-true, or if
> (more likely) "text" are placeholders for random text, and you claim
> that I'm on record liking no spaces between em dashes.  If it's the
> latter, I believe I am not, and you might have been confused by some
> of those records?  Could you point me to the records?
I think you've said it to me before but I can't strictly find the mail
(but I'd hopefully blame that on my mail searching).

> Maybe I had
> some brain-fart and defended that at some point, but I do not like
> that style personally.
Neither do I but I, as usual, consulted the corpus, and it said
  $ git grep -F '\[em]' | grep -Fe '\[em] ' -e '\[em] ' -c
to around 160/16 vs -cv.

Thus, I did what the corpus says.

> Basically, it is something similar to why we should write punctuation
> outside of quotes, unless they belong to them, so if I quote someone
> who said "Hello world!", I include '!' in the quote, as it belongs to
> the quote, but the ',' belongs to my text.
This is known (unfairly-)derisively as "programmer punctuation".

> The reason that I like spaces in (only) one side of em dashes --and I
> also like closing em dashes even right before other punctuation-- is
> to make parsing the text less complex.  I've seen cases where in a
> paragraph, several em-dash asides appear, and it's hard to understand
> what is the main text and what are the asides, especially when the
> closing em dash of one of them is omitted.
The corpus sayeth:
  $ git grep -F '\[em]' | grep -e '\\\[em\] ' -e ' \\\[em\]'  -e ':\\\[em\]' -e '\\\[em\]$' | grep -v @
  man2/futex.2:.IR "futex word" \[em]whose
  man2/get_mempolicy.2:.IR nodemask \[em]that
  man2/ioctl_iflags.2:.IR "inode flags" \[em]attributes
  man2/madvise.2:\[em]including tmpfs (see
  man2/madvise.2:.BR tmpfs (2))\[em]
  man2/mbind.2:.BR MAP_ANONYMOUS \[em]or
  man2/perf_event_open.2:\[em]added, divided (to get ratios), and so on\[em]
  man2/uname.2:\[em] this is the largest value likely to be encountered in the wild.
  man3/grantpt.3:\[em]with permissions configured on pty allotion, as is the case on Linux\[em]\c
  man3type/stat.3type:.RI fields\[em] st_atime ,
  man3type/stat.3type:.IR st_ctime \[em]typed
  man4/intro.4:/dev/* \[em] device files
  man4/st.4:.SS MTIOCTOP \[em] perform a tape operation
  man4/st.4:.SS MTIOCGET \[em] get status
  man4/st.4:.SS MTIOCPOS \[em] get tape position
  man7/man.7:.\" .IP \[em] 3m
  man7/man.7:.\" .IP \[em]
  man7/man.7:.\" .IP \[em]
  man7/man.7:.\" .IP \[em]
  man7/path_resolution.7:the process \[em] or in the case of
  man7/tcp.7:Use this option with care \[em] it makes TCP less tolerant to routing
  man7/unicode.7:Information technology \[em] Universal Multiple-Octet Coded Character
  man7/unicode.7:Set (UCS) \[em] Part 1: Architecture and Basic Multilingual Plane.
  man7/x25.7:Message boundaries are preserved \[em] a
of which these use ‒s as interjective commas:
  man2/futex.2:.IR "futex word" \[em]whose
  man2/madvise.2:\[em]including tmpfs (see
  man2/madvise.2:.BR tmpfs (2))\[em]
  man2/mbind.2:.BR MAP_ANONYMOUS \[em]or
  man2/perf_event_open.2:\[em]added, divided (to get ratios), and so on\[em]
  man3/grantpt.3:\[em]with permissions configured on pty allotion, as is the case on Linux\[em]\c
(whoops allotion, should be allocation)
  man3type/stat.3type:.RI fields\[em] st_atime ,
  man3type/stat.3type:.IR st_ctime \[em]typed
of which these have spacing around the outside:
  man2/madvise.2:\[em]including tmpfs (see
  man2/madvise.2:.BR tmpfs (2))\[em]
  man2/perf_event_open.2:\[em]added, divided (to get ratios), and so on\[em]

This is, I'm pretty sure, the first time I've encountered this style,
and it kinda looks like a formatting error to me.

v6 with
  op —with permissions configured on pty allocation, as is the case on Linux— or an ioctl(2).
scissored below.
-- >8 --
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@jwilk.net>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
 man3/grantpt.3 | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/man3/grantpt.3 b/man3/grantpt.3
index a19172a3e..3c753da03 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).
 .SH STANDARDS
 POSIX.1-2008.
 .SH HISTORY
-- 
2.39.2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5] grantpt.3: no-op on modern glibc and other UNIXes

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 7375 bytes --]

Hi!

On 2023-07-16 16:52, наб wrote:
> Hi!
> 
> On Sun, Jul 16, 2023 at 03:46:10PM +0200, Alejandro Colomar wrote:
>> On 2023-07-16 13:55, наб wrote:
>> [...]
>>> I read it but didn't really understand what you were saying, since
>>> you're on record as a text‒text‒text liker.
>> In this context, I'm not sure if to read that as that being just
>> emphasis on me being a text liker, which is true-true-true, or if
>> (more likely) "text" are placeholders for random text, and you claim
>> that I'm on record liking no spaces between em dashes.  If it's the
>> latter, I believe I am not, and you might have been confused by some
>> of those records?  Could you point me to the records?
> I think you've said it to me before but I can't strictly find the mail
> (but I'd hopefully blame that on my mail searching).
> 
>> Maybe I had
>> some brain-fart and defended that at some point, but I do not like
>> that style personally.
> Neither do I but I, as usual, consulted the corpus, and it said
>   $ git grep -F '\[em]' | grep -Fe '\[em] ' -e '\[em] ' -c
> to around 160/16 vs -cv.
> 
> Thus, I did what the corpus says.
> 
>> Basically, it is something similar to why we should write punctuation
>> outside of quotes, unless they belong to them, so if I quote someone
>> who said "Hello world!", I include '!' in the quote, as it belongs to
>> the quote, but the ',' belongs to my text.
> This is known (unfairly-)derisively as "programmer punctuation".
> 
>> The reason that I like spaces in (only) one side of em dashes --and I
>> also like closing em dashes even right before other punctuation-- is
>> to make parsing the text less complex.  I've seen cases where in a
>> paragraph, several em-dash asides appear, and it's hard to understand
>> what is the main text and what are the asides, especially when the
>> closing em dash of one of them is omitted.
> The corpus sayeth:

Michael wrote most of that corpus, and that's one of the very few
points where I disagree with him.  I may have written myself some of
those, for continuity with the corpus, but I dislike it.

I may reform all of it to get rid of such cases.  Let's add it to my
TODO list:

-  'Linux v[0-9]\+'  (I see 5 cases.)
-  Logic em dashes.
-  Get rid as much as possible of \f.
-  Transform the remaining \f into \f[].
-  Split proc(5).

>   $ git grep -F '\[em]' | grep -e '\\\[em\] ' -e ' \\\[em\]'  -e ':\\\[em\]' -e '\\\[em\]$' | grep -v @
>   man2/futex.2:.IR "futex word" \[em]whose
>   man2/get_mempolicy.2:.IR nodemask \[em]that
>   man2/ioctl_iflags.2:.IR "inode flags" \[em]attributes
>   man2/madvise.2:\[em]including tmpfs (see
>   man2/madvise.2:.BR tmpfs (2))\[em]
>   man2/mbind.2:.BR MAP_ANONYMOUS \[em]or
>   man2/perf_event_open.2:\[em]added, divided (to get ratios), and so on\[em]
>   man2/uname.2:\[em] this is the largest value likely to be encountered in the wild.
>   man3/grantpt.3:\[em]with permissions configured on pty allotion, as is the case on Linux\[em]\c
>   man3type/stat.3type:.RI fields\[em] st_atime ,
>   man3type/stat.3type:.IR st_ctime \[em]typed
>   man4/intro.4:/dev/* \[em] device files
>   man4/st.4:.SS MTIOCTOP \[em] perform a tape operation
>   man4/st.4:.SS MTIOCGET \[em] get status
>   man4/st.4:.SS MTIOCPOS \[em] get tape position
>   man7/man.7:.\" .IP \[em] 3m
>   man7/man.7:.\" .IP \[em]
>   man7/man.7:.\" .IP \[em]
>   man7/man.7:.\" .IP \[em]
>   man7/path_resolution.7:the process \[em] or in the case of
>   man7/tcp.7:Use this option with care \[em] it makes TCP less tolerant to routing
>   man7/unicode.7:Information technology \[em] Universal Multiple-Octet Coded Character
>   man7/unicode.7:Set (UCS) \[em] Part 1: Architecture and Basic Multilingual Plane.
>   man7/x25.7:Message boundaries are preserved \[em] a
> of which these use ‒s as interjective commas:
>   man2/futex.2:.IR "futex word" \[em]whose
>   man2/madvise.2:\[em]including tmpfs (see
>   man2/madvise.2:.BR tmpfs (2))\[em]
>   man2/mbind.2:.BR MAP_ANONYMOUS \[em]or
>   man2/perf_event_open.2:\[em]added, divided (to get ratios), and so on\[em]
>   man3/grantpt.3:\[em]with permissions configured on pty allotion, as is the case on Linux\[em]\c
> (whoops allotion, should be allocation)

nice catch :)

>   man3type/stat.3type:.RI fields\[em] st_atime ,
>   man3type/stat.3type:.IR st_ctime \[em]typed
> of which these have spacing around the outside:
>   man2/madvise.2:\[em]including tmpfs (see
>   man2/madvise.2:.BR tmpfs (2))\[em]
>   man2/perf_event_open.2:\[em]added, divided (to get ratios), and so on\[em]
> 
> This is, I'm pretty sure, the first time I've encountered this style,
> and it kinda looks like a formatting error to me.
> 
> v6 with
>   op —with permissions configured on pty allocation, as is the case on Linux— or an ioctl(2).
> scissored below.

Thanks!  I'll review later.

Cheers,
Alex

> -- >8 --
> 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@jwilk.net>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
>  man3/grantpt.3 | 18 ++++++++----------
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/man3/grantpt.3 b/man3/grantpt.3
> index a19172a3e..3c753da03 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).
>  .SH STANDARDS
>  POSIX.1-2008.
>  .SH HISTORY

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5] grantpt.3: no-op on modern glibc and other UNIXes

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2877 bytes --]

On 2023-07-16 13:55, наб 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@jwilk.net>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
> I read it but didn't really understand what you were saying, since
> you're on record as a text‒text‒text liker.
> You can trivially continue the lines with \c like the below, but
>   "no-op, with permissions ... on Linux, or an ioctl(2)."
> would probably also work just as well,
> and I leave that to your editorial sensibilities.
> 
>  man3/grantpt.3 | 18 ++++++++----------
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/man3/grantpt.3 b/man3/grantpt.3
> index a19172a3e..363a7aebd 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\c
> +\[em]with permissions configured on pty allotion, as is the case on Linux\[em]\c
> +or an
> +.BR ioctl (2).

I'm thinking that this paragraph deserves to be HISTORYzised, doesn't it?

>  .SH STANDARDS
>  POSIX.1-2008.
>  .SH HISTORY

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v6] grantpt.3: no-op on modern glibc and other UNIXes, HISTORYise

[наб]

[-- Attachment #1: Type: text/plain, Size: 3140 bytes --]

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).

There really aren't many cohesive "versions" of this ‒ indeed, so long
as grantpt(3) exists it behaves precisely as described here ‒
inasmuch as different systems, historically, had different ptys,
and thus different implementations. These are all but trivia.

Cc: Jakub Wilk <jwilk@jwilk.net>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
I originally thought to do so, but decided against it because I'm not
substantially changing this paragraph and it's already in VERSIONS...
Moved with rationale added.

Also, administriva-wise, git pull tells me
  [PATCH 1/2] statfs.2: unshade as deprecated, but direct to statvfs(3)
with msgid
  <b4b871ffdf8f764ffd6c25039f3944b08748bd3e.1687553930.git.nabijaczleweli@nabijaczleweli.xyz>
is the last outstanding patch I have rn, sans this one.

 man3/grantpt.3 | 22 ++++++++++------------
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/man3/grantpt.3 b/man3/grantpt.3
index a19172a3e..949f70de9 100644
--- a/man3/grantpt.3
+++ b/man3/grantpt.3
@@ -83,18 +83,6 @@ .SH ATTRIBUTES
 .hy
 .ad
 .sp 1
-.SH VERSIONS
-Many systems implement 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).
 .SH STANDARDS
 POSIX.1-2008.
 .SH HISTORY
@@ -103,6 +91,16 @@ .SH HISTORY
 .PP
 This is part of the UNIX 98 pseudoterminal support, see
 .BR pts (4).
+.PP
+Historical systems implemented this function via a set-user-ID helper binary
+called "pt_chown".
+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).
 .SH SEE ALSO
 .BR open (2),
 .BR posix_openpt (3),
-- 
2.39.2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v6] grantpt.3: no-op on modern glibc and other UNIXes, HISTORYise

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 4054 bytes --]

Subject: grantpt.3: no-op on modern glibc and other UNIXes, HISTORYise

Hi!

Please use Uppercase after the ':'.  Rationale: it should (usually) be an
English sentence, following conventional rules (except for the trailing
period, which we remove).

On 2023-07-18 01:31, наб 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).
> 
> There really aren't many cohesive "versions" of this ‒ indeed, so long
> as grantpt(3) exists it behaves precisely as described here ‒
> inasmuch as different systems, historically, had different ptys,
> and thus different implementations. These are all but trivia.

Please use two spaces after period.  ;)

> 
> Cc: Jakub Wilk <jwilk@jwilk.net>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
> I originally thought to do so, but decided against it because I'm not
> substantially changing this paragraph and it's already in VERSIONS...
> Moved with rationale added.

Thanks.  Patch applied.
> 
> Also, administriva-wise, git pull tells me
>   [PATCH 1/2] statfs.2: unshade as deprecated, but direct to statvfs(3)
> with msgid
>   <b4b871ffdf8f764ffd6c25039f3944b08748bd3e.1687553930.git.nabijaczleweli@nabijaczleweli.xyz>
> is the last outstanding patch I have rn, sans this one.

I was waiting for you to send an v2 with the fs and inode corrections
suggested by Tom Schwindl.  Is that correct?

It's a bit weird, because IIRC, I had written to confirm what Tom said,
with pointers to man-pages(7), but now I can't find it.  I'll write
(again?) now.

Cheers,
Alex

> 
>  man3/grantpt.3 | 22 ++++++++++------------
>  1 file changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/man3/grantpt.3 b/man3/grantpt.3
> index a19172a3e..949f70de9 100644
> --- a/man3/grantpt.3
> +++ b/man3/grantpt.3
> @@ -83,18 +83,6 @@ .SH ATTRIBUTES
>  .hy
>  .ad
>  .sp 1
> -.SH VERSIONS
> -Many systems implement 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).
>  .SH STANDARDS
>  POSIX.1-2008.
>  .SH HISTORY
> @@ -103,6 +91,16 @@ .SH HISTORY
>  .PP
>  This is part of the UNIX 98 pseudoterminal support, see
>  .BR pts (4).
> +.PP
> +Historical systems implemented this function via a set-user-ID helper binary
> +called "pt_chown".
> +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).
>  .SH SEE ALSO
>  .BR open (2),
>  .BR posix_openpt (3),

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v6] grantpt.3: no-op on modern glibc and other UNIXes, HISTORYise

[наб]

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

On Tue, Jul 18, 2023 at 01:42:08PM +0200, Alejandro Colomar wrote:
> On 2023-07-18 01:31, наб wrote:
> > Also, administriva-wise, git pull tells me
> >   [PATCH 1/2] statfs.2: unshade as deprecated, but direct to statvfs(3)
> > with msgid
> >   <b4b871ffdf8f764ffd6c25039f3944b08748bd3e.1687553930.git.nabijaczleweli@nabijaczleweli.xyz>
> > is the last outstanding patch I have rn, sans this one.
> I was waiting for you to send an v2 with the fs and inode corrections
> suggested by Tom Schwindl.  Is that correct?
You applied 2/2 but I got no responses for 1/2.
Scissoring a rebased 1/2 below.

Update-wise: musl@ told me they basically agree and will apply it
when glibc does, and I got the glibc first round of reviews and the
hurd half stamped, but it's now entered the "resend every week to
no response" stage that all glibc patches go through.

When those land I'll probably re-shade the declarations, turn the
paragraph into "use the standard statvfs(3) interface instead, but
see VERSIONS if using f_type" and extract the magicks to, like,
fs-magic(7) or whatever.

Best,
-- >8 --
Date: Fri, 23 Jun 2023 22:49:22 +0200
Subject: [PATCH v2 1/2] statfs.2: Unshade as deprecated, but direct to statvfs(3)

Link: https://lore.kernel.org/linux-man/f54kudgblgk643u32tb6at4cd3kkzha6hslahv24szs4raroaz@ogivjbfdaqtb/t/#u
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
 man2/statfs.2 | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/man2/statfs.2 b/man2/statfs.2
index 0496ab6c9..307a29b3a 100644
--- a/man2/statfs.2
+++ b/man2/statfs.2
@@ -15,9 +15,15 @@ .SH SYNOPSIS
 .nf
 .BR "#include <sys/vfs.h>    " "/* or <sys/statfs.h> */"
 .PP
-.BI "[[deprecated]] int statfs(const char *" path ", struct statfs *" buf );
-.BI "[[deprecated]] int fstatfs(int " fd ", struct statfs *" buf );
+.BI "int statfs(const char *" path ", struct statfs *" buf );
+.BI "int fstatfs(int " fd ", struct statfs *" buf );
 .fi
+.PP
+Unless you need the
+.I f_type
+field, you should use the standard
+.BR statvfs (3)
+interface instead.
 .SH DESCRIPTION
 The
 .BR statfs ()
-- 
2.39.2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v6] grantpt.3: no-op on modern glibc and other UNIXes, HISTORYise

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2464 bytes --]

On 2023-07-18 17:07, наб wrote:
> On Tue, Jul 18, 2023 at 01:42:08PM +0200, Alejandro Colomar wrote:
>> On 2023-07-18 01:31, наб wrote:
>>> Also, administriva-wise, git pull tells me
>>>   [PATCH 1/2] statfs.2: unshade as deprecated, but direct to statvfs(3)
>>> with msgid
>>>   <b4b871ffdf8f764ffd6c25039f3944b08748bd3e.1687553930.git.nabijaczleweli@nabijaczleweli.xyz>
>>> is the last outstanding patch I have rn, sans this one.
>> I was waiting for you to send an v2 with the fs and inode corrections
>> suggested by Tom Schwindl.  Is that correct?
> You applied 2/2 but I got no responses for 1/2.
> Scissoring a rebased 1/2 below.
> 
> Update-wise: musl@ told me they basically agree and will apply it
> when glibc does, and I got the glibc first round of reviews and the
> hurd half stamped, but it's now entered the "resend every week to
> no response" stage that all glibc patches go through.
> 
> When those land I'll probably re-shade the declarations, turn the
> paragraph into "use the standard statvfs(3) interface instead, but
> see VERSIONS if using f_type" and extract the magicks to, like,
> fs-magic(7) or whatever.

Ok.  Thanks!

> 
> Best,
> -- >8 --
> Date: Fri, 23 Jun 2023 22:49:22 +0200
> Subject: [PATCH v2 1/2] statfs.2: Unshade as deprecated, but direct to statvfs(3)
> 
> Link: https://lore.kernel.org/linux-man/f54kudgblgk643u32tb6at4cd3kkzha6hslahv24szs4raroaz@ogivjbfdaqtb/t/#u
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>

Patch applied.

Cheers,
Alex

> ---
>  man2/statfs.2 | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/man2/statfs.2 b/man2/statfs.2
> index 0496ab6c9..307a29b3a 100644
> --- a/man2/statfs.2
> +++ b/man2/statfs.2
> @@ -15,9 +15,15 @@ .SH SYNOPSIS
>  .nf
>  .BR "#include <sys/vfs.h>    " "/* or <sys/statfs.h> */"
>  .PP
> -.BI "[[deprecated]] int statfs(const char *" path ", struct statfs *" buf );
> -.BI "[[deprecated]] int fstatfs(int " fd ", struct statfs *" buf );
> +.BI "int statfs(const char *" path ", struct statfs *" buf );
> +.BI "int fstatfs(int " fd ", struct statfs *" buf );
>  .fi
> +.PP
> +Unless you need the
> +.I f_type
> +field, you should use the standard
> +.BR statvfs (3)
> +interface instead.
>  .SH DESCRIPTION
>  The
>  .BR statfs ()

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]