[PATCH] mount_setattr.2: Update supported file-systems

[PATCH] mount_setattr.2: Update supported file-systems

[Rodrigo Campos]

Let's update the list with the last file-systems that added support.

You can easily verify this by "git grep FS_ALLOW_IDMAP" on the given Linux
version to see that the fs is listed and then checkout the previous Linux
version to see that it is not listed, therefore it was added in that version.

Signed-off-by: Rodrigo Campos <rodrigo@sdfg.com.ar>
---

I've took the liberty of adding hugetlbfs that was merged in Linux 6.9-rc1 but there is still no
final release of 6.9. Please feel free to drop that if you prefer to wait for the final release to
include it.


Best,
Rodrigo

---
 man2/mount_setattr.2 | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/man2/mount_setattr.2 b/man2/mount_setattr.2
index 3b70dcd97..f4bbc088b 100644
--- a/man2/mount_setattr.2
+++ b/man2/mount_setattr.2
@@ -667,6 +667,18 @@ Currently, the following filesystems support ID-mapped mounts:
 .IP \[bu]
 .B overlayfs
 (ID-mapped lower and upper layers supported since Linux 5.19)
+.IP \[bu]
+.B squashfs
+(since Linux 6.2)
+.IP \[bu]
+.B tmpfs
+(since Linux 6.3)
+.IP \[bu]
+.B cephfs
+(since Linux 6.7)
+.IP \[bu]
+.B hugetlbfs
+(since Linux 6.9)
 .PD
 .RE
 .IP \[bu]
-- 
2.43.0

Re: [PATCH] mount_setattr.2: Update supported file-systems

[Alejandro Colomar]

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

Hi Rodrigo,

On Tue, Apr 09, 2024 at 03:10:46PM +0100, Rodrigo Campos wrote:
> Let's update the list with the last file-systems that added support.
> 
> You can easily verify this by "git grep FS_ALLOW_IDMAP" on the given Linux
> version to see that the fs is listed and then checkout the previous Linux
> version to see that it is not listed, therefore it was added in that version.

You could add the following to the commit message:

$ diff -w -U0 \
	<(git grep FS_ALLOW_IDMAP v6.8 | sed 's/^v6.8://') \
	<(git grep FS_ALLOW_IDMAP v6.9-rc4 | sed 's/^v6.9-rc4://') \
| tail -n+4;
+fs/hugetlbfs/inode.c:	.fs_flags               = FS_ALLOW_IDMAP,

$ diff -w -U0 \
	<(git grep FS_ALLOW_IDMAP v6.6 | sed 's/^v6.6://') \
	<(git grep FS_ALLOW_IDMAP v6.7 | sed 's/^v6.7://') \
| tail -n+4;
+fs/ceph/super.c:	.fs_flags	= FS_RENAME_DOES_D_MOVE | FS_ALLOW_IDMAP,
$ diff -w -U0 \
	<(git grep FS_ALLOW_IDMAP v6.2 | sed 's/^v6.2://') \
	<(git grep FS_ALLOW_IDMAP v6.3 | sed 's/^v6.3://') \
| tail -n+4;
+mm/shmem.c:	.fs_flags	= FS_USERNS_MOUNT | FS_ALLOW_IDMAP,
$ diff -w -U0 \
	<(git grep FS_ALLOW_IDMAP v6.1 | sed 's/^v6.1://') \
	<(git grep FS_ALLOW_IDMAP v6.2 | sed 's/^v6.2://') \
| tail -n+4;
+fs/squashfs/super.c:	.fs_flags = FS_REQUIRES_DEV | FS_ALLOW_IDMAP,


> 
> Signed-off-by: Rodrigo Campos <rodrigo@sdfg.com.ar>
> ---
> 
> I've took the liberty of adding hugetlbfs that was merged in Linux 6.9-rc1 but there is still no
> final release of 6.9. Please feel free to drop that if you prefer to wait for the final release to
> include it.

Are you confident that it will be in 6.9?  If so, I don't mind having it
already in the manual.

> 
> 
> Best,
> Rodrigo
> 
> ---
>  man2/mount_setattr.2 | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/man2/mount_setattr.2 b/man2/mount_setattr.2
> index 3b70dcd97..f4bbc088b 100644
> --- a/man2/mount_setattr.2
> +++ b/man2/mount_setattr.2
> @@ -667,6 +667,18 @@ Currently, the following filesystems support ID-mapped mounts:
>  .IP \[bu]
>  .B overlayfs
>  (ID-mapped lower and upper layers supported since Linux 5.19)
> +.IP \[bu]
> +.B squashfs
> +(since Linux 6.2)
> +.IP \[bu]
> +.B tmpfs
> +(since Linux 6.3)
> +.IP \[bu]
> +.B cephfs
> +(since Linux 6.7)
> +.IP \[bu]
> +.B hugetlbfs
> +(since Linux 6.9)

I checked that all of them seem to be correct.  Thanks!

Have a lovely day!
Alex

>  .PD
>  .RE
>  .IP \[bu]
> -- 
> 2.43.0
> 

-- 
<https://www.alejandro-colomar.es/>

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

Re: [PATCH] mount_setattr.2: Update supported file-systems

[Rodrigo Campos]

On 4/17/24 1:02 PM, Alejandro Colomar wrote:
> Hi Rodrigo,
> 
> On Tue, Apr 09, 2024 at 03:10:46PM +0100, Rodrigo Campos wrote:
>> Let's update the list with the last file-systems that added support.
>>
>> You can easily verify this by "git grep FS_ALLOW_IDMAP" on the given Linux
>> version to see that the fs is listed and then checkout the previous Linux
>> version to see that it is not listed, therefore it was added in that version.
> 
> You could add the following to the commit message:
> 
> $ diff -w -U0 \
> 	<(git grep FS_ALLOW_IDMAP v6.8 | sed 's/^v6.8://') \
> 	<(git grep FS_ALLOW_IDMAP v6.9-rc4 | sed 's/^v6.9-rc4://') \
> | tail -n+4;
> +fs/hugetlbfs/inode.c:	.fs_flags               = FS_ALLOW_IDMAP,
> 
> $ diff -w -U0 \
> 	<(git grep FS_ALLOW_IDMAP v6.6 | sed 's/^v6.6://') \
> 	<(git grep FS_ALLOW_IDMAP v6.7 | sed 's/^v6.7://') \
> | tail -n+4;
> +fs/ceph/super.c:	.fs_flags	= FS_RENAME_DOES_D_MOVE | FS_ALLOW_IDMAP,
> $ diff -w -U0 \
> 	<(git grep FS_ALLOW_IDMAP v6.2 | sed 's/^v6.2://') \
> 	<(git grep FS_ALLOW_IDMAP v6.3 | sed 's/^v6.3://') \
> | tail -n+4;
> +mm/shmem.c:	.fs_flags	= FS_USERNS_MOUNT | FS_ALLOW_IDMAP,
> $ diff -w -U0 \
> 	<(git grep FS_ALLOW_IDMAP v6.1 | sed 's/^v6.1://') \
> 	<(git grep FS_ALLOW_IDMAP v6.2 | sed 's/^v6.2://') \
> | tail -n+4;
> +fs/squashfs/super.c:	.fs_flags = FS_REQUIRES_DEV | FS_ALLOW_IDMAP,


Heh, nice trick. Do I need to resend for this or can you add it while 
you apply it?

>>
>> Signed-off-by: Rodrigo Campos <rodrigo@sdfg.com.ar>
>> ---
>>
>> I've took the liberty of adding hugetlbfs that was merged in Linux 6.9-rc1 but there is still no
>> final release of 6.9. Please feel free to drop that if you prefer to wait for the final release to
>> include it.
> 
> Are you confident that it will be in 6.9?  If so, I don't mind having it
> already in the manual.

Yes. It's already rc6 and there was no issue reported for this, the 
patch is quite trivial too and was in linux-next before without issues 
either.



Best,
Rodrigo

Re: [PATCH] mount_setattr.2: Update supported file-systems

[Alejandro Colomar]

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

Hi Rodrigo,

On Mon, Apr 29, 2024 at 11:19:36AM +0100, Rodrigo Campos wrote:
> On 4/17/24 1:02 PM, Alejandro Colomar wrote:
> > Hi Rodrigo,
> > 
> > On Tue, Apr 09, 2024 at 03:10:46PM +0100, Rodrigo Campos wrote:
> > > Let's update the list with the last file-systems that added support.

I've amended this: s/last/latest/

> > > You can easily verify this by "git grep FS_ALLOW_IDMAP" on the given Linux
> > > version to see that the fs is listed and then checkout the previous Linux
> > > version to see that it is not listed, therefore it was added in that version.
> > 
> > You could add the following to the commit message:
> > 
> > $ diff -w -U0 \
> > 	<(git grep FS_ALLOW_IDMAP v6.8 | sed 's/^v6.8://') \
> > 	<(git grep FS_ALLOW_IDMAP v6.9-rc4 | sed 's/^v6.9-rc4://') \
> > | tail -n+4;
> > +fs/hugetlbfs/inode.c:	.fs_flags               = FS_ALLOW_IDMAP,
> > 
> > $ diff -w -U0 \
> > 	<(git grep FS_ALLOW_IDMAP v6.6 | sed 's/^v6.6://') \
> > 	<(git grep FS_ALLOW_IDMAP v6.7 | sed 's/^v6.7://') \
> > | tail -n+4;
> > +fs/ceph/super.c:	.fs_flags	= FS_RENAME_DOES_D_MOVE | FS_ALLOW_IDMAP,
> > $ diff -w -U0 \
> > 	<(git grep FS_ALLOW_IDMAP v6.2 | sed 's/^v6.2://') \
> > 	<(git grep FS_ALLOW_IDMAP v6.3 | sed 's/^v6.3://') \
> > | tail -n+4;
> > +mm/shmem.c:	.fs_flags	= FS_USERNS_MOUNT | FS_ALLOW_IDMAP,
> > $ diff -w -U0 \
> > 	<(git grep FS_ALLOW_IDMAP v6.1 | sed 's/^v6.1://') \
> > 	<(git grep FS_ALLOW_IDMAP v6.2 | sed 's/^v6.2://') \
> > | tail -n+4;
> > +fs/squashfs/super.c:	.fs_flags = FS_REQUIRES_DEV | FS_ALLOW_IDMAP,
> 
> 
> Heh, nice trick. Do I need to resend for this or can you add it while you
> apply it?

I can.  :-)

> > > Signed-off-by: Rodrigo Campos <rodrigo@sdfg.com.ar>
> > > ---
> > > 
> > > I've took the liberty of adding hugetlbfs that was merged in Linux 6.9-rc1 but there is still no
> > > final release of 6.9. Please feel free to drop that if you prefer to wait for the final release to
> > > include it.
> > 
> > Are you confident that it will be in 6.9?  If so, I don't mind having it
> > already in the manual.
> 
> Yes. It's already rc6 and there was no issue reported for this, the patch is
> quite trivial too and was in linux-next before without issues either.

Okay.  I've applied the patch.  Thanks!
<https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=8ea186128f96d6f8912e05c95544734004618827>

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>
A client is hiring kernel driver, mm, and/or crypto developers;
contact me if interested.

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

Re: [PATCH] mount_setattr.2: Update supported file-systems

[Rodrigo Campos]

On 4/29/24 12:31 PM, Alejandro Colomar wrote:
> Okay.  I've applied the patch.  Thanks!
> <https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=8ea186128f96d6f8912e05c95544734004618827>

Thanks!

There is no online html version of this, right? Not even after the 
recent 6.8 release?

I'm asking because I would like to link it in Kubernetes documentation.



Best
Rodrigo

Re: [PATCH] mount_setattr.2: Update supported file-systems

[Alejandro Colomar]

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

Hi Rodrigo,

On Tue, May 21, 2024 at 11:08:58AM GMT, Rodrigo Campos wrote:
> On 4/29/24 12:31 PM, Alejandro Colomar wrote:
> > Okay.  I've applied the patch.  Thanks!
> > <https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=8ea186128f96d6f8912e05c95544734004618827>
> 
> Thanks!

:-)

> There is no online html version of this, right? Not even after the recent
> 6.8 release?

Yes, there is.  We publish a PDF book for each release at:
<https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/book/>
<https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/book/man-pages-6.8.pdf>

with a copy also available at my own server:
<https://www.alejandro-colomar.es/share/dist/man-pages/6/6.8/man-pages-6.8.pdf>

And if you want to check an online version of git HEAD (like this case,
since the patch was applied after the release), it's available in my own
sever:
<https://www.alejandro-colomar.es/share/dist/man-pages/git/HEAD/man-pages-HEAD.pdf>

You will find that my SSL cert is self-signed.  It's documented here:
<https://www.alejandro-colomar.es/ssl>.  You can use HTTP links to avoid
it, or add my certificate to your browser exceptions.

> I'm asking because I would like to link it in Kubernetes documentation.
> 
> 
> 
> Best
> Rodrigo

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

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

Re: [PATCH] mount_setattr.2: Update supported file-systems

[Rodrigo Campos]

On 5/21/24 12:31 PM, Alejandro Colomar wrote:
> On Tue, May 21, 2024 at 11:08:58AM GMT, Rodrigo Campos wrote:
>> There is no online html version of this, right? Not even after the recent
>> 6.8 release?
> 
> Yes, there is.  We publish a PDF book for each release at:
> <https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/book/>
> <https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/book/man-pages-6.8.pdf>
> 
> with a copy also available at my own server:
> <https://www.alejandro-colomar.es/share/dist/man-pages/6/6.8/man-pages-6.8.pdf>
> 
> And if you want to check an online version of git HEAD (like this case,
> since the patch was applied after the release), it's available in my own
> sever:

Nah, the patch was included in 6.8 :)

> <https://www.alejandro-colomar.es/share/dist/man-pages/git/HEAD/man-pages-HEAD.pdf>
> 
> You will find that my SSL cert is self-signed.  It's documented here:
> <https://www.alejandro-colomar.es/ssl>.  You can use HTTP links to avoid
> it, or add my certificate to your browser exceptions.

Oh, thanks. Pointing to a specific release is not very useful for 
documentation, as I want it to point to the latest version so users can 
see which fs support idmap mounts on which kernels, I don't want to 
update the link every time there is a man-pages release.

Also, in 2024 pointing to a site with self-signed cert is not something 
I'm not willing to do in the Kubernetes documentation. I understand your 
issues with CA, but self-signed for this context is definitely not better.

And don't worry, if a CA does indeed impersonate you, no one will 
realize it as the cert will just be trusted. Maybe only users that 
remember you use self signed might suspect, but maybe they will think 
you use a signed cert already ;)

Thanks a lot anyways!
Rodrigo

Re: [PATCH] mount_setattr.2: Update supported file-systems

[Alejandro Colomar]

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

Hi Rodrigo,

On Tue, May 21, 2024 at 12:53:10PM GMT, Rodrigo Campos wrote:
> On 5/21/24 12:31 PM, Alejandro Colomar wrote:
> > On Tue, May 21, 2024 at 11:08:58AM GMT, Rodrigo Campos wrote:
> > > There is no online html version of this, right? Not even after the recent
> > > 6.8 release?
> > 
> > Yes, there is.  We publish a PDF book for each release at:
> > <https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/book/>
> > <https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/book/man-pages-6.8.pdf>
> > 
> > with a copy also available at my own server:
> > <https://www.alejandro-colomar.es/share/dist/man-pages/6/6.8/man-pages-6.8.pdf>
> > 
> > And if you want to check an online version of git HEAD (like this case,
> > since the patch was applied after the release), it's available in my own
> > sever:
> 
> Nah, the patch was included in 6.8 :)

True.  cgit confused me.  :)

> > <https://www.alejandro-colomar.es/share/dist/man-pages/git/HEAD/man-pages-HEAD.pdf>
> > 
> > You will find that my SSL cert is self-signed.  It's documented here:
> > <https://www.alejandro-colomar.es/ssl>.  You can use HTTP links to avoid
> > it, or add my certificate to your browser exceptions.
> 
> Oh, thanks. Pointing to a specific release is not very useful for
> documentation, as I want it to point to the latest version so users can see
> which fs support idmap mounts on which kernels, I don't want to update the
> link every time there is a man-pages release.
> 
> Also, in 2024 pointing to a site with self-signed cert is not something I'm
> not willing to do in the Kubernetes documentation.

I guess you meant

	s/not something I'm not willing/something I'm not willing/

Is then HTTP okay for you?  MY website works with HTTP just fine, and
doesn't try to switch to HTTPS (but browsers these days got dumber and
may force HTTPS).  Or do you need something from me?  It wasn't clear to
me from your response.

I might be able to set up hardlinks in <kernel.org> with kup(1) to have
<.../man-pages-latest.pdf> if HTTP doesn't work for you.  I'd need to
manually update it at every release, though (but I guess it's not that
bad).

> I understand your issues
> with CA, but self-signed for this context is definitely not better.
> 
> And don't worry, if a CA does indeed impersonate you, no one will realize it
> as the cert will just be trusted.

I see the 'Connection not secure' logo as a security feature.  :D
If I see my website as trusted, it's actually the other way around.  Of
course, only those who remember me using a self-signed cert will notice.
But that's true of any impersonation.

Anyway, hopefully nobody will trust my website at all, because there's
nothing important in it, other than the git(1) repos and the documents,
all of which are PGP-signed.

This is just my grain of sand to take down the CA system.

> Maybe only users that remember you use
> self signed might suspect, but maybe they will think you use a signed cert
> already ;)

Even if I ever switch to a signed cert, I will provide my detached
signature to it.  If a cert doesn't have a PGP signature from me,
suspect.  ;)

> 
> Thanks a lot anyways!
> Rodrigo

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

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

Re: [PATCH] mount_setattr.2: Update supported file-systems

[Rodrigo Campos]

On 5/21/24 1:27 PM, Alejandro Colomar wrote:
> Hi Rodrigo,
>>> <https://www.alejandro-colomar.es/share/dist/man-pages/git/HEAD/man-pages-HEAD.pdf>
>>>
>>> You will find that my SSL cert is self-signed.  It's documented here:
>>> <https://www.alejandro-colomar.es/ssl>.  You can use HTTP links to avoid
>>> it, or add my certificate to your browser exceptions.
>>
>> Oh, thanks. Pointing to a specific release is not very useful for
>> documentation, as I want it to point to the latest version so users can see
>> which fs support idmap mounts on which kernels, I don't want to update the
>> link every time there is a man-pages release.
>>
>> Also, in 2024 pointing to a site with self-signed cert is not something I'm
>> not willing to do in the Kubernetes documentation.
> 
> I guess you meant
> 
> 	s/not something I'm not willing/something I'm not willing/

Yes, sorry.

> Is then HTTP okay for you?  MY website works with HTTP just fine, and

Not really. Lot of browsers switch to https, even if you don't redirect 
on the server.

> doesn't try to switch to HTTPS (but browsers these days got dumber and
> may force HTTPS).  Or do you need something from me?  It wasn't clear to
> me from your response.

I prefer an HTML website (a 8mb pdf is not the best experience, 
specially on mobile), and a fixed link that is kept updated with the 
latest info is what I'd love (doesn't matter if it is latest git or 
latest release, the fact that is periodically updated is what matter to me).

Something like man7.org or man.die.net would be great, if they were updated.

> 
> I might be able to set up hardlinks in <kernel.org> with kup(1) to have
> <.../man-pages-latest.pdf> if HTTP doesn't work for you.  I'd need to
> manually update it at every release, though (but I guess it's not that
> bad).

Thanks a lot! But I'm not sure linking such a big PDF is nice, I think 
I'll just mention to check the manpage.

I'll let you know if I find a use case for the latest PDF, thanks! :)



Best,
Rodrigo

Re: [PATCH] mount_setattr.2: Update supported file-systems

[Alejandro Colomar]

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

[CC += Elliott]

Hi Rodrigo,

On Tue, May 21, 2024 at 01:49:47PM GMT, Rodrigo Campos wrote:
> On 5/21/24 1:27 PM, Alejandro Colomar wrote:
> > Is then HTTP okay for you?  MY website works with HTTP just fine, and
> 
> Not really. Lot of browsers switch to https, even if you don't redirect on
> the server.

Yep.

> > doesn't try to switch to HTTPS (but browsers these days got dumber and
> > may force HTTPS).  Or do you need something from me?  It wasn't clear to
> > me from your response.
> 
> I prefer an HTML website (a 8mb pdf is not the best experience, specially on
> mobile), and a fixed link that is kept updated with the latest info is what
> I'd love (doesn't matter if it is latest git or latest release, the fact
> that is periodically updated is what matter to me).

This has been asked in the past at least by a Google (bionic libc)
employee.  If any company is willing to put money in it, we could do
something; here are certainly programmers that could do it (I'm not just
thinking of setting up a website, but also of improving the tools that
generate the HTML from manual pages; that is, groff(1)).

> Something like man7.org or man.die.net would be great, if they were updated.

It seems man7.org gets updated eventually.  The period for those events
is unknown to me, though.  Not too often.  linux.die.net/man is frozen
in the past it seems.

> > I might be able to set up hardlinks in <kernel.org> with kup(1) to have
> > <.../man-pages-latest.pdf> if HTTP doesn't work for you.  I'd need to
> > manually update it at every release, though (but I guess it's not that
> > bad).
> 
> Thanks a lot! But I'm not sure linking such a big PDF is nice, I think I'll
> just mention to check the manpage.
> 
> I'll let you know if I find a use case for the latest PDF, thanks! :)

You're welcome!  :-)

> Best,
> Rodrigo

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

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

Re: [PATCH] mount_setattr.2: Update supported file-systems

[Rodrigo Campos]

On 5/21/24 2:16 PM, Alejandro Colomar wrote:
> [CC += Elliott]
> 
> Hi Rodrigo,
> 
>> I prefer an HTML website (a 8mb pdf is not the best experience, specially on
>> mobile), and a fixed link that is kept updated with the latest info is what
>> I'd love (doesn't matter if it is latest git or latest release, the fact
>> that is periodically updated is what matter to me).
> 
> This has been asked in the past at least by a Google (bionic libc)
> employee.  If any company is willing to put money in it, we could do

I don't think I can help with that, sorry :-(

> something; here are certainly programmers that could do it (I'm not just
> thinking of setting up a website, but also of improving the tools that
> generate the HTML from manual pages; that is, groff(1)).

Fair. Just out of curiosity, do you have any improvements in mind? Or 
not from the top of your head?


Best,
Rodrigo

Re: [PATCH] mount_setattr.2: Update supported file-systems

[Alejandro Colomar]

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

Hi Rodrigo,

On Thu, May 23, 2024 at 11:24:19AM GMT, Rodrigo Campos wrote:
> On 5/21/24 2:16 PM, Alejandro Colomar wrote:
> > [CC += Elliott]
> > 
> > Hi Rodrigo,
> > 
> > > I prefer an HTML website (a 8mb pdf is not the best experience, specially on
> > > mobile), and a fixed link that is kept updated with the latest info is what
> > > I'd love (doesn't matter if it is latest git or latest release, the fact
> > > that is periodically updated is what matter to me).
> > 
> > This has been asked in the past at least by a Google (bionic libc)
> > employee.  If any company is willing to put money in it, we could do
> 
> I don't think I can help with that, sorry :-(

I guess.  In any case, if that changes, please let us know.  ;)

> > something; here are certainly programmers that could do it (I'm not just
> > thinking of setting up a website, but also of improving the tools that
> > generate the HTML from manual pages; that is, groff(1)).
> 
> Fair. Just out of curiosity, do you have any improvements in mind? Or not
> from the top of your head?

G. Branden Robinson, maintainer of groff(1) has been proposing several
in the last few years in the mailing list.  The .MR macro is the one
that has already been published in groff-1.23.0.  There are a few other
improvements.  Plus very many bugs that I reported against grohtml(1)
that need investigation.

> Best,
> Rodrigo

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

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