Error building Hurd on an existing Hurd

[Zhaoming Luo]

Hi,

I am trying to build Hurd (76419b67...) from source on an existing Hurd. 
I found this post 
<https://mail.gnu.org/archive/html/bug-hurd/2023-01/msg00132.html>. 
However, when I tried ./configure && make, I got the following error:
I guess some mach libraries are needed, but I haven't found more 
up-to-date instructions about building Hurd. Thanks for any help in advance.


```
...

default_pagerUser.c: In function 'default_pager_object_create':
default_pagerUser.c:75:17: error: unknown type name 
'mach_port_name_inlined_t'

   75 | mach_port_name_inlined_t memory_object;
  | ^~~~
default_pagerUser.c:180:45: error: request for member 'name' in 
something not a structure or union

  180 | *memory_object = OutP->memory_object.name;
  | ^
default_pagerUser.c: In function 'default_pager_objects':
default_pagerUser.c:321:25: error: unknown type name 
'mach_port_name_inlined_t'

  321 | mach_port_name_inlined_t ports[512];
  | ^~~~
default_pagerUser.c: In function 'default_pager_object_pages':
default_pagerUser.c:502:17: error: unknown type name 
'mach_port_name_inlined_t'

  502 | mach_port_name_inlined_t memory_object;
  | ^~~~

...

```

Best

--
Zhaoming Luo

Re: [PATCH hurd]: adding /dev/rtc device

[Zhaoming Luo]

On 10/21/24 7:37 PM, Samuel Thibault wrote:

Zhaoming Luo, le lun. 21 oct. 2024 19:31:19 +0800, a ecrit:

Adding /dev/rtc device in the Hurd as described on [1]contributing website.

/dev/rtc is useless until rtc and the functions for accessing it are added in
dev_name_list in GNU mach.

So there is no real reason to commit this for now, we have to wait for
the mach device to exist.

Also, perhaps it doesn't need to reside in mach and be a userland
translator, in which case it won't be devnode which will be needed here.
Then perhaps 'adding /dev/rtc device' should be removed from 'small hack 
entries', or this entry includes implementing a rtc mach device? In 
addition to that, I'm quite confused about 'it doesn't need to reside in 
mach'. Do you mean it is not necessary  to add a rtc mach device? But I 
think we can only access underlying device through mach device 
interface, device_open() for example, and a rtc mach device is required.


--
Zhaoming Luo

[PATCH hurd]: adding /dev/rtc device

[Zhaoming Luo]

Adding /dev/rtc device in the Hurd as described on contributing website 
<https://darnassus.sceen.net/~hurd-web/contributing/#index1h2>.


/dev/rtc is useless until rtc and the functions for accessing it are 
added in dev_name_list in GNU mach.


---
 sutils/MAKEDEV.sh | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/sutils/MAKEDEV.sh b/sutils/MAKEDEV.sh
index c3d7d112..6a65c8ea 100644
--- a/sutils/MAKEDEV.sh
+++ b/sutils/MAKEDEV.sh
@@ -120,7 +120,7 @@ mkdev() {
 ;;

   std)
-    mkdev console tty random urandom null zero full fd time mem klog shm
+    mkdev console tty random urandom null zero full fd time mem klog 
shm rtc

 ;;
   console|com[0-9])
 st $I root 600 c /hurd/term ${DEVDIR}/$I device $I;;
@@ -155,6 +155,8 @@ mkdev() {
 st $I root 644 c /hurd/storeio --no-cache time ;;
   mem)
 st $I root 660 c /hurd/storeio --no-cache mem ;;
+  rtc)
+    st $I root 660 c /hurd/devnode $I ;;
   klog)
 st $I root 660 c /hurd/streamio kmsg;;
   # ptys

--
Zhaoming Luo

Re: [PATCH hurd]: adding /dev/rtc device

[Zhaoming Luo]

On 10/21/24 8:12 PM, Samuel Thibault wrote:
Thank you for your patience, but there are still a few things I don't 
understand.

I mean that it probably doesn't have to be in kernelland, and rather be
a userland translator.

Do you mean we can implement an userland translator (it is also a rtc 
device driver, something like /hurd/rtc?) without using the device 
interface (e.g. device_open("rtc",...) to open rtc) provided by gnumach? 
If the answer is yes. How?

Userland can implement device_open etc. Actually we would rather make
/dev/rtc expose the usual ioctls that applications expect to be able to
use, we don't necessarily want to implement the device_* interface.


How do we expose the usual ioctls?

--
Zhaoming Luo

Re: Error building Hurd on an existing Hurd

[Zhaoming Luo]

Guys thank you for your patience. I realize the problem is my MIG was not up to 
date. A few days ago I compiled an old version MIG from source and used it. So 
I removed the old one and installed the latest MIG from apt.

The following instructions suggested by jbranso works fine:
$ apt get build-dep gnumach hurd
$ apt source gnumach
$ apt source hurd
$ cd hurd directory; autoreconf --install;  ./configure; make

---

When I tried to compile hurd repo from the latest tree by using the following 
commands, it failed:
$ git clone git://git.savannah.gnu.org/hurd/hurd.git
$ autoreconf --install
$ ./configure && make

Additional information:
```
$ sudo apt build-dep hurd
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

$ mig --version
i686-gnu-mig (GNU MIG) 1.8+git20230520
```

Errors:
```
start-translator-long.c:42:3: error: unknown type name 
'mach_port_name_inlined_t'
   42 |   mach_port_name_inlined_t control_port;
  |   ^~~~
start-translator-long.c:51:3: error: unknown type name 
'mach_port_name_inlined_t'
   51 |   mach_port_name_inlined_t realnode;
  |   ^~~~
start-translator-long.c: In function 'service_fsys_startup':
start-translator-long.c:79:31: error: 'mach_port_name_inlined_t' undeclared 
(first use in this function); did you mean 'mach_port_name_array_t'?
   79 |   .msgt_size = 8 * sizeof(mach_port_name_inlined_t),
  |   ^~~~
  |   mach_port_name_array_t
start-translator-long.c:79:31: note: each undeclared identifier is reported 
only once for each function it appears in
start-translator-long.c:160:46: error: request for member 'name' in something 
not a structure or union
  160 |   *control = request.startup.control_port.name;
  |  ^
start-translator-long.c:164:47: error: request for member 'name' in something 
not a structure or union
  164 |&reply.realnode.name, &realnode_type, 
task,
  |   ^
start-translator-long.c:170:43: error: request for member 'name' in something 
not a structure or union
  170 |   if (!reply.RetCode && reply.realnode.name != MACH_PORT_NULL)
  |   ^
start-translator-long.c:183:60: error: request for member 'name' in something 
not a structure or union
  183 | mach_port_deallocate (mach_task_self (), reply.realnode.name);
  |^
```

--
Zhaoming Luo

Some confusions about /hurd/chrdev

[Zhaoming Luo]

Hi,

While I was reading the document about chrdev I was quite confused. On 
this website 
<https://darnassus.sceen.net/~hurd-web/hurd/documentation/translators/>, 
it says "all device files are provided by translators". In the Hurd, I 
get `/hurd/chrdev 0 36` when I run `showtrans /dev/cons/mouse`. However, 
on the other website 
<https://darnassus.sceen.net/~hurd-web/hurd/translator/short-circuiting/>, 
it says "In fact, chrdev and blkdev aren't even implemented as 
translators at all". Is this a contradiction?


The other question I have is why I can't find `/hurd/chrdev` in the 
Hurd. I try to understand the meaning of 0 and 36 in `/hurd/chrdev 0 36` 
but I cannot find the executable or the source code in the git tree.


I also cannot find the source code of `/hurd/netdde` in the git tree.

--
Zhaoming Luo

Re: Error building Hurd on an existing Hurd

[Zhaoming Luo]

On 10/22/24 3:43 PM, Samuel Thibault wrote:


That is very old.

See
https://www.debian.org/ports/hurd/hurd-install#morepackages

to fix your sources.list and upgrade to the most recent packages.

Thank you. It works after the upgrade :D. I didn't add the up-to-date 
sources because I thought I was using 2023 release and there was no need 
to do it.


--
Zhaoming Luo

Re: Error building Hurd on an existing Hurd

[Zhaoming Luo]

On 10/22/24 3:37 PM, Samuel Thibault wrote:


Hello,


Hi,


Which version of gnumach-dev do you have?

dpkg -l gnumach-dev


Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version Architecture Description
+++-=-===--===
ii  gnumach-dev:hurd-i386 2:1.8+git20230526-2 hurd-i386GNU version of the 
Mach microkernel

--
Zhaoming Luo

Re: No confirmation email after subscribe to bug-hurd mail list using one of my email

[Zhaoming Luo]

On 11/5/24 7:11 AM, Zhaoming Luo wrote:

On 11/5/24 4:28 AM, jbra...@dismail.de wrote:

How did you subscribe?
I subscribe on this website: 
https://lists.gnu.org/mailman/listinfo/bug-hurd

I've never had any issues signing up to a mailing list.
This is my first my come across this issue, my other two emails work 
fine (zhaoming1...@qq.com and zhaoming1...@outlook.com).


It works now :). I think the confirmation email may be detected as spam 
by 163.com, so I modify filter setting then I received the email.


--
Zhaoming Luo

No confirmation email after subscribe to bug-hurd mail list using one of my email

[Zhaoming Luo]

Hi,

After I subscribed to bug-hurd mail list using zhaoming2...@163.com, I 
didn't receive any confirmation email; I also checked the Junk 
directory. Probably because this address is like spam?


Best

--
Zhaoming Luo

Re: No confirmation email after subscribe to bug-hurd mail list using one of my email

[Zhaoming Luo]

On 11/5/24 4:28 AM, jbra...@dismail.de wrote:

How did you subscribe?

I subscribe on this website: https://lists.gnu.org/mailman/listinfo/bug-hurd

I've never had any issues signing up to a mailing list.
This is my first my come across this issue, my other two emails work 
fine (zhaoming1...@qq.com and zhaoming1...@outlook.com).


--
Zhaoming Luo

Re: [RFC PATCH] Adding RTC device (work in progress)

[Zhaoming Luo]

On 11/5/24 9:27 PM, Sergey Bugaev wrote:

First, a brief description of what a protid is. Hurd translators
typically represent "files" internally with three kinds of distinct
structures:

1. node -- these are filesystem nodes, same concept as an "inode".
2. peropen -- this keeps the data "per open" of the file and
corresponds to an "open file description" in POSIX. Things like
current I/O offset and the open mode (O_READ | O_WRITE ...) live here.
3. protid (or "credential") -- describes a specific "user" (UIDs/GIDs)
on behalf of whom the file is being accessed.

A protid has a pointer to the peropen, and the peropen has a pointer
to the node. A node can have multiple peropens referring to it (when
the file has been opened multiple times), and a peropen can have
multiple protids referring to it (when processes running as different
users share an open file description, e.g. your shell and a sudo
invocation share the pts). In trivfs, there's only a single node, so
the concept is deemphasized.

The concept of protid doesn't exist in classic Unix, since a
monolithic kernel can just directly see which UID the current process
runs as. But Mach IPC is (intentionally) designed in a way that it's
inherently impossible to see "who's asking", so instead we represent
differently-privileged callers with different handles (protids) that
refer to the same peropen, and then we check which protid the request
was made on.

It is a protid that corresponds to an Mach port (io_t, file_t, ...),
though the client side doesn't need to care.

When an incoming request arrives, the thing you actually receive in a
message is the port name (ignoring protected payloads for now). What
you actually want is the protid that it corresponds to.

trivfs has the API to look up the protid given the port, namely
trivfs_begin_using_protid (which wraps ports_lookup_port from
libports), and you could call that yourself:

kern_return_t
rtc_S_foobar (io_t port, int foo, int *bar)
{
   error_t err = 0;
   struct trivfs_protid *cred = trivfs_begin_using_protid (port);

   if (!cred)
 /* The request came in on a port that we listen for incoming
  * messages on, but it doesn't correspond to a protid. Must
  * be some other kind of port. */
 return EOPNOTSUPP;

   if (!(cred->po->openmodes & O_READ))
 {
   err = EBADF;
   goto out;
 }

   do something with cred...

out:
   trivfs_end_using_protid (cred);
   return err;
}

But since we already have a code generator (MIG), why not make it
generate the conversion logic for us as well. And so, in MIG, when
defining a type, you can provide 'intran' and 'outtran' and
'destructor' function names, and MIG will generate the calls for you.

So the proper MIG way to (but see below about the Hurd way) to do the
thing that you're trying to do would be to define your own flavor of
Mach ports, say rtc_port_t, like this:

type rtc_port_t = mach_port_t
   intran: trivfs_protid_t trivfs_begin_using_protid (io_t)
   destructor: trivfs_end_using_protid (trivfs_protid_t);

and then use that type in the routine definitions. MIG would then call
trivfs_begin_using_protid & trivfs_end_using_protid in the server-side
generated functions, only passing trivfs_protid_t (which is a typedef
for struct trivfs_protid *, since MIG can't deal with the full C type
notation) to your implementation. The downside of this is that it the
implementation details of the server leak into the API definition, and
for instance you'd have to edit the .defs if you switch the server
from trivfs to netfs.

You can find some documentation about this MIG feature under "Type
Translation Information" on page 17 of the "Mach 3 Server Writer’s
Guide" [0], but of course keep in mind that the guide was written a
long time ago, about a much older version of MIG, without any of the
Hurd additions / specifics / best practices.

[0]: http://shakthimaan.com/downloads/hurd/server_writer.pdf is
apparently one place to find it

Then, hurd_types.defs has this:

type io_t = mach_port_copy_send_t
#ifdef IO_INTRAN
intran: IO_INTRAN
intranpayload: IO_INTRAN_PAYLOAD
#else
#ifdef HURD_DEFAULT_PAYLOAD_TO_PORT
intranpayload: io_t HURD_DEFAULT_PAYLOAD_TO_PORT
#endif
#endif
#ifdef IO_OUTTRAN
outtran: IO_OUTTRAN
#endif
#ifdef IO_DESTRUCTOR
destructor: IO_DESTRUCTOR
#endif
;

(and same for all the other types of ports, e.g. FILE_INTRAN,
SHUTDOWN_DESTRUCTOR etc)

which lets you use the standard io_t type while plugging in your own
intran/intranpayload/outtran/destructor functions, in a way that
doesn't leak into the defs. You only have to define the macros in your
local mig-mutate.h header in your server.

I think it's worth to put this part into mig documentation website[0], 
just like the IRC log pieces we have already had. What do you think? I 
can do it.


[0]: 
https://darnassus.sceen.net/~hurd-web/microkernel/mach/mig/documentation/


--
Zhaoming Luo

Re: [RFC PATCH] Adding RTC device (work in progress)

[Zhaoming Luo]

On 11/1/24 8:13 PM, Sergey Bugaev wrote:

On Fri, Nov 1, 2024 at 2:46 PM Zhaoming Luo  wrote:

diff --git a/hurd/pioctl.defs b/hurd/pioctl.defs
new file mode 100644
index ..36fa8d3f
--- /dev/null
+++ b/hurd/pioctl.defs
@@ -0,0 +1,34 @@
+/* Definitions for /dev/rtc ioctls */
+
+/* Ioctl group 'p'; the subsystem is derived from calculations in
+   hurd/ioctls.defs. */
+subsystem pioctl 14;
+
+#include 
+
+import "rtc.h";

This would only work when the generated C file is built in the rtc/ of
the Hurd source tree, right? Perhaps this should be ?
It makes sense, and I have corrected it. However, then the compilation 
will fail with:

```
make[2]: *** No rule to make target 'hurd/rtc/rtc.h', needed by 
'main.o'.  Stop.

```
If I want to fix it. Do I need to modify $(hurd)/rtc/Makefile or add 
hurd/rtc/rtc.h into hurd-dev package?

diff --git a/rtc/mig-mutate.h b/rtc/mig-mutate.h
new file mode 100644
index ..e69de29b

You'd want to put something like the following into this file:

#define IO_INTRAN trivfs_protid_t trivfs_begin_using_protid (io_t)
#define IO_INTRAN_PAYLOAD trivfs_protid_t trivfs_begin_using_protid_payload
#define IO_DESTRUCTOR trivfs_end_using_protid (trivfs_protid_t)
#define IO_IMPORTS import "libtrivfs/mig-decls.h";

...and change 'io_t reqport' arguments in pioctl-ops.c to 'struct
trivfs_protid *cred'.
I just know that this is the process of transforming the parameter type 
so we can have different parameter types on server side and user side. 
Is there some document explaining how to write a mig-mutate.h file? I 
haven't found one.



The feedback is very valuable, thank you.

--
Zhaoming Luo

Re: Using tm_t in a defs file

[Zhaoming Luo]

On 10/28/24 2:36 AM, Sergey Bugaev wrote:

But the important point is that on
the client side, glibc doesn't use the generated C function to invoke
the routine, and instead does things based on the ioctl number, so
it's crucial that the definition of RTC_RD_TIME constant matches the
signature of the MIG routine.

On Linux, RTC_RD_TIME is defined as _IOR('p', 0x09, struct rtc_time),
and IIUC you plan to keep the same definition. _IOR (..., ..., type)
means an RPC that has a single out-parameter of the given type, so
that's what your MIG routine should be defined as. You'll also have to
define _IOT_rtc_time in a C header (rtc.h) next to the struct rtc_time
definition, using the _IOT macro.
I see, so _IOR is a wrapper of _IOC for calculating an ioctl number. 
This ioctl number is used for invoking the routine in the rtc server. We 
need to define _IOT_rtc_time because calculating RTC_RD_TIME requires 
the ioctl number of rtc, _IOT_rtc_time (like what's mentioned in 
ioctls.h in glibc).


Please tell me if this all makes sense, and if I need to rephrase /
expand on something.

It's very clear, thank you.

--
Zhaoming Luo 

Using tm_t in a defs file

[Zhaoming Luo]

Hi,

I did the following things in a Debian/Hurd virtual machine.

I was following this link 
<https://darnassus.sceen.net/~hurd-web/hurd/translator/writing/example/> 
to implement a rtc server. My idea is that I should implement a working 
rtc server in user space before adding the source code into the repo 
because I don't want to get stuck in Makefile system before I have a 
working rtc server. I wrote the pioctl.defs (I paste it below), used mig 
to resolve it, and mig told me 'tm_t' is not defined. Then I added the 
following lines in /usr/include/i386-gnu/hurd/ioctl_types.h:


```
typedef struct srtentry srtentry_t;

+#include 
+typedef struct tm tm_t;
#endif  /* hurd/ioctl_types.h */
```

It still didn't work. How can I use `struct tm` in a user space defs file?

Thank you

pioctl.defs:
```
/* Ioctl group 'p'; the subsystem is derived from calculations in
    hurd/ioctls.defs. */
subsystem pioctl 14;

#include 

#ifdef PIOCTL_IMPORTS
PIOCTL_IMPORTS
#endif

INTR_INTERFACE

/* TODO: adding other ioctl calls for /dev/rtc in mc146818rtc.h */
skip; skip; skip; skip; /* 0 1 2 3 */
skip; skip; skip; skip; /* 4 5 6 7 */
skip;   /* 8 */

/* 9 RTC_RD_TIME */
routine pioctl_rtc_rd_time (
    reqport: io_t;
    inout time: tm_t);

/* 10 RTC_SET_TIME */
routine pioctl_rtc_set_time (
    reqport: io_t;
    time: tm_t);
```

--
Zhaoming Luo 

[PATCH Web] Fixing a ld error in Data User-Server Translator Example

[Zhaoming Luo]

-lthreads cause ld: cannot find -lthreads: No such file or directory error
After removing -lthreads the example can work

---
 hurd/translator/writing/example.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hurd/translator/writing/example.mdwn 
b/hurd/translator/writing/example.mdwn
index 0a3be4df..1891f74f 100644
--- a/hurd/translator/writing/example.mdwn
+++ b/hurd/translator/writing/example.mdwn
@@ -241,7 +241,7 @@ Makefile:
 CC = gcc
 MIG = mig
 CFLAGS = -Wall -g  -D_GNU_SOURCE
-LDFLAGS = -lthreads -lports -ltrivfs -lfshelp -lshouldbeinlibc
+LDFLAGS = -lports -ltrivfs -lfshelp -lshouldbeinlibc
 INCLUDES = -I.
 LCHDRS = 
 MIGCOMSFLAGS = -prefix S_
-- 
2.47.0

[RFC PATCH Hurd] Using NETIF_FOREACH to replace netif for-loops

[Zhaoming Luo]

Come across NETIF_FOREACH in /usr/include/lwip/lwip/netif.h, but I'm not
sure if it affects some self-contained stuff.

netif.h belongs to liblwip-dev.

---
 lwip/iioctl-ops.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lwip/iioctl-ops.c b/lwip/iioctl-ops.c
index 14c4d585..f46b9cdb 100644
--- a/lwip/iioctl-ops.c
+++ b/lwip/iioctl-ops.c
@@ -42,7 +42,7 @@ get_if (const char *name)
   memcpy (ifname, name, IFNAMSIZ - 1);
   ifname[IFNAMSIZ - 1] = 0;
 
-  for (netif = netif_list; netif != 0; netif = netif->next)
+  NETIF_FOREACH(netif)
 {
   if (strcmp (netif_get_state (netif)->devname, ifname) == 0)
break;
@@ -376,7 +376,7 @@ lwip_S_iioctl_siocgifindex (struct sock_user * user,
 return EOPNOTSUPP;
 
   i = 1;   /* The first index must be 1 */
-  for (netif = netif_list; netif != 0; netif = netif->next)
+  NETIF_FOREACH(netif)
 {
   if (strcmp (netif_get_state (netif)->devname, ifnam) == 0)
{
@@ -410,7 +410,7 @@ lwip_S_iioctl_siocgifname (struct sock_user * user,
 return EINVAL;
 
   i = 1;   /* The first index is 1 */
-  for (netif = netif_list; netif != 0; netif = netif->next)
+  NETIF_FOREACH(netif)
 {
   if (i == *index)
break;
-- 
2.47.0

Re: Using tm_t in a defs file

[Zhaoming Luo]

On 10/27/24 6:08 PM, Sergey Bugaev wrote:

Sure, that makes sense. And it's a great property of the Hurd that you
can in fact develop out-of-tree translators with ease. Though in the
case of rtc, we'd probably want it in-tree eventually.
I didn't develop it in-tree because I haven't figure out how to write a 
Makefile for an in-tree server. I haven't found a reference or document 
for me to learn writing it. Any recommendations? Maybe I should write 
one based on the Makefile of lwip and add something in the top-level 
Makefile?

If so, it would make sense to me if you defined a type that represents
RTC's time representation right in your .defs file, and used that in
your RPCs. Perhaps like this:

type rtc_time_t = struct {
   int tm_sec;
   ...
};

with a matching definition in C.

I add it and it works now :).

/* TODO: adding other ioctl calls for /dev/rtc in mc146818rtc.h */
skip; skip; skip; skip; /* 0 1 2 3 */
skip; skip; skip; skip; /* 4 5 6 7 */
skip;   /* 8 */

/* 9 RTC_RD_TIME */
routine pioctl_rtc_rd_time (
  reqport: io_t;
  inout time: tm_t);

Shouldn't this be 'out' rather than 'inout'?
I think my idea was that time should be a pointer. I think there may be 
two method to correct it now: 1) let time be a pointer (tm_p_t?) 2) 
using 'out' rather than 'inout'.

Maybe 1) is better? Because the message length will be shorter.

/* 10 RTC_SET_TIME */
routine pioctl_rtc_set_time (
  reqport: io_t;
  time: tm_t);

Do I understand it right that this would be more privileged than
reading the time?
Indeed[1]. How to make it more privileged. I didn't find information 
about it in [2][3] by searching 'privilged'.


reference:
[1]: https://www.man7.org/linux/man-pages/man4/rtc.4.html
[2]: http://shakthimaan.com/downloads/hurd/server_writer.pdf
[3]: http://shakthimaan.com/downloads/hurd/server_interface.pdf

Thank you

--
Zhaoming Luo 

Re: T60 poweroff command hang at halting Hurd...

[Zhaoming Luo]

On 11/10/24 11:10 AM, Almudena Garcia wrote:
Yes, I detected this problem some time ago. The halt command doesn't 
shutdown the machine. Instead, keep it in a suspension-like status, in 
which the machine is "sleep", but doesn't turn off.
Damien told me some years ago that the problem is related with IRQ 
number, and an implementation of ACPIca must solve it, but I don't 
remember if ACPIca was implemented or not.


So it's a known issue.
I would like to confirm if it is safe to use the force shutdown (long 
pressing the power button) while hanging.


Thanks for the report

You are welcome.

--
Zhaoming Luo

Re: T60 poweroff command hang at halting Hurd...

[Zhaoming Luo]

On 11/11/24 10:22 AM, Damien Zammit via Bug reports for the GNU Hurd wrote:

Please read the mailing list. I just fixed this bug and it was merged.
My bad. I saw the patch but I supposed the patch fixing that issue 
should be related to ACPICA. Thank you for the fix!


My current hurd version is 20240714-4. Does that mean the patch will be 
included in the next git version?


--
Zhaoming Luo

Re: T60 poweroff command hang at halting Hurd...

[Zhaoming Luo]

On 11/10/24 11:29 PM, jbra...@dismail.de wrote:

November 9, 2024 at 10:10 PM, "Almudena Garcia" mailto:liberamenso10...@gmail.com?to=%22Almudena%20Garcia%22%20%3Cliberamenso1%40gmail.com%3E
 > wrote:





Yes, I detected this problem some time ago. The halt command doesn't shutdown the 
machine. Instead, keep it in a suspension-like status, in which the machine is 
"sleep", but doesn't turn off.
Damien told me some years ago that the problem is related with IRQ number, and 
an implementation of ACPIca must solve it, but I don't remember if ACPIca was 
implemented or not.

So it's a known issue.
Sorry for the inconveniences, and we expect to solve this problem in a future.


If you'd like you could help us debug this minor issue.

I would like to help :).


I think it's $hurd-src/hurd/shutdown.c
I didn't find $hurd-src/hurd/shutdown.c, but instead I found 
$hurd-src/shutdown/shutdown.c; is this shutdown server the correct one?


You could add in some printf (or maybe mach_print) throughout the file
and try to see where the problem starts.

Joshua


Thanks for the report

El dom, 10 nov 2024 a las 2:39, Zhaoming Luo (mailto:zhming...@163.com >) escribió:



Hi,

I have installed Debian Hurd on my T60. I just finished configuring
apt[0] so it has more packages. When I typed poweroff, it got stuck at
`startup: halting Hurd...`. I have forced to shut it down (by holding
the power button) several times; it seems to me the force shutdown
didn't break anything (I didn't see any message about repairing file
system). I think a decent way of shutting it down is necessary.

I tried to search in mail list and IRC log about the shutdown hang, e.g.
[1], but they seem not to be my case.

The command `reboot` works.

`poweroff-hurd` mentioned in [2] also hangs at `startup: halting Hurd`.

part of the log of `poweroff-hurd`:
```
startup: notifying random of halt...done
startup: notifying netdde of halt...done
startup: notifying pfinet of halt...done
...
startup: notifying acpi of halt...done
startup: halting Hurd...
(hang)
```

Thank you

[0]:https://www.debian.org/ports/hurd/hurd-install#morepackages
[1]:https://logs.guix.gnu.org/hurd/2023-09-05.log#001605
[2]:https://mail.gnu.org/archive/html/bug-hurd/2024-10/msg00151.html
--
Zhaoming Luo





--
Zhaoming Luo

Re: [PATCH Hurd]: adding a missing comment

[Zhaoming Luo]

On 11/10/24 12:30 AM, Joshua Branson wrote:

Zhaoming, if you have never used git send-email, then I recommend it!

This is a short guide that will walk you through how to use it.

https://git-send-email.io/
Thank you Joshua, I have tried it and it is very useful, I didn't 
realized this tool.

I personally really like using Emacs' magit mode.  It makes messing
around with git things super easy!  Re-order commits, easily reword
commit messages, commit a change to an old commit that I made, combine
commits, etc.  In my humble opinion, it's one of the easiest ways to
work with git.

I have watched the demo of Magit. It's so attractive but I have used vim 
for three years. I found an alternative for vim which is called vimagit 
but it seems a bit unreliable (last commit is 7 months ago). I think I 
will starting changing to emacs.


--
Zhaoming Luo 

Re: [PATCH hurd]: adding /dev/rtc device

[Zhaoming Luo]

On 10/21/24 9:04 PM, Samuel Thibault wrote:


By implementing the corresponding RPC, whose msgid is given by the
IOC_MSGID macro. For instance for

RTC_RD_TIME._IOR('p', 0x09, struct rtc_time)

the group is 'p' and the command is 0x9, so the subsystem would be
14, and the exact RPC would be 140009.


I'm quite confused about the calculation of subsystem. May I have a more 
detailed process of how 14 is calculated? Including the names of the files 
in which macros is used in the calculation. Thank you

--
Zhaoming Luo

More thinking about adding /dev/rtc

[Zhaoming Luo]

Hi,

After doing more reading document and code. I think now I have a better 
understanding of adding /dev/rtc. As suggested by Samuel, because RTC 
operations belong to p-group[1],we can write a pioctl.defs for p-group 
io operations. Then this defs file can generate *_pioctl_S.h (a user 
header module); we will include this file in pioctl-ops.c which wil 
contain the core implementations of /dec/rtc ioctl operation 
(pioctl.defs is for the communication between ioctl and server). After 
that, we just need to implement pioctl-ops.c for accessing rtc device.


However, I still have a question:

- Which server should have the implementation pioctl-ops.c, pfinet or 
lwip? The directory of pfinet has the register definitions for rtc 
device[1], but the document mentions that lwip can be a replacement for 
pfinet. Maybe we can move mc146818rtc.h to lwip, or create a new server 
(because pfinet and lwip are for TCP/IP), or there is a server which 
should handle accessing rtc.


[1]:https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/pfinet/linux-src/include/linux/mc146818rtc.h
[2]:https://darnassus.sceen.net/~hurd-web/hurd/translator/pfinet/
<https://darnassus.sceen.net/~hurd-web/hurd/translator/pfinet/>

--
Zhaoming Luo 

[RFC PATCH 0/3] Adding /dev/rtc device (work in progress)

[Zhaoming Luo]

Hi,

Currently I am working on adding /dev/rtc. For now I can compile it and
use `settrans` to create a device file; I can confirm that ioctl() works
perfectly on the generated device file. I think it's a good chance to stop
and gather some suggestions and feedback, so I sent a series of RTC patches.

The next thing I'm going to do is implementing the rtc server code, i.e
rtc device driver. I have no experience of writing driver but I want to
give it a try. Any document that is recommended to read for implementing
rtc device driver?

Best,
Zhaoming

Zhaoming Luo (3):
  Compile rtc server while compiling the Hurd
  rtc server
  rtc ioctl interface definitions

 Makefile |  2 ++
 hurd/pioctl.defs | 34 ++
 rtc/Makefile | 19 ++
 rtc/main.c   | 94 
 rtc/mig-mutate.h |  0
 rtc/pioctl-ops.c | 17 +
 rtc/rtc.h| 21 +++
 7 files changed, 187 insertions(+)
 create mode 100644 hurd/pioctl.defs
 create mode 100644 rtc/Makefile
 create mode 100644 rtc/main.c
 create mode 100644 rtc/mig-mutate.h
 create mode 100644 rtc/pioctl-ops.c
 create mode 100644 rtc/rtc.h

-- 
2.47.0

[RFC PATCH 0/3] Adding /dev/rtc device (work in progress)

[Zhaoming Luo]

Hi,

Currently I am working on adding /dev/rtc. For now I can compile it and
use `settrans` to create a device file; I can confirm that ioctl() works
perfectly on the generated device file. I think it's a good chance to stop
and gather some suggestions and feedback, so I sent a series of RTC patches.

The next thing I'm going to do is implementing the rtc server code, i.e
rtc device driver. I have no experience of writing driver but I want to
give it a try. Any document that is recommended to read for implementing
rtc device driver?

Best,
Zhaoming

Zhaoming Luo (3):
  Compile rtc server while compiling the Hurd
  rtc server
  rtc ioctl interface definitions

 Makefile |  2 ++
 hurd/pioctl.defs | 34 ++
 rtc/Makefile | 19 ++
 rtc/main.c   | 94 
 rtc/mig-mutate.h |  0
 rtc/pioctl-ops.c | 17 +
 rtc/rtc.h| 21 +++
 7 files changed, 187 insertions(+)
 create mode 100644 hurd/pioctl.defs
 create mode 100644 rtc/Makefile
 create mode 100644 rtc/main.c
 create mode 100644 rtc/mig-mutate.h
 create mode 100644 rtc/pioctl-ops.c
 create mode 100644 rtc/rtc.h

-- 
2.47.0

Re: [RFC PATCH 0/3] Adding /dev/rtc device (work in progress)

[Zhaoming Luo]

On 11/1/24 6:42 PM, Sergey Bugaev wrote:

I'm only seeing a single "patch", namely this cover letter. Did you
perhaps accidentally run your git send-email on a single patch file
instead of on the whole series?

When I use `git send-email *.patch`, 0/3 patch can be sent perfectly, but
when I type 'yes' for the 1/3 patch it gave me the following error:

```
Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): y
250 OK
    ...propagated at /usr/lib/git-core/git-send-email line 1696,  
line 2.

```

--
Zhaoming Luo 

Re: [RFC PATCH 0/3] Adding /dev/rtc device (work in progress)

[Zhaoming Luo]

On 11/1/24 6:42 PM, Sergey Bugaev wrote:

I'm only seeing a single "patch", namely this cover letter. Did you
perhaps accidentally run your git send-email on a single patch file
instead of on the whole series?
This is the issue of the mail service provider I'm using. I will try to 
switch to another email provider. For now, should I post them in one 
patch or separately?


--
Zhaoming Luo 

[RFC PATCH] Adding RTC device (work in progress)

[Zhaoming Luo]

Hi,

Currently I am working on adding /dev/rtc. For now I can compile it and
use `settrans` to create a device file; I can confirm that ioctl() works
perfectly on the generated device file. I think it's a good chance to stop
and gather some suggestions and feedback, so I sent a series of RTC patches.

The next thing I'm going to do is implementing the rtc server code, i.e
rtc device driver. I have no experience of writing driver but I want to
give it a try. Any document that is recommended to read for implementing
rtc device driver?

Best,
Zhaoming


---
 Makefile |  2 ++
 hurd/pioctl.defs | 34 ++
 rtc/Makefile | 19 ++
 rtc/main.c   | 94 
 rtc/mig-mutate.h |  0
 rtc/pioctl-ops.c | 17 +
 rtc/rtc.h| 21 +++
 7 files changed, 187 insertions(+)
 create mode 100644 hurd/pioctl.defs
 create mode 100644 rtc/Makefile
 create mode 100644 rtc/main.c
 create mode 100644 rtc/mig-mutate.h
 create mode 100644 rtc/pioctl-ops.c
 create mode 100644 rtc/rtc.h

diff --git a/Makefile b/Makefile
index 4d848221..8133c9e9 100644
--- a/Makefile
+++ b/Makefile
@@ -69,6 +69,8 @@ ifeq ($(HAVE_LIBACPICA),yes)
 prog-subdirs += acpi
 endif
 
+prog-subdirs += rtc
+
 # Other directories
 other-subdirs = hurd doc config release include
 
diff --git a/hurd/pioctl.defs b/hurd/pioctl.defs
new file mode 100644
index ..36fa8d3f
--- /dev/null
+++ b/hurd/pioctl.defs
@@ -0,0 +1,34 @@
+/* Definitions for /dev/rtc ioctls */
+
+/* Ioctl group 'p'; the subsystem is derived from calculations in
+   hurd/ioctls.defs. */
+subsystem pioctl 14;
+
+#include 
+
+import "rtc.h";
+
+#ifdef PIOCTL_IMPORTS
+PIOCTL_IMPORTS
+#endif
+
+INTR_INTERFACE
+
+/* This is the arg for a struct rtc_time as specified by the
+   definition of _IOT_rtc_time in $(hurd)/rtc/rtc.h. */
+type rtc_time_t = struct[9] of int;
+
+/* TODO: adding other ioctl calls for /dev/rtc in mc146818rtc.h */
+skip; skip; skip; skip; /* 0 1 2 3 */
+skip; skip; skip; skip; /* 4 5 6 7 */
+skip; /* 8 */
+
+/* 9 RTC_RD_TIME */
+routine pioctl_rtc_rd_time (
+   reqport: io_t;
+   out time: rtc_time_t);
+
+/* 10 RTC_SET_TIME */
+routine pioctl_rtc_set_time (
+   reqport: io_t;
+   time: rtc_time_t);
diff --git a/rtc/Makefile b/rtc/Makefile
new file mode 100644
index ..dd0e19d2
--- /dev/null
+++ b/rtc/Makefile
@@ -0,0 +1,19 @@
+dir := rtc
+makemode := server
+
+SRCS = main.c pioctl-ops.c
+MIGSRCS = pioctlServer.c
+
+OBJS = main.o pioctlServer.o pioctl-ops.o
+
+HURDLIBS = trivfs shouldbeinlibc ports
+
+target = rtc
+
+include ../Makeconf
+
+MIGCOMSFLAGS += -prefix rtc_
+mig-sheader-prefix = rtc_
+pioctl-MIGSFLAGS = -imacros $(srcdir)/mig-mutate.h
+
+rtc_pioctl_S.h pioctlServer.c: mig-mutate.h
diff --git a/rtc/main.c b/rtc/main.c
new file mode 100644
index ..ae871e85
--- /dev/null
+++ b/rtc/main.c
@@ -0,0 +1,94 @@
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rtc_pioctl_S.h"
+
+#include "rtc.h"
+
+const char *argp_program_version = STANDARD_HURD_VERSION (rtc);
+
+mach_port_t fsys_identity;
+
+struct trivfs_control *rtccntl;
+
+int trivfs_fstype = FSTYPE_DEV;
+int trivfs_fsid = 0;
+int trivfs_support_read = 0;
+int trivfs_support_write = 0;
+int trivfs_support_exec = 0;
+int trivfs_allow_open = O_READ | O_WRITE;
+
+static const struct argp_option options[] =
+{
+  {0}
+};
+
+/* TODO: adding option */
+static error_t
+parse_opt (int opt, char *arg, struct argp_state *state)
+{
+  return ARGP_ERR_UNKNOWN;
+}
+
+static const struct argp rtc_argp =
+{ options, parse_opt, 0, "RTC device" };
+
+int
+demuxer (mach_msg_header_t *inp, mach_msg_header_t *outp)
+{
+  mig_routine_t routine;
+  if ((routine = rtc_pioctl_server_routine (inp)) ||
+  (routine = NULL, trivfs_demuxer (inp, outp)))
+{
+  if (routine)
+(*routine) (inp, outp);
+  return TRUE;
+}
+  else
+return FALSE;
+}
+
+int
+main (int argc, char **argv)
+{
+  error_t err;
+  mach_port_t bootstrap;
+
+  mach_port_allocate (mach_task_self (),
+ MACH_PORT_RIGHT_RECEIVE, &fsys_identity);
+
+  argp_parse (&rtc_argp, argc, argv, 0, 0, 0);
+
+  task_get_bootstrap_port (mach_task_self (), &bootstrap);
+  if (bootstrap == MACH_PORT_NULL)
+error(1, 0, "Must be started as a translator");
+
+  /* Reply to our parent */
+  err = trivfs_startup (bootstrap, 0, 0, 0, 0, 0, &rtccntl);
+  mach_port_deallocate (mach_task_self (), bootstrap);
+  if (err)
+return -1;
+
+  /* Launch. */
+  ports_manage_port_operations_multithread (rtccntl->pi.bucket, demuxer,
+   30 * 1000, 2 * 60 * 1000, 0);
+
+  return 0;
+}
+
+void
+trivfs_modify_stat (struct trivfs_protid *cred, struct stat *st)
+{
+}
+
+error_t
+trivfs_goaway (struct trivfs_control *fsys, int flags)
+{
+  exit (0);
+}
diff --git a/rtc/mig-mutate.h b/rtc/mig-mutate.h
new file mode 100644
index ..e69de29b
diff --git a/rtc/pioctl-ops.

T60 poweroff command hang at halting Hurd...

[Zhaoming Luo]

Hi,

I have installed Debian Hurd on my T60. I just finished configuring 
apt[0] so it has more packages. When I typed poweroff, it got stuck at 
`startup: halting Hurd...`. I have forced to shut it down (by holding 
the power button) several times; it seems to me the force shutdown 
didn't break anything (I didn't see any message about repairing file 
system). I think a decent way of shutting it down is necessary.


I tried to search in mail list and IRC log about the shutdown hang, e.g. 
[1], but they seem not to be my case.


The command `reboot` works.

`poweroff-hurd` mentioned in [2] also hangs at `startup: halting Hurd`.

part of the log of `poweroff-hurd`:
```
startup: notifying random of halt...done
startup: notifying netdde of halt...done
startup: notifying pfinet of halt...done
...
startup: notifying acpi of halt...done
startup: halting Hurd...
(hang)
```

Thank you

[0]:https://www.debian.org/ports/hurd/hurd-install#morepackages
[1]:https://logs.guix.gnu.org/hurd/2023-09-05.log#001605
[2]:https://mail.gnu.org/archive/html/bug-hurd/2024-10/msg00151.html
--
Zhaoming Luo

Re: [RFC PATCH v2 4/4] Add rtc server

[Zhaoming Luo]

On 11/8/24 5:10 PM, Sergey Bugaev wrote:

On Fri, Nov 8, 2024 at 4:55 AM Zhaoming Luo  wrote:

diff --git a/rtc/main.c b/rtc/main.c
new file mode 100644
index ..114fb497
--- /dev/null
+++ b/rtc/main.c
@@ -0,0 +1,88 @@
+
+#include 
+
+#include 
+#include 
+#include 


I don't think you need nullauth.h?


Indeed, removed it.

+#include 
+#include 
+#include 
+
+#include "rtc_pioctl_S.h"
+
+const char *argp_program_version = STANDARD_HURD_VERSION (rtc);
+
+struct trivfs_control *rtccntl;


Please make global variables 'static' unless there is a reason not to.

Got it.

+int trivfs_fstype = FSTYPE_DEV;
+int trivfs_fsid = 0;
+int trivfs_support_read = 0;


Actually Linux lets you read() /dev/rtc, doesn't it?

Is it implied by 'it is read-only' in [0]?
[0]:https://man.archlinux.org/man/rtc.4



+int trivfs_support_write = 0;
+int trivfs_support_exec = 0;
+int trivfs_allow_open = O_READ | O_WRITE;
+
+static const struct argp_option options[] =
+{
+  {0}
+};
+
+/* TODO: adding option */


Hm, so what kind of options do you envision it might have? (Not saying
there's none, just wondering.)
To be honest options was added just in case I want to add some options, 
but I haven't got any idea.


Can there be multiple RTC devices? (the Linux man page talks of
"/dev/rtc0, /dev/rtc1, etc."). Do we need a way to identify which
specific RTC device the translator should drive?
I found some discussion about 'multiple RTC devices" on [1]. It is 
possible to have multiple RTC devices on a single machine.


I think we exactly need a way to identify RTC devices (though I have no 
idea how to do that). Different RTC device needs different 
`pioctl-ops.c` (i.e. driver) to access. How about make each 
implementation a package? Then users can install the drivers as packages 
depending on their needs?

[1]:https://www.kernel.org/doc/html/v6.12-rc6/admin-guide/rtc.html



+static error_t
+parse_opt (int opt, char *arg, struct argp_state *state)
+{
+  return ARGP_ERR_UNKNOWN;
+}
+
+static const struct argp rtc_argp =
+{ options, parse_opt, 0, "RTC device" };
+
+int
+demuxer (mach_msg_header_t *inp, mach_msg_header_t *outp)


Same here, make it 'static' please, unless there is a reason not to.

OK



+{
+  mig_routine_t routine;
+  if ((routine = rtc_pioctl_server_routine (inp)) ||
+  (routine = NULL, trivfs_demuxer (inp, outp)))
+{
+  if (routine)
+(*routine) (inp, outp);
+  return TRUE;
+}
+  else
+return FALSE;
+}
+
+int
+main (int argc, char **argv)
+{
+  error_t err;
+  mach_port_t bootstrap;
+
+  argp_parse (&rtc_argp, argc, argv, 0, 0, 0);
+
+  task_get_bootstrap_port (mach_task_self (), &bootstrap);
+  if (bootstrap == MACH_PORT_NULL)
+error (1, 0, "Must be started as a translator");
+
+  /* Reply to our parent */
+  err = trivfs_startup (bootstrap, 0, 0, 0, 0, 0, &rtccntl);


Even more of a nitpick: better pass NULL instead of 0 when the type is
a pointer. So:

trivfs_startup (bootstrap, 0, NULL, NULL, NULL, NULL, &rtccntl)

OK


you might even specify the first 0 as O_NORW for clarity, but I
haven't seen anyone do that.

We can start doing it now :).



diff --git a/rtc/pioctl-ops.c b/rtc/pioctl-ops.c
new file mode 100644
index ..44038e26
--- /dev/null
+++ b/rtc/pioctl-ops.c
@@ -0,0 +1,28 @@
+/* Server side implementation for rtc device */
+
+/* This implementation is largely based on sys-utils/hwclock from util-linux */
+
+#include "rtc_pioctl_S.h"
+#include 
+#include 
+
+/* 9 RTC_RD_TIME -- Read RTC time */
+kern_return_t
+rtc_S_pioctl_rtc_rd_time (struct trivfs_protid *cred, struct rtc_time *time)
+{
+  if (!cred) {
+return EOPNOTSUPP;
+  }


Nitpick: according to the GNU C style, this pair of braces shouldn't be here.

OK



+  if (!(cred->po->openmodes & O_READ))
+return EBADF;
+  return KERN_SUCCESS;
+}
+
+/* 10 RTC_SET_TIME -- Set RTC time */
+kern_return_t
+rtc_S_pioctl_rtc_set_time (struct trivfs_protid *cred, struct rtc_time time)
+{
+  if (!(cred->po->openmodes & O_WRITE))
+return EBADF;


You need to check for cred being NULL here too, before you dereference it.

OK


Again, this happens when the request arrives on some port that we
listen for messages on, but it corresponds to something other than a
protid, e.g. the trivfs control port. EOPNOTSUPP is the appropriate
error code to return in that case, because indeed the
whatever-other-kind of port doesn't support the ioctl, only protids
do.


+  return KERN_SUCCESS;
+}



Thank you for the code view.

--
Zhaoming Luo

Can `hwclock` access /dev/rtc after /dev/rtc is added?

[Zhaoming Luo]

Hi,

I am trying to learn how to add the /dev/rtc device as it is in *Small 
hack entries* in https://darnassus.sceen.net/~hurd-web/contributing/. I 
found that `hwclock` command will try to detect /dev/rtc [1]. However, 
the probing work will only be done when the system-specific pre-defined 
macro `__linux__` is defined [2]. Gnu/Hurd does not have this macro [3]. 
The command `hwclock` is from utils-linux. I think utils-linux is used 
without any modifications because I didn't find a git for utils-linux of 
Gnu/Hurd on the git repositories 
. Does that mean `hwclock` will 
still not be able to access /dev/rtc after /dev/rtc is implemented?


[1]: 
https://github.com/util-linux/util-linux/blob/f1c26f0154ec683065109d776e65e568e3917c79/sys-utils/hwclock-rtc.c#L83-L124
[2]: 
https://github.com/util-linux/util-linux/blob/f1c26f0154ec683065109d776e65e568e3917c79/sys-utils/hwclock.c#L987-L990

[3]: https://sourceforge.net/p/predef/wiki/OperatingSystems/

Best,
Zhaoming

Re: [RFC PATCH] Adding RTC device (work in progress)

[Zhaoming Luo]

On 11/7/24 9:42 PM, Sergey Bugaev wrote:


Was the explanation clear enough / do you have follow-up questions?

Yeah it's clear and I haven't got any questions.


Have you made any progress on the RTC server?
I've applied the suggestions from you and Samuel. The rest of the stuff 
is mainly about filling codes into the server-side functions; it may 
require some time as I haven't had any experience of writing drivers. 
I'm reading the document suggested by Samuel to learn to do it. I just 
got my T60 and I would prefer developing the driver on the Hurd running 
on real hardware, so the time required may be longer (some time is 
required to set up the Hurd on the computer). Should I develop in qemu?


I will post a RTC patch series soon (I now have an account on another 
mail server which allows me to do it :)).


--
Zhaoming Luo

[PATCH Hurd]: adding a missing comment

[Zhaoming Luo]

Adding a line of missing comment ---diff --git a/hurd/iioctl.defs 
b/hurd/iioctl.defs index bd2c789f..58b7dbab 100644 --- 
a/hurd/iioctl.defs +++ b/hurd/iioctl.defs @@ -130,6 +130,7 @@ routine 
iioctl_siocgifnetmask ( skip; /* 38 SIOCGARP -- Not implemented yet */ 
+/* 39 SIOCGIFHWADDR */ routine iioctl_siocgifhwaddr ( reqport: io_t; 
inout ifnam: ifname_t;


--
Zhaoming Luo

Re: [PATCH hurd]: adding /dev/rtc device

[Zhaoming Luo]

On 10/24/24 10:12 AM, Zhaoming Luo wrote:


On 10/21/24 9:04 PM, Samuel Thibault wrote:

By implementing the corresponding RPC, whose msgid is given by the
IOC_MSGID macro. For instance for

RTC_RD_TIME._IOR('p', 0x09, struct rtc_time)

the group is 'p' and the command is 0x9, so the subsystem would be
14, and the exact RPC would be 140009.

I'm quite confused about the calculation of subsystem. May I have a more 
detailed process of how 14 is calculated? Including the names of the files 
in which macros is used in the calculation. Thank you


I just came across the definition in hurd/ioctls.defs :), it's (10 + 
((group) - 'f') * 4000).

Best,
Zhaoming

Errors while building gnu mach (2275d52...) from git source

[Zhaoming Luo]

Hi,

For testing, I'm trying to build gnu mach (2275d52...) from source by 
following the guide on this website 
<https://darnassus.sceen.net/~hurd-web/microkernel/mach/gnumach/building/>. 
I followed the path of building from the git repository. After I have a 
working MIG (either pre-built from apt or built from source), I run 
`make gnumach.gz`, then I get the following error messages:


```
In file included from ../linux/dev/include/linux/netdevice.h:30,
 from ../linux/dev/drivers/net/auto_irq.c:47:
../linux/dev/include/linux/if.h:148:17: error: unknown type name 'caddr_t'
  148 | caddr_t ifru_data;
  | ^~~
../linux/dev/include/linux/if.h:177:17: error: unknown type name 'caddr_t'
  177 | caddr_t ifcu_buf;
  | ^~~
make: *** [Makefile:6682: linux/dev/drivers/net/liblinux_a-auto_irq.o] 
Error 1


```

Did I misunderstand something?

Best

--
Zhaoming Luo

[RFC PATCH v2 4/4] Add rtc server

[Zhaoming Luo]

---
 rtc/Makefile | 19 +++
 rtc/main.c   | 88 
 rtc/mig-mutate.h |  4 +++
 rtc/pioctl-ops.c | 28 +++
 4 files changed, 139 insertions(+)
 create mode 100644 rtc/Makefile
 create mode 100644 rtc/main.c
 create mode 100644 rtc/mig-mutate.h
 create mode 100644 rtc/pioctl-ops.c

diff --git a/rtc/Makefile b/rtc/Makefile
new file mode 100644
index ..dd0e19d2
--- /dev/null
+++ b/rtc/Makefile
@@ -0,0 +1,19 @@
+dir := rtc
+makemode := server
+
+SRCS = main.c pioctl-ops.c
+MIGSRCS = pioctlServer.c
+
+OBJS = main.o pioctlServer.o pioctl-ops.o
+
+HURDLIBS = trivfs shouldbeinlibc ports
+
+target = rtc
+
+include ../Makeconf
+
+MIGCOMSFLAGS += -prefix rtc_
+mig-sheader-prefix = rtc_
+pioctl-MIGSFLAGS = -imacros $(srcdir)/mig-mutate.h
+
+rtc_pioctl_S.h pioctlServer.c: mig-mutate.h
diff --git a/rtc/main.c b/rtc/main.c
new file mode 100644
index ..114fb497
--- /dev/null
+++ b/rtc/main.c
@@ -0,0 +1,88 @@
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rtc_pioctl_S.h"
+
+const char *argp_program_version = STANDARD_HURD_VERSION (rtc);
+
+struct trivfs_control *rtccntl;
+
+int trivfs_fstype = FSTYPE_DEV;
+int trivfs_fsid = 0;
+int trivfs_support_read = 0;
+int trivfs_support_write = 0;
+int trivfs_support_exec = 0;
+int trivfs_allow_open = O_READ | O_WRITE;
+
+static const struct argp_option options[] =
+{
+  {0}
+};
+
+/* TODO: adding option */
+static error_t
+parse_opt (int opt, char *arg, struct argp_state *state)
+{
+  return ARGP_ERR_UNKNOWN;
+}
+
+static const struct argp rtc_argp =
+{ options, parse_opt, 0, "RTC device" };
+
+int
+demuxer (mach_msg_header_t *inp, mach_msg_header_t *outp)
+{
+  mig_routine_t routine;
+  if ((routine = rtc_pioctl_server_routine (inp)) ||
+  (routine = NULL, trivfs_demuxer (inp, outp)))
+{
+  if (routine)
+(*routine) (inp, outp);
+  return TRUE;
+}
+  else
+return FALSE;
+}
+
+int
+main (int argc, char **argv)
+{
+  error_t err;
+  mach_port_t bootstrap;
+
+  argp_parse (&rtc_argp, argc, argv, 0, 0, 0);
+
+  task_get_bootstrap_port (mach_task_self (), &bootstrap);
+  if (bootstrap == MACH_PORT_NULL)
+error (1, 0, "Must be started as a translator");
+
+  /* Reply to our parent */
+  err = trivfs_startup (bootstrap, 0, 0, 0, 0, 0, &rtccntl);
+  mach_port_deallocate (mach_task_self (), bootstrap);
+  if (err)
+error (1, err, "trivfs_startup failed");
+
+  /* Launch. */
+  ports_manage_port_operations_multithread (rtccntl->pi.bucket, demuxer,
+   30 * 1000, 2 * 60 * 1000, 0);
+
+  return 0;
+}
+
+void
+trivfs_modify_stat (struct trivfs_protid *cred, struct stat *st)
+{
+}
+
+error_t
+trivfs_goaway (struct trivfs_control *fsys, int flags)
+{
+  exit (0);
+}
diff --git a/rtc/mig-mutate.h b/rtc/mig-mutate.h
new file mode 100644
index ..cbf156c7
--- /dev/null
+++ b/rtc/mig-mutate.h
@@ -0,0 +1,4 @@
+#define IO_INTRAN trivfs_protid_t trivfs_begin_using_protid (io_t)
+#define IO_INTRAN_PAYLOAD trivfs_protid_t trivfs_begin_using_protid_payload
+#define IO_DESTRUCTOR trivfs_end_using_protid (trivfs_protid_t)
+#define PIOCTL_IMPORTS import "../libtrivfs/mig-decls.h";
diff --git a/rtc/pioctl-ops.c b/rtc/pioctl-ops.c
new file mode 100644
index ..44038e26
--- /dev/null
+++ b/rtc/pioctl-ops.c
@@ -0,0 +1,28 @@
+/* Server side implementation for rtc device */
+
+/* This implementation is largely based on sys-utils/hwclock from util-linux */
+
+#include "rtc_pioctl_S.h"
+#include 
+#include 
+
+/* 9 RTC_RD_TIME -- Read RTC time */
+kern_return_t
+rtc_S_pioctl_rtc_rd_time (struct trivfs_protid *cred, struct rtc_time *time)
+{
+  if (!cred) {
+return EOPNOTSUPP;
+  }
+  if (!(cred->po->openmodes & O_READ))
+return EBADF;
+  return KERN_SUCCESS;
+}
+
+/* 10 RTC_SET_TIME -- Set RTC time */
+kern_return_t
+rtc_S_pioctl_rtc_set_time (struct trivfs_protid *cred, struct rtc_time time)
+{
+  if (!(cred->po->openmodes & O_WRITE))
+return EBADF;
+  return KERN_SUCCESS;
+}
-- 
2.47.0

[RFC PATCH v2 2/4] Add ioctl interface for rtc device

[Zhaoming Luo]

---
 hurd/pioctl.defs | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 hurd/pioctl.defs

diff --git a/hurd/pioctl.defs b/hurd/pioctl.defs
new file mode 100644
index ..144ed14b
--- /dev/null
+++ b/hurd/pioctl.defs
@@ -0,0 +1,34 @@
+/* Definitions for /dev/rtc ioctls */
+
+/* Ioctl group 'p'; the subsystem is derived from calculations in
+   hurd/ioctls.defs. */
+subsystem pioctl 14;
+
+#include 
+
+import ;
+
+#ifdef PIOCTL_IMPORTS
+PIOCTL_IMPORTS
+#endif
+
+INTR_INTERFACE
+
+/* This is the arg for a struct rtc_time as specified by the
+   definition of _IOT_rtc_time in $(hurd)/rtc/rtc.h. */
+type rtc_time_t = struct[9] of int;
+
+/* TODO: adding other ioctl calls for /dev/rtc in mc146818rtc.h */
+skip; skip; skip; skip; /* 0 1 2 3 */
+skip; skip; skip; skip; /* 4 5 6 7 */
+skip; /* 8 */
+
+/* 9 RTC_RD_TIME */
+routine pioctl_rtc_rd_time (
+   reqport: io_t;
+   out time: rtc_time_t);
+
+/* 10 RTC_SET_TIME */
+routine pioctl_rtc_set_time (
+   reqport: io_t;
+   time: rtc_time_t);
-- 
2.47.0

[RFC PATCH v2 1/4] Add rtc server into compilation stage

[Zhaoming Luo]

---
 Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile
index 4d848221..8133c9e9 100644
--- a/Makefile
+++ b/Makefile
@@ -69,6 +69,8 @@ ifeq ($(HAVE_LIBACPICA),yes)
 prog-subdirs += acpi
 endif
 
+prog-subdirs += rtc
+
 # Other directories
 other-subdirs = hurd doc config release include
 
-- 
2.47.0

[RFC PATCH v2 0/4] Adding RTC device (work in progress)

[Zhaoming Luo]

This v2 patch series applys Sergey's and Samuel's suggestions. The
copyright headers have not been added because it is still work in
progress. The rest of the work is mainly about filling codes in
pioctl-ops.c.

Zhaoming Luo (4):
  Add rtc server into compilation stage
  Add ioctl interface for rtc device
  Add rtc interface
  Add rtc server

 Makefile |  2 ++
 hurd/pioctl.defs | 34 +++
 hurd/rtc.h   | 21 
 rtc/Makefile | 19 +++
 rtc/main.c   | 88 
 rtc/mig-mutate.h |  4 +++
 rtc/pioctl-ops.c | 28 +++
 7 files changed, 196 insertions(+)
 create mode 100644 hurd/pioctl.defs
 create mode 100644 hurd/rtc.h
 create mode 100644 rtc/Makefile
 create mode 100644 rtc/main.c
 create mode 100644 rtc/mig-mutate.h
 create mode 100644 rtc/pioctl-ops.c

-- 
2.47.0

[RFC PATCH v2 3/4] Add rtc interface

[Zhaoming Luo]

---
 hurd/rtc.h | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 hurd/rtc.h

diff --git a/hurd/rtc.h b/hurd/rtc.h
new file mode 100644
index ..957b13a0
--- /dev/null
+++ b/hurd/rtc.h
@@ -0,0 +1,21 @@
+#ifndef _RTC_H
+#define _RTC_H 1
+
+#include 
+
+struct rtc_time {
+   int tm_sec;
+   int tm_min;
+   int tm_hour;
+   int tm_mday;
+   int tm_mon;
+   int tm_year;
+   int tm_wday;
+   int tm_yday;
+   int tm_isdst;
+};
+typedef struct rtc_time rtc_time_t;
+
+#define _IOT_rtc_time _IOT(_IOTS(int),9,0,0,0,0)
+
+#endif /* rtc/rtc.h */
-- 
2.47.0

[PATCH hurd] Comment fixes

[Zhaoming Luo]

I don't think ioctls.h is a good place looking for the subsystem id
calculation, instead hurd/ioctls.defs, it contains the following codes:

```
/* Calculate the MiG subsystem (i.e. first message ID)
   for the RPCs produced by ioctl requests in the given group.  */
#define IOC_GROUP_SUBSYSTEM(group)  (10 + ((group) - 'f') * 4000)
```

---
 hurd/iioctl.defs  | 4 ++--
 hurd/kdioctl.defs | 4 ++--
 hurd/rioctl.defs  | 4 ++--
 hurd/tioctl.defs  | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/hurd/iioctl.defs b/hurd/iioctl.defs
index 58b7dbab..30087fea 100644
--- a/hurd/iioctl.defs
+++ b/hurd/iioctl.defs
@@ -17,8 +17,8 @@ You should have received a copy of the GNU General Public 
License
 along with the GNU Hurd; see the file COPYING.  If not, write to
 the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
 
-/* Ioctl class `i'; the subsystem is derived from calculations in
-   . */
+/* Ioctl class `i'; the subsystem is derived from IOC_GROUP_SUBSYSTEM in
+   hurd/ioctls.defs. */
 subsystem iioctl 112000; /* XXX */
 
 #include 
diff --git a/hurd/kdioctl.defs b/hurd/kdioctl.defs
index 0dd09d38..88f69496 100644
--- a/hurd/kdioctl.defs
+++ b/hurd/kdioctl.defs
@@ -17,8 +17,8 @@ You should have received a copy of the GNU General Public 
License
 along with the GNU Hurd; see the file COPYING.  If not, write to
 the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
 
-/* Ioctl class `k'; the subsystem is derived from calculations in
-   . */
+/* Ioctl class `k'; the subsystem is derived from IOC_GROUP_SUBSYSTEM in
+   hurd/ioctls.defs. */
 subsystem kdioctl 12;
 
 #include 
diff --git a/hurd/rioctl.defs b/hurd/rioctl.defs
index e04fe6b3..880c087a 100644
--- a/hurd/rioctl.defs
+++ b/hurd/rioctl.defs
@@ -18,8 +18,8 @@ along with the GNU Hurd; see the file COPYING.  If not, write 
to
 the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
 
 
-/* Ioctl class `r'; the subsystem is derived from calculations in
-   . */
+/* Ioctl class `r'; the subsystem is derived from IOC_GROUP_SUBSYSTEM in
+   hurd/ioctls.defs. */
 subsystem rioctl 148000; /* XXX */
 
 #include 
diff --git a/hurd/tioctl.defs b/hurd/tioctl.defs
index 905a4a38..74af62e2 100644
--- a/hurd/tioctl.defs
+++ b/hurd/tioctl.defs
@@ -17,8 +17,8 @@ You should have received a copy of the GNU General Public 
License
 along with the GNU Hurd; see the file COPYING.  If not, write to
 the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
 
-/* Ioctl class `t'; the subsystem is derived from calculations in
-   . */
+/* Ioctl class `t'; the subsystem is derived from IOC_GROUP_SUBSYSTEM in
+   hurd/ioctls.defs. */
 subsystem tioctl 156000; /* XXX */
 
 #include 
-- 
2.47.0

[PATCH v3] Add rtc-cmos translator for accessing CMOS Real-Time Clock device

[Zhaoming Luo]

A translator will be created as /hurd/rtc-cmos, users can create a
/dev/rtc device using the following command:
```
sudo settrans -c /dev/rtc /hurd/rtc-cmos
```

* Makefile: add rtc-cmos server into the compile chain
* hurd/pioctl.defs: new file. Interfaces for rtc ioctl operations
* hurd/rtc.h: new file. Interfaces for rtc device
* rtc-cmos/Makefile: new file. Makefile for rtc-cmos server
* rtc-cmos/main.c: new file. Initialisation for rtc-cmos translator
* rtc-cmos/mig-mutate.h: new file. Type translation for rtc-cmos server
* rtc-cmos/pioctl-ops.c: new file. The rtc-cmos server side implementation

---
 Makefile  |   3 +-
 hurd/pioctl.defs  |  51 
 hurd/rtc.h|  45 
 rtc-cmos/Makefile |  39 +++
 rtc-cmos/main.c   | 104 +
 rtc-cmos/mig-mutate.h |  24 
 rtc-cmos/pioctl-ops.c | 263 ++
 7 files changed, 528 insertions(+), 1 deletion(-)
 create mode 100644 hurd/pioctl.defs
 create mode 100644 hurd/rtc.h
 create mode 100644 rtc-cmos/Makefile
 create mode 100644 rtc-cmos/main.c
 create mode 100644 rtc-cmos/mig-mutate.h
 create mode 100644 rtc-cmos/pioctl-ops.c

diff --git a/Makefile b/Makefile
index 4d848221..d7cab34c 100644
--- a/Makefile
+++ b/Makefile
@@ -47,7 +47,8 @@ prog-subdirs = auth proc exec term \
   init \
   devnode \
   eth-multiplexer \
-  shutdown
+  shutdown \
+  rtc-cmos
 
 ifeq ($(HAVE_LIBRUMP),yes)
 prog-subdirs += rumpdisk
diff --git a/hurd/pioctl.defs b/hurd/pioctl.defs
new file mode 100644
index ..f6b7b3a6
--- /dev/null
+++ b/hurd/pioctl.defs
@@ -0,0 +1,51 @@
+/* Definitions for /dev/rtc ioctls
+
+   Copyright (C) 2024 Free Software Foundation, Inc.
+
+   This file is part of the GNU Hurd.
+
+   The GNU Hurd is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License as
+   published by the Free Software Foundation; either version 2, or (at
+   your option) any later version.
+
+   The GNU Hurd is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111, USA. */
+
+/* Ioctl group 'p'; the subsystem is derived from calculations in
+   hurd/ioctls.defs. */
+subsystem pioctl 14;
+
+#include 
+
+import ;
+
+#ifdef PIOCTL_IMPORTS
+PIOCTL_IMPORTS
+#endif
+
+INTR_INTERFACE
+
+/* This is the arg for a struct rtc_time as specified by the
+   definition of _IOT_rtc_time in $(hurd)/hurd/rtc.h. */
+type rtc_time_t = struct[9] of int;
+
+skip; skip; skip; skip; /* 0 1 2 3 */
+skip; skip; skip; skip; /* 4 5 6 7 */
+skip; /* 8 */
+
+/* 9 RTC_RD_TIME */
+routine pioctl_rtc_rd_time (
+   reqport: io_t;
+   out tm: rtc_time_t);
+
+/* 10 RTC_SET_TIME */
+routine pioctl_rtc_set_time (
+   reqport: io_t;
+   tm: rtc_time_t);
diff --git a/hurd/rtc.h b/hurd/rtc.h
new file mode 100644
index ..12ca7531
--- /dev/null
+++ b/hurd/rtc.h
@@ -0,0 +1,45 @@
+/* GNU Hurd RTC interface
+
+   Copyright (C) 2024 Free Software Foundation, Inc.
+
+   This file is part of the GNU Hurd.
+
+   The GNU Hurd is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License as
+   published by the Free Software Foundation; either version 2, or (at
+   your option) any later version.
+
+   The GNU Hurd is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111, USA. */
+
+#ifndef _RTC_H
+#define _RTC_H 1
+
+#include 
+
+struct rtc_time
+{
+  int tm_sec;
+  int tm_min;
+  int tm_hour;
+  int tm_mday;
+  int tm_mon;
+  int tm_year;
+  int tm_wday;
+  int tm_yday;
+  int tm_isdst;
+};
+typedef struct rtc_time rtc_time_t;
+
+#define _IOT_rtc_time _IOT(_IOTS(int),9,0,0,0,0)
+
+#define RTC_RD_TIME_IOR('p', 0x09, struct rtc_time) /* Read RTC time.  */
+#define RTC_SET_TIME   _IOW('p', 0x0a, struct rtc_time) /* Set RTC time.  */
+
+#endif /* rtc.h */
diff --git a/rtc-cmos/Makefile b/rtc-cmos/Makefile
new file mode 100644
index ..22efa6ca
--- /dev/null
+++ b/rtc-cmos/Makefile
@@ -0,0 +1,39 @@
+#   Makefile for rtc-cmos server
+#
+#   Copyright (C) 2024 Free Software Foundation, Inc.
+#
+#   This file is part of the GNU Hurd.
+#
+#   The GNU Hurd is free software; you can

Re: [RFC PATCH] Add rtc server, rtc-read and rtc-set operations

[Zhaoming Luo]

First of all, thanks for the code review.

On 11/17/24 9:04 PM, Sergey Bugaev wrote:

On Sun, Nov 17, 2024 at 3:34 PM Zhaoming Luo  wrote:

diff --git a/hurd/rtc.h b/hurd/rtc.h
new file mode 100644
index ..6516e86c
--- /dev/null
+++ b/hurd/rtc.h



+struct rtc_time {
+  int tm_sec;
+  int tm_min;
+  int tm_hour;
+  int tm_mday;
+  int tm_mon;
+  int tm_year;
+  int tm_wday;
+  int tm_yday;
+  int tm_isdst;
+};


Nitpick: please see how struct definitions should be formatted
according to the GNU code style [0].

OK


[0]: https://www.gnu.org/prep/standards/html_node/Formatting.html#Formatting


diff --git a/rtc/main.c b/rtc/main.c
new file mode 100644
index ..daefb95d
--- /dev/null
+++ b/rtc/main.c



+static const struct argp rtc_argp =
+{ options, parse_opt, 0, "RTC device" };


This would probably be a good place to spell out that RTC stands for
real time clock?

Indeed, "Real-Time Clock device" is employed.



+int
+main (int argc, char **argv)
+{
+  error_t err;
+  mach_port_t bootstrap;
+
+  argp_parse (&rtc_argp, argc, argv, 0, 0, 0);
+
+  task_get_bootstrap_port (mach_task_self (), &bootstrap);
+  if (bootstrap == MACH_PORT_NULL)
+error (1, 0, "Must be started as a translator");
+
+  /* Reply to our parent */
+  err = trivfs_startup (bootstrap, O_NORW, NULL, NULL, NULL, NULL, &rtccntl);
+  mach_port_deallocate (mach_task_self (), bootstrap);
+  if (err)
+error (1, err, "trivfs_startup failed");
+
+  /* Request for permission to do i/o on port numbers 0x70 and 0x71 for
+ accessing RTC registers. */
+  err = ioperm (0x70, 2, true);
+  if (err)
+error (1, err, "Request IO permission failed");


It's probably a good idea to do this before you reply to the parent,
so you don't end up saying "I'm ready!" and then immediately exit with
an error.
OK. I think it can explain why when I settrans rtc to /tmp/rtc without 
sudo will cause `ls /tmp/` hanging. After I swap the position of "Replay 
to our parent" and "Request for permission", `ls /tmp/` does not hang, 
instead ls gives me "cannot access '/tmp/rtc': Translator died" error. 
Interesting.



+error_t
+trivfs_goaway (struct trivfs_control *fsys, int flags)
+{
+  exit (0);
+}


Do you need to do anything to the RTC hardware before you exit to
leave it in a good/well-defined state? Especially if other threads are
accessing it at the same time? (Perhaps not, I don't know.)

I don't think I need to do anything before exit. However, maybe I need 
to ensure the rtc operations is thread-safe; I haven't done it. It seems 
util-linux tried to implement thread-safe functionality[0], but it seems 
they didn't do it right[1].


[0]:https://github.com/util-linux/util-linux/blob/master/sys-utils/hwclock-cmos.c#L207-L215
[1]:https://github.com/util-linux/util-linux/blob/master/sys-utils/hwclock-cmos.c#L90-L94

I will do some experiments to see whether two threads setting rtc causes 
data race before implement thread-safe functionality.

diff --git a/rtc/pioctl-ops.c b/rtc/pioctl-ops.c
new file mode 100644
index ..c33403c8
--- /dev/null
+++ b/rtc/pioctl-ops.c
@@ -0,0 +1,223 @@
+/* Server side implementation for rtc server
+
+   Copyright (C) 2024 Free Software Foundation, Inc.
+
+   This file is part of the GNU Hurd.
+
+   The GNU Hurd is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License as
+   published by the Free Software Foundation; either version 2, or (at
+   your option) any later version.
+
+   The GNU Hurd is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111, USA. */
+
+/* This implementation is largely based on sys-utils/hwclock-cmos.c from
+   util-linux */
+
+/* A struct tm has int fields (it is defined in POSIX)
+   tm_sec  0-59, 60 or 61 only for leap seconds
+   tm_min  0-59
+   tm_hour 0-23
+   tm_mday 1-31
+   tm_mon  0-11
+   tm_year number of years since 1900
+   tm_wday 0-6, 0=Sunday
+   tm_yday 0-365
+   tm_isdst>0: yes, 0: no, <0: unknown */
+
+#include "rtc_pioctl_S.h"
+#include 
+#include 
+#include 
+#include 
+
+/* Conversions to and from RTC internal format */
+#define BCD_TO_BIN(val) ((val)=((val)&15) + ((val)>>4)*10)
+#define BIN_TO_BCD(val) ((val)=(((val)/10)<<4) + (val)%10)
+
+/* POSIX uses 1900 as epoch for a struct tm, and 1970 for a time_t. */
+#define TM_EPOCH 1900
+
+static unsigned short clock_ctl_addr = 0x70;
+static unsigned short clock_d

Re: [RFC PATCH] Add rtc server, rtc-read and rtc-set operations

[Zhaoming Luo]

On 11/19/24 5:08 PM, Samuel Thibault wrote:

Zhaoming Luo, le mar. 19 nov. 2024 16:54:38 +0800, a ecrit:

On 11/17/24 9:04 PM, Sergey Bugaev wrote:
I don't think I need to do anything before exit. However, maybe I need to
ensure the rtc operations is thread-safe; I haven't done it.


Ah, yes. Since it's not a performance-critical service, you can as well
use ports_manage_port_operations_one_thread instead, and get done with
it :)

Indeed, I will employ ports_manage_port_operations_one_thread.



I will do some experiments to see whether two threads setting rtc causes
data race


It will since cmos access requires two outb calls, but it'll be very
hard to reproduce.

OK, remove it from my TODO list.



+  The following flags have to be released exactly in this order,
+  otherwise the DS12887 (popular MC146818A clone with integrated
+  battery and quartz) will not reset the oscillator and will not
+  update precisely 500 ms later. You won't find this mentioned in
+  the Dallas Semiconductor data sheets, but who believes data
+  sheets anyway ... -- Markus Kuhn */
+  cmos_write(11, save_control);
+  cmos_write(10, save_freq_select);


Can these writes somehow fail, and if so, can you detect it and report
the error? (I've no idea.)

I think the only way to check is reading rtc between `cmos_write(9,
tm.tm_year);` and `cmos_write(11, save_control);`; then compare the values
we just read with the values for setting.


I don't think it is useful to do this. Nowadays RTC is not even a
separate chip, we won't have any issue.

OK, remove it from my TODO list.

--
Zhaoming Luo

Re: [RFC PATCH] Add rtc server, rtc-read and rtc-set operations

[Zhaoming Luo]

On 11/17/24 9:04 PM, Sergey Bugaev wrote:

On Sun, Nov 17, 2024 at 3:34 PM Zhaoming Luo  wrote:

looks nice to me overall, thanks for working on this! I cannot judge
the actual driver part, so here are some nitpicks about not following
the GNU code style :D I will try to build and test it later.
Thanks for the review. This patch has some issues, and it can't be 
applied correctly. I will send another patch after I do some improvement.


I'm still reading the code review email. I got a question.

Is there any style checker recommended? I haven't got used to GNU C 
Style Coding. I think a style checker can help me a lot.


--
Zhaoming Luo

[RFC PATCH v2] Add rtc server, rtc-read and rtc-set operations

[Zhaoming Luo]

Some coding style fixes. The rtc read operation can calculate day of year
based on month, day of month and year. Use only one thread for accessing
rtc to avoid data race.

* Makefile: add rtc server into the compile chain
* hurd/pioctl.defs: new file. Interfaces for rtc ioctl operations
* hurd/rtc.h: new file. Interfaces for rtc device
* rtc/Makefile: new file. Makefile for rtc server
* rtc/main.c: new file. Initialisation for rtc translator
* rtc/mig-mutate.h: new file. Type translation for rtc server
* rtc/pioctl-ops.c: new file. The rtc server side implementation
* sutils/MAKEDEV.sh: create rtc device at startup

---
 Makefile  |   3 +-
 hurd/pioctl.defs  |  52 +
 hurd/rtc.h|  45 
 rtc/Makefile  |  39 +++
 rtc/main.c| 104 ++
 rtc/mig-mutate.h  |  24 +
 rtc/pioctl-ops.c  | 268 ++
 sutils/MAKEDEV.sh |   4 +-
 8 files changed, 537 insertions(+), 2 deletions(-)
 create mode 100644 hurd/pioctl.defs
 create mode 100644 hurd/rtc.h
 create mode 100644 rtc/Makefile
 create mode 100644 rtc/main.c
 create mode 100644 rtc/mig-mutate.h
 create mode 100644 rtc/pioctl-ops.c

diff --git a/Makefile b/Makefile
index 4d848221..9d9e33c3 100644
--- a/Makefile
+++ b/Makefile
@@ -47,7 +47,8 @@ prog-subdirs = auth proc exec term \
   init \
   devnode \
   eth-multiplexer \
-  shutdown
+  shutdown \
+  rtc
 
 ifeq ($(HAVE_LIBRUMP),yes)
 prog-subdirs += rumpdisk
diff --git a/hurd/pioctl.defs b/hurd/pioctl.defs
new file mode 100644
index ..307d9ee9
--- /dev/null
+++ b/hurd/pioctl.defs
@@ -0,0 +1,52 @@
+/* Definitions for /dev/rtc ioctls
+
+   Copyright (C) 2024 Free Software Foundation, Inc.
+
+   This file is part of the GNU Hurd.
+
+   The GNU Hurd is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License as
+   published by the Free Software Foundation; either version 2, or (at
+   your option) any later version.
+
+   The GNU Hurd is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111, USA. */
+
+/* Ioctl group 'p'; the subsystem is derived from calculations in
+   hurd/ioctls.defs. */
+subsystem pioctl 14;
+
+#include 
+
+import ;
+
+#ifdef PIOCTL_IMPORTS
+PIOCTL_IMPORTS
+#endif
+
+INTR_INTERFACE
+
+/* This is the arg for a struct rtc_time as specified by the
+   definition of _IOT_rtc_time in $(hurd)/hurd/rtc.h. */
+type rtc_time_t = struct[9] of int;
+
+/* TODO: adding other ioctl calls for /dev/rtc in mc146818rtc.h */
+skip; skip; skip; skip; /* 0 1 2 3 */
+skip; skip; skip; skip; /* 4 5 6 7 */
+skip; /* 8 */
+
+/* 9 RTC_RD_TIME */
+routine pioctl_rtc_rd_time (
+   reqport: io_t;
+   out tm: rtc_time_t);
+
+/* 10 RTC_SET_TIME */
+routine pioctl_rtc_set_time (
+   reqport: io_t;
+   tm: rtc_time_t);
diff --git a/hurd/rtc.h b/hurd/rtc.h
new file mode 100644
index ..12ca7531
--- /dev/null
+++ b/hurd/rtc.h
@@ -0,0 +1,45 @@
+/* GNU Hurd RTC interface
+
+   Copyright (C) 2024 Free Software Foundation, Inc.
+
+   This file is part of the GNU Hurd.
+
+   The GNU Hurd is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License as
+   published by the Free Software Foundation; either version 2, or (at
+   your option) any later version.
+
+   The GNU Hurd is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111, USA. */
+
+#ifndef _RTC_H
+#define _RTC_H 1
+
+#include 
+
+struct rtc_time
+{
+  int tm_sec;
+  int tm_min;
+  int tm_hour;
+  int tm_mday;
+  int tm_mon;
+  int tm_year;
+  int tm_wday;
+  int tm_yday;
+  int tm_isdst;
+};
+typedef struct rtc_time rtc_time_t;
+
+#define _IOT_rtc_time _IOT(_IOTS(int),9,0,0,0,0)
+
+#define RTC_RD_TIME_IOR('p', 0x09, struct rtc_time) /* Read RTC time.  */
+#define RTC_SET_TIME   _IOW('p', 0x0a, struct rtc_time) /* Set RTC time.  */
+
+#endif /* rtc.h */
diff --git a/rtc/Makefile b/rtc/Makefile
new file mode 100644
index ..e84d9c14
--- /dev/null
+++ b/rtc/Makefile
@@ -0,0 +1,39 @@
+#   Makefile for rtc server
+#
+#   Copyright (C) 2024 Free Software Foundation, Inc.
+#
+#   This file is part of the GNU Hurd.

Re: [RFC PATCH] Adding RTC device (work in progress)

[Zhaoming Luo]

On 11/9/24 10:58 PM, Sergey Bugaev wrote:

I know that RTC can be configured to either represent local time, or
in UTC. MS Windows prefers the former, GNU/Linux (or rather systemd?)
prefers the latter [6]. Would it maybe make sense for the driver to
have an --option to *pretend* the RTC stores UTC time when it's
actually storing local time, transparently converting the time on
read/write? The driver would learn the local timezone the same way all
processes do (tzset?).

[6]: https://wiki.archlinux.org/title/System_time

I think we don't need to add an option to pretend the RTC stores UTC 
time when it's actually storing local time, because I think the Hurd 
expects RTC storing UTC time.As mentioned in [6], 'The standard used by 
the hardware clock (CMOS clock, the BIOS time) is set by the operating 
system'. I did the following experiments in the virtual machine:


I changed the timezone to Chongqing:
```
sudo rm /etc/localtime
sudo ln -s /usr/share/zoneinfo/Asia/Chongqing /etc/localtime
```
Running `date` to get the following output:
```
Wed Nov 20 19:55:58 CST 2024
```
When I reboot the virtual machine I saw a line of log saying `saving 
system time to CMOS clock`.


After the reboot I setup the rtc translator and used the following 
program to read rtc. The time I read is UTC time, and the timezone I got 
by running `date` is still Chongqing. Therefore, I think the RTC time is 
independent of timezone for the Hurd.


This program reads the /tmp/rtc. (Please ignore the coding style :P, it 
was written before I started being aware of GNU coding style)

```
#include 
#include 
#include 
#include 

struct rtc_time {
int tm_sec;
int tm_min;
int tm_hour;
int tm_mday;
int tm_mon;
int tm_year;
int tm_wday;
int tm_yday;
int tm_isdst;
};

#define RTC_RD_TIME _IOR('p', 0x09, struct rtc_time)
#define _IOT_rtc_time _IOT(_IOTS(int),9,0,0,0,0)

int main() {
int fd = open("/tmp/rtc", O_RDONLY);
if (fd == -1) {
printf("Cannot open rtc!\n");
return 1;
}
printf("The fd of rtc is %d\n", fd);

struct rtc_time time;
int err = ioctl(fd, RTC_RD_TIME, &time);
if (err == -1) {
printf ("ioctl error!\n");
return 1;
}
printf("tm_sec  : %d\n", time.tm_sec  );
printf("tm_min  : %d\n", time.tm_min  );
printf("tm_hour : %d\n", time.tm_hour );
printf("tm_mday : %d\n", time.tm_mday );
printf("tm_mon  : %d\n", time.tm_mon  );
printf("tm_year : %d\n", time.tm_year );
printf("tm_wday : %d\n", time.tm_wday );
printf("tm_yday : %d\n", time.tm_yday );
printf("tm_isdst: %d\n", time.tm_isdst);

return 0;
}

```


--
Zhaoming Luo

Re: [RFC PATCH v2 2/4] Add ioctl interface for rtc device

[Zhaoming Luo]

On 11/8/24 4:48 PM, Sergey Bugaev wrote:

Hi Zhaoming,

Hi


On Fri, Nov 8, 2024 at 11:01 AM Samuel Thibault  wrote:

Here as well this breaks the build since at this point of the series you
haven't added rtc.h yet. Better just merge all the patches.


To expand on what Samuel says, the point is that the repo is expected
to build successfully if you check out any specific Git commit. This
is helpful for using 'git bisect' in particular to catch regressions
[0], but is also generally a good practice. You might call it a part
of Git hygiene.

So not only are you expected to split your diff into a set of
reasonably-sized, self-sufficient, reviewable patches; you should also
consider the dependencies between your changes, and commit them in the
right order.

I didn't realise it. I will try to get used to it.


But for your case here, you can just squash the patches into one.

OK
--
Zhaoming Luo

[RFC PATCH util-linux] Support hwclock read and set operations for Hurd

[Zhaoming Luo]

From: Zhaoming Luo 

* configure.ac: add HURD conditional for meson build
* sys-utils/Makemodule.am: compile hurd-specific rtc device operations
* sys-utils/hurd-hwclock-rtc.c: new file, hurd-specific rtc device
* operations
* sys-utils/hwclock.c: add --rtc option and probe_for_rtc_clock for hwclock in 
Hurd
* sys-utils/hwclock.h: add variable for storing rtc device name in Hurd

---
 configure.ac |   6 +-
 sys-utils/Makemodule.am  |   4 +
 sys-utils/hurd-hwclock-rtc.c | 193 +++
 sys-utils/hwclock.c  |   8 +-
 sys-utils/hwclock.h  |   3 +
 5 files changed, 209 insertions(+), 5 deletions(-)
 create mode 100644 sys-utils/hurd-hwclock-rtc.c

diff --git a/configure.ac b/configure.ac
index 698da36..8de6af6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -263,16 +263,20 @@ AC_PATH_PROG([XSLTPROC], [xsltproc])
 
 linux_os=no
 bsd_os=no
+gnu_os=no
 AS_CASE([${host_os}],
   [*linux*],
  [linux_os=yes],
   [*darwin*],
  [darwin_os=yes],
   [*bsd*],
- [bsd_os=yes])
+ [bsd_os=yes],
+  [gnu*],
+ [gnu_os=yes])
 AM_CONDITIONAL([LINUX], [test "x$linux_os" = xyes])
 AM_CONDITIONAL([DARWIN], [test "x$darwin_os" = xyes])
 AM_CONDITIONAL([BSD], [test "x$bsd_os" = xyes])
+AM_CONDITIONAL([HURD], [test "x$gnu_os" = xyes])
 
 AS_IF([test  "x$darwin_os" = xyes], [
   AC_DEFINE([_DARWIN_C_SOURCE], [1], [Enable MAP_ANON in sys/mman.h on Mac OS 
X])
diff --git a/sys-utils/Makemodule.am b/sys-utils/Makemodule.am
index 209b656..7582106 100644
--- a/sys-utils/Makemodule.am
+++ b/sys-utils/Makemodule.am
@@ -570,6 +570,10 @@ hwclock_SOURCES += \
lib/monotonic.c
 hwclock_LDADD += $(REALTIME_LIBS)
 endif
+if HURD
+hwclock_SOURCES += \
+   sys-utils/hurd-hwclock-rtc.c
+endif
 if HAVE_AUDIT
 hwclock_LDADD += -laudit
 endif
diff --git a/sys-utils/hurd-hwclock-rtc.c b/sys-utils/hurd-hwclock-rtc.c
new file mode 100644
index 000..4c388fe
--- /dev/null
+++ b/sys-utils/hurd-hwclock-rtc.c
@@ -0,0 +1,193 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * hurd-hwclock-rtc.c - Use /dev/rtc for clock access in GNU Hurd
+ */
+#include 
+#include 
+
+#include "hwclock.h"
+
+/* default or user defined dev (by hwclock --rtc=) */
+static const char *rtc_dev_name;
+static int rtc_dev_fd = -1;
+
+static void close_rtc(void)
+{
+   if (rtc_dev_fd != -1)
+   close(rtc_dev_fd);
+   rtc_dev_fd = -1;
+}
+
+static int open_rtc(const struct hwclock_control *ctl)
+{
+   static const char * const fls[] = {
+#ifdef __ia64__
+   "/dev/efirtc",
+   "/dev/misc/efirtc",
+#endif
+   "/dev/rtc0",
+   "/dev/rtc",
+   "/dev/misc/rtc"
+   };
+   size_t i;
+
+   if (rtc_dev_fd != -1)
+   return rtc_dev_fd;
+
+   /* --rtc option has been given */
+   if (ctl->rtc_dev_name) {
+   rtc_dev_name = ctl->rtc_dev_name;
+   rtc_dev_fd = open(rtc_dev_name, O_RDONLY | O_WRONLY);
+   } else {
+   for (i = 0; i < ARRAY_SIZE(fls); i++) {
+   if (ctl->verbose)
+   printf(_("Trying to open: %s\n"), fls[i]);
+   rtc_dev_fd = open(fls[i], O_RDONLY | O_WRONLY);
+
+   if (rtc_dev_fd < 0) {
+   if (errno == ENOENT || errno == ENODEV)
+   continue;
+   if (ctl->verbose)
+   warn(_("cannot open %s"), fls[i]);
+   }
+   rtc_dev_name = fls[i];
+   break;
+   }
+   if (rtc_dev_fd < 0)
+   rtc_dev_name = *fls;/* default for error messages */
+   }
+   if (rtc_dev_fd != -1)
+   atexit(close_rtc);
+   return rtc_dev_fd;
+}
+
+/*
+ * Not yet implemented
+ */
+static int synchronize_to_clock_tick_rtc([[maybe_unused]] const struct 
hwclock_control *ctl)
+{
+   return 0;
+}
+
+static int open_rtc_or_exit(const struct hwclock_control *ctl)
+{
+   int rtc_fd = open_rtc(ctl);
+
+   if (rtc_fd < 0) {
+   warn(_("cannot open rtc device"));
+   hwclock_exit(ctl, EXIT_FAILURE);
+   }
+   return rtc_fd;
+}
+
+static int do_rtc_read_ioctl(int rtc_fd, struct tm *tm)
+{
+   int rc = -1;
+   struct rtc_time rtc_tm = { 0 };
+
+   rc = ioctl(rtc_fd, RTC_RD_TIME, &rtc_tm);
+
+   if (rc == -1) {
+   warn(_("ioctl(RTC_RD_N

[PATCH Hurd] Add rtc translator and RTC CMOS driver

[Zhaoming Luo]

A translator will be created as /hurd/rtc-cmos, users can create a
/dev/rtc device using the following command:
```
sudo settrans -c /dev/rtc /hurd/rtc-cmos
```

* Makefile: add rtc-cmos server into the compile chain
* hurd/pioctl.defs: new file. Interfaces for rtc ioctl operations
* hurd/rtc.h: new file. Interfaces for rtc device
* rtc/Makefile: new file. Makefile for rtc server
* rtc/main.c: new file. Initialisation for rtc translator
* rtc/mig-mutate.h: new file. Type translation for rtc server
* rtc/rtc-cmos_pioctl-ops.c: new file. The rtc-cmos server side implementation

---
 Makefile  |   3 +-
 hurd/pioctl.defs  |  51 
 hurd/rtc.h|  45 +++
 rtc/Makefile  |  39 ++
 rtc/main.c| 104 +++
 rtc/mig-mutate.h  |  24 
 rtc/rtc-cmos_pioctl-ops.c | 262 ++
 7 files changed, 527 insertions(+), 1 deletion(-)
 create mode 100644 hurd/pioctl.defs
 create mode 100644 hurd/rtc.h
 create mode 100644 rtc/Makefile
 create mode 100644 rtc/main.c
 create mode 100644 rtc/mig-mutate.h
 create mode 100644 rtc/rtc-cmos_pioctl-ops.c

diff --git a/Makefile b/Makefile
index 4d848221..9d9e33c3 100644
--- a/Makefile
+++ b/Makefile
@@ -47,7 +47,8 @@ prog-subdirs = auth proc exec term \
   init \
   devnode \
   eth-multiplexer \
-  shutdown
+  shutdown \
+  rtc
 
 ifeq ($(HAVE_LIBRUMP),yes)
 prog-subdirs += rumpdisk
diff --git a/hurd/pioctl.defs b/hurd/pioctl.defs
new file mode 100644
index ..f6b7b3a6
--- /dev/null
+++ b/hurd/pioctl.defs
@@ -0,0 +1,51 @@
+/* Definitions for /dev/rtc ioctls
+
+   Copyright (C) 2024 Free Software Foundation, Inc.
+
+   This file is part of the GNU Hurd.
+
+   The GNU Hurd is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License as
+   published by the Free Software Foundation; either version 2, or (at
+   your option) any later version.
+
+   The GNU Hurd is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111, USA. */
+
+/* Ioctl group 'p'; the subsystem is derived from calculations in
+   hurd/ioctls.defs. */
+subsystem pioctl 14;
+
+#include 
+
+import ;
+
+#ifdef PIOCTL_IMPORTS
+PIOCTL_IMPORTS
+#endif
+
+INTR_INTERFACE
+
+/* This is the arg for a struct rtc_time as specified by the
+   definition of _IOT_rtc_time in $(hurd)/hurd/rtc.h. */
+type rtc_time_t = struct[9] of int;
+
+skip; skip; skip; skip; /* 0 1 2 3 */
+skip; skip; skip; skip; /* 4 5 6 7 */
+skip; /* 8 */
+
+/* 9 RTC_RD_TIME */
+routine pioctl_rtc_rd_time (
+   reqport: io_t;
+   out tm: rtc_time_t);
+
+/* 10 RTC_SET_TIME */
+routine pioctl_rtc_set_time (
+   reqport: io_t;
+   tm: rtc_time_t);
diff --git a/hurd/rtc.h b/hurd/rtc.h
new file mode 100644
index ..12ca7531
--- /dev/null
+++ b/hurd/rtc.h
@@ -0,0 +1,45 @@
+/* GNU Hurd RTC interface
+
+   Copyright (C) 2024 Free Software Foundation, Inc.
+
+   This file is part of the GNU Hurd.
+
+   The GNU Hurd is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License as
+   published by the Free Software Foundation; either version 2, or (at
+   your option) any later version.
+
+   The GNU Hurd is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111, USA. */
+
+#ifndef _RTC_H
+#define _RTC_H 1
+
+#include 
+
+struct rtc_time
+{
+  int tm_sec;
+  int tm_min;
+  int tm_hour;
+  int tm_mday;
+  int tm_mon;
+  int tm_year;
+  int tm_wday;
+  int tm_yday;
+  int tm_isdst;
+};
+typedef struct rtc_time rtc_time_t;
+
+#define _IOT_rtc_time _IOT(_IOTS(int),9,0,0,0,0)
+
+#define RTC_RD_TIME_IOR('p', 0x09, struct rtc_time) /* Read RTC time.  */
+#define RTC_SET_TIME   _IOW('p', 0x0a, struct rtc_time) /* Set RTC time.  */
+
+#endif /* rtc.h */
diff --git a/rtc/Makefile b/rtc/Makefile
new file mode 100644
index ..ce32de4c
--- /dev/null
+++ b/rtc/Makefile
@@ -0,0 +1,39 @@
+#   Makefile for rtc server
+#
+#   Copyright (C) 2024 Free Software Foundation, Inc.
+#
+#   This file is part of the GNU Hurd.
+#
+#   The GNU Hurd is free software; you can redistribute it and/or
+#   modify it und

Re: [RFC PATCH util-linux] Support hwclock read and set operations for Hurd

[Zhaoming Luo]

On 12/2/24 10:12 AM, Samuel Thibault wrote:

Hello,

Hi,

Zhaoming Luo, le lun. 02 déc. 2024 10:06:48 +0800, a ecrit:


+static void close_rtc(void)
+{

[...]

+}
+
+static int open_rtc(const struct hwclock_control *ctl)
+{

[...]

+}
+



+static int open_rtc_or_exit(const struct hwclock_control *ctl)
+{

[...]

+}
+
+static int do_rtc_read_ioctl(int rtc_fd, struct tm *tm)
+{

[...]

+}
+
+static int read_hardware_clock_rtc(const struct hwclock_control *ctl,
+  struct tm *tm)
+{

[...]

+}
+
+/*
+ * Set the Hardware Clock to the broken down time . Use
+ * ioctls to "rtc" device /dev/rtc.
+ */
+static int set_hardware_clock_rtc(const struct hwclock_control *ctl,
+ const struct tm *new_broken_time)
+{

[...]

+}


Please factorize these with the linux port, by putting them into a
shared file that is linked-in in both ports cases.

Do you mean having the following structure?
 /- hurd-hwlock-rtc.c \
hwclock.c   hwclock-rtc.c
 \- linux-hwlock-rtc.c /

hwclock-rtc.c contains close_rtc, open_rtc, etc.
--
Zhaoming Luo

Re: [RFC PATCH v2] Add rtc server, rtc-read and rtc-set operations

[Zhaoming Luo]

Thanks for the review

On 11/25/24 8:57 AM, Samuel Thibault wrote:



This looks good.  The last step is then to update util-linux to use
it.  The code from sys-utils/hwclock-rtc.c (read_hardware_clock_rtc,
set_hardware_clock_rtc) can be moved out to another file, that a hurd
version could use (you'd add a "HURD =" line along the LINUX and BSD
ones in meson.build:130).  And you should then be able to play with
hwclock to manipulate the RTC.



I will do it, but before it I still have a few questions (listing below 
with the source code). I will change the name of the translator to 
rtc-cmos because I just realised there are many other rtc drivers, 
calling it 'rtc' is too generic.



diff --git a/sutils/MAKEDEV.sh b/sutils/MAKEDEV.sh
index c3d7d112..c1ef4f92 100644
--- a/sutils/MAKEDEV.sh
+++ b/sutils/MAKEDEV.sh
@@ -120,10 +120,12 @@ mkdev() {
;;
  
std)

-   mkdev console tty random urandom null zero full fd time mem klog shm
+   mkdev console tty random urandom null zero full fd time mem klog shm rtc
;;
console|com[0-9])
st $I root 600 c /hurd/term ${DEVDIR}/$I device $I;;
+  rtc)
+   st $I root 644 c /hurd/rtc;;
vcs)
  st $I root 600 d /hurd/console;;
tty[1-9][0-9]|tty[1-9])


- Should rtc-cmos be appended to std device list in MAKEDEV? (i.e. is 
rtc-cmos a standard device?).


- Should we create /dev/rtc in MAKEDEV? I spent some time reading the 
documentation about how old Linux (2.0.10) creates /dev/rtc. 
Linux-2.0.10 has neither udev nor devfs. According to the following 
part, it seems /dev/rtc was expected to be created by users using mknod 
depending on their needs (I didn't find any direct evidence). Probably 
we just need to provide the translator (/hurd/rtc-cmos) and users just 
set up /dev/rtc using settrans depending on their needs?


``` Documentation/Configure.help
Enhanced Real Time Clock Support
CONFIG_RTC
  If you enable this option and create a character special file
  /dev/rtc with major number 10 and minor number 135 using mknod ("man
  mknod"), you will get access to the real time clock built into your
...
```

- Should we consider (/dev/rtcN [0]) at this stage? Linux's /dev/rtcN 
seems to depend on its file system[1].


[0]:https://www.kernel.org/doc/html/v6.12/admin-guide/rtc.html
[1]:https://github.com/torvalds/linux/blob/master/drivers/rtc/dev.c#L560-L567

--
Zhaoming Luo

Re: [RFC PATCH util-linux] Support hwclock read and set operations for Hurd

[Zhaoming Luo]

On 12/3/24 6:48 AM, Samuel Thibault wrote:

Zhaoming Luo, le mar. 03 déc. 2024 06:42:07 +0800, a ecrit:

On 12/2/24 10:12 AM, Samuel Thibault wrote:

Please factorize these with the linux port, by putting them into a
shared file that is linked-in in both ports cases.

Do you mean having the following structure?
  /- hurd-hwlock-rtc.c \
hwclock.c   hwclock-rtc.c
  \- linux-hwlock-rtc.c /

hwclock-rtc.c contains close_rtc, open_rtc, etc.


Yes.
I think another of supporting hwclock in Hurd is implementing more ioctl 
calls (RTC_UIE_ON, RTC_PARAM_GET, etc) for rtc. The current compile 
errors seem to be mainly due to the lack of RTC ioctl macros (i.e. 
RTC_UIE_ON, etc). The issues with __u64, __s64, and __u32 (they seem to 
be Linux-specific) can be solved by using:


```
#ifdef __gnu_hurd__
typedef unsigned long long __u64;
typedef signed long long __s64;
typedef unsigned int __u32;
#endif
```

Providing a rtc ioctl interface similar to Linux can avoid large change 
on util-linux upstream. Maybe I should go this way?


--
Zhaoming Luo

[Hurd PATCH 1/1] Add rtc translator and RTC CMOS driver

[Zhaoming Luo]

A /hurd/rtc translator will be created as, users can create a /dev/rtc
device using the following command:
```
sudo settrans -c /dev/rtc /hurd/rtc
```

* Makefile: add rtc-cmos server into the compile chain
* hurd/pioctl.defs: new file. Interfaces for rtc ioctl operations
* hurd/rtc.h: new file. Interfaces for rtc device
* rtc/Makefile: new file. Makefile for rtc server
* rtc/main.c: new file. Initialisation for rtc translator
* rtc/mig-mutate.h: new file. Type translation for rtc server
* rtc/rtc-cmos_pioctl-ops.c: new file. The rtc-cmos server side implementation
---
 Makefile  |   3 +-
 hurd/pioctl.defs  |  59 
 hurd/rtc.h|  51 +++
 rtc/Makefile  |  39 ++
 rtc/main.c| 104 ++
 rtc/mig-mutate.h  |  24 
 rtc/rtc-cmos_pioctl-ops.c | 276 ++
 7 files changed, 555 insertions(+), 1 deletion(-)
 create mode 100644 hurd/pioctl.defs
 create mode 100644 hurd/rtc.h
 create mode 100644 rtc/Makefile
 create mode 100644 rtc/main.c
 create mode 100644 rtc/mig-mutate.h
 create mode 100644 rtc/rtc-cmos_pioctl-ops.c

diff --git a/Makefile b/Makefile
index 4d848221..9d9e33c3 100644
--- a/Makefile
+++ b/Makefile
@@ -47,7 +47,8 @@ prog-subdirs = auth proc exec term \
   init \
   devnode \
   eth-multiplexer \
-  shutdown
+  shutdown \
+  rtc
 
 ifeq ($(HAVE_LIBRUMP),yes)
 prog-subdirs += rumpdisk
diff --git a/hurd/pioctl.defs b/hurd/pioctl.defs
new file mode 100644
index ..77d830e7
--- /dev/null
+++ b/hurd/pioctl.defs
@@ -0,0 +1,59 @@
+/* Definitions for /dev/rtc ioctls
+
+   Copyright (C) 2024 Free Software Foundation, Inc.
+
+   This file is part of the GNU Hurd.
+
+   The GNU Hurd is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License as
+   published by the Free Software Foundation; either version 2, or (at
+   your option) any later version.
+
+   The GNU Hurd is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111, USA. */
+
+/* Ioctl group 'p'; the subsystem is derived from calculations in
+   hurd/ioctls.defs. */
+subsystem pioctl 14;
+
+#include 
+
+import ;
+
+#ifdef PIOCTL_IMPORTS
+PIOCTL_IMPORTS
+#endif
+
+INTR_INTERFACE
+
+/* This is the arg for a struct rtc_time as specified by the
+   definition of _IOT_rtc_time in $(hurd)/hurd/rtc.h. */
+type rtc_time_t = struct[9] of int;
+
+skip; skip; skip; /* 0 1 2 */
+
+/* 3 RTC_UIE_ON */
+routine pioctl_rtc_uie_on (
+   reqport: io_t);
+
+/* 4 RTC_UIE_OFF */
+routine pioctl_rtc_uie_off (
+   reqport: io_t);
+
+skip; skip; skip; skip; /* 5 6 7 8 */
+
+/* 9 RTC_RD_TIME */
+routine pioctl_rtc_rd_time (
+   reqport: io_t;
+   out tm: rtc_time_t);
+
+/* 10 RTC_SET_TIME */
+routine pioctl_rtc_set_time (
+   reqport: io_t;
+   tm: rtc_time_t);
diff --git a/hurd/rtc.h b/hurd/rtc.h
new file mode 100644
index ..58bf5536
--- /dev/null
+++ b/hurd/rtc.h
@@ -0,0 +1,51 @@
+/* GNU Hurd RTC interface
+
+   Copyright (C) 2024 Free Software Foundation, Inc.
+
+   This file is part of the GNU Hurd.
+
+   The GNU Hurd is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License as
+   published by the Free Software Foundation; either version 2, or (at
+   your option) any later version.
+
+   The GNU Hurd is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111, USA. */
+
+#ifndef _RTC_H
+#define _RTC_H 1
+
+#include 
+
+struct rtc_time
+{
+  int tm_sec;
+  int tm_min;
+  int tm_hour;
+  int tm_mday;
+  int tm_mon;
+  int tm_year;
+  int tm_wday;
+  int tm_yday;
+  int tm_isdst;
+};
+typedef struct rtc_time rtc_time_t;
+
+#define _IOT_rtc_time _IOT(_IOTS(int),9,0,0,0,0)
+
+/* ioctl calls that are permitted to the /dev/rtc interface, if
+   any of the RTC drivers are enabled.  */
+
+#define RTC_UIE_ON  _IO('p', 0x03) /* Update int. enable on.  */
+#define RTC_UIE_OFF _IO('p', 0x04) /* ... off.  */
+
+#define RTC_RD_TIME_IOR('p', 0x09, struct rtc_time) /* Read RTC time.  */
+#define RTC_SET_TIME   _IOW('p', 0x0a, struct rtc_time) /* Set RTC time.  */
+
+#endif /* rtc.h */
diff 

[PATCH 0/1] Add rtc translator, RTC CMOS driver and hwclock

[Zhaoming Luo]

Because the hurd patch (rtc translator and RTC CMOS driver) is a bit
related to the patch for util-linux (support hwclock in Hurd), I decided
to send them together.

We will see the following functions after applying the patch:
```
Functions:
 -r, --show  display the RTC time
 --get   display drift corrected RTC time
 --set   set the RTC according to --date
 -s, --hctosys   set the system time from the RTC
 -w, --systohc   set the RTC from the system time
 --systz send timescale configurations to the kernel
 -a, --adjustadjust the RTC to account for systematic drift
 --predict   predict the drifted RTC time according to 
--date
```

I have tested those functions, they works perfectly expect --systz. The
hwclock said the issue is `settimeofday() failed: Function not
implemented`. However, settimeofday is obsolescent[0] so I think we can
ignore it.

You will see in rtc-cmos_pioctl-ops.c RTC_UIE_ON and RTC_UIE_OFF just
return EOPNOTSUPP. Samuel mentioned a proper implementation is quite
involved; it means registering to gnumach ... etc. A solution would be
using the busy-wait method used by hwclock. However, hwclock itself will
select the busy-wait method (hwclock has a built-in one) automatically
if RTC_UIE_ON ioctl fails. Therefore, I think before there are some other
softwares want to use RTC_UIE_ON, we can just use placeholders.
BTW I'm quite interested in that proper implementation :).

About the adding of O_WRONLY in hwclock-rtc.c in the util-linux patch.
It's quite weird that hurd (in qemu) cannot set time without O_WRONLY
but linux (on my linux laptop) can.

[0]: https://www.mail-archive.com/info-gnu@gnu.org/msg02694.html
-- 
2.45.2

[util-linux PATCH] Support hwclock for GNU Hurd

[Zhaoming Luo]

* configure.ac: add HURD so it can be used in conditional in am files
* sys-utils/Makemodule.am: compile hwclock for GNU Hurd
* sys-utils/hwclock-cmos.c: avoid nested declaration warning
* sys-utils/hwclock-rtc.c: compile for GNU Hurd
* sys-utils/hwclock.c: compile for GNU Hurd
* sys-utils/hwclock.h: compile for GNU Hurd

---
 configure.ac |  6 +-
 sys-utils/Makemodule.am  |  5 +
 sys-utils/hwclock-cmos.c |  2 ++
 sys-utils/hwclock-rtc.c  | 15 ---
 sys-utils/hwclock.c  |  2 +-
 sys-utils/hwclock.h  |  3 +++
 6 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 698da36..8de6af6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -263,16 +263,20 @@ AC_PATH_PROG([XSLTPROC], [xsltproc])
 
 linux_os=no
 bsd_os=no
+gnu_os=no
 AS_CASE([${host_os}],
   [*linux*],
  [linux_os=yes],
   [*darwin*],
  [darwin_os=yes],
   [*bsd*],
- [bsd_os=yes])
+ [bsd_os=yes],
+  [gnu*],
+ [gnu_os=yes])
 AM_CONDITIONAL([LINUX], [test "x$linux_os" = xyes])
 AM_CONDITIONAL([DARWIN], [test "x$darwin_os" = xyes])
 AM_CONDITIONAL([BSD], [test "x$bsd_os" = xyes])
+AM_CONDITIONAL([HURD], [test "x$gnu_os" = xyes])
 
 AS_IF([test  "x$darwin_os" = xyes], [
   AC_DEFINE([_DARWIN_C_SOURCE], [1], [Enable MAP_ANON in sys/mman.h on Mac OS 
X])
diff --git a/sys-utils/Makemodule.am b/sys-utils/Makemodule.am
index 209b656..8cc69be 100644
--- a/sys-utils/Makemodule.am
+++ b/sys-utils/Makemodule.am
@@ -570,6 +570,11 @@ hwclock_SOURCES += \
lib/monotonic.c
 hwclock_LDADD += $(REALTIME_LIBS)
 endif
+if HURD
+hwclock_SOURCES += \
+   sys-utils/hwclock-rtc.c \
+   lib/monotonic.c
+endif
 if HAVE_AUDIT
 hwclock_LDADD += -laudit
 endif
diff --git a/sys-utils/hwclock-cmos.c b/sys-utils/hwclock-cmos.c
index 7e5eecc..cc672cb 100644
--- a/sys-utils/hwclock-cmos.c
+++ b/sys-utils/hwclock-cmos.c
@@ -352,7 +352,9 @@ static int i386_iopl(const int level)
 # else
 static int i386_iopl(const int level __attribute__ ((__unused__)))
 {
+   #ifndef __gnu_hurd__
extern int ioperm(unsigned long from, unsigned long num, int turn_on);
+   #endif
return ioperm(clock_ctl_addr, 2, 1);
 }
 # endif
diff --git a/sys-utils/hwclock-rtc.c b/sys-utils/hwclock-rtc.c
index 2796f2e..251746c 100644
--- a/sys-utils/hwclock-rtc.c
+++ b/sys-utils/hwclock-rtc.c
@@ -8,10 +8,15 @@
  *
  * rtc.c - Use /dev/rtc for clock access
  */
+#ifdef __gnu_hurd__
+#include 
+#include 
+#else
 #include 
-#include 
 #include 
 #include 
+#endif /* GNU_HURD */
+#include 
 #include 
 #include 
 #include 
@@ -28,6 +33,7 @@
 
 #include "hwclock.h"
 
+#ifndef __gnu_hurd__
 #ifndef RTC_PARAM_GET
 struct rtc_param {
__u64 param;
@@ -60,6 +66,7 @@ const struct hwclock_param *get_hwclock_params(void)
 {
return hwclock_params;
 }
+#endif /* GNU_HURD */
 
 /*
  * /dev/rtc is conventionally chardev 10/135
@@ -99,12 +106,12 @@ static int open_rtc(const struct hwclock_control *ctl)
/* --rtc option has been given */
if (ctl->rtc_dev_name) {
rtc_dev_name = ctl->rtc_dev_name;
-   rtc_dev_fd = open(rtc_dev_name, O_RDONLY);
+   rtc_dev_fd = open(rtc_dev_name, O_RDONLY | O_WRONLY);
} else {
for (i = 0; i < ARRAY_SIZE(fls); i++) {
if (ctl->verbose)
printf(_("Trying to open: %s\n"), fls[i]);
-   rtc_dev_fd = open(fls[i], O_RDONLY);
+   rtc_dev_fd = open(fls[i], O_RDONLY | O_WRONLY);
 
if (rtc_dev_fd < 0) {
if (errno == ENOENT || errno == ENODEV)
@@ -411,6 +418,7 @@ int set_epoch_rtc(const struct hwclock_control *ctl)
 
 
 
+#ifndef __gnu_hurd__
 static int resolve_rtc_param_alias(const char *alias, __u64 *value)
 {
const struct hwclock_param *param = &hwclock_params[0];
@@ -609,3 +617,4 @@ int rtc_vl_clear(const struct hwclock_control *ctl)
 
return 0;
 }
+#endif /* GNU_HURD */
diff --git a/sys-utils/hwclock.c b/sys-utils/hwclock.c
index 2b33dfb..e1a105e 100644
--- a/sys-utils/hwclock.c
+++ b/sys-utils/hwclock.c
@@ -989,7 +989,7 @@ static void determine_clock_access_method(const struct 
hwclock_control *ctl)
if (ctl->directisa)
ur = probe_for_cmos_clock();
 #endif
-#ifdef __linux__
+#if defined(__linux__) || defined(__gnu_hurd__)
if (!ur)
ur = probe_for_rtc_clock(ctl);
 #endif
diff --git a/sys-utils/hwclock.h b/sys-utils/hwclock.h
index 2522d6c..485e904 100644
--- a/sys-utils/hwclock.h
+++ b/sys-utils/hwclock.h
@@ -39,6 +39,9 @@ struct hwclock_control {
 #ifdef __linux__
char *rtc_dev_name;
uint32_t param_idx; /* --param-index  */
+#endif
+#ifdef __gnu_hurd__
+   char *rtc_dev_name;
 #endif
char *param_get_option;
char *param_set_option;
-- 
2.45.2

Re: [RFC PATCH util-linux] Support hwclock read and set operations for Hurd

[Zhaoming Luo]

On 12/4/24 5:56 AM, Samuel Thibault wrote:

Zhaoming Luo, le mar. 03 déc. 2024 08:53:44 +0800, a ecrit:

On 12/3/24 6:48 AM, Samuel Thibault wrote:

Zhaoming Luo, le mar. 03 déc. 2024 06:42:07 +0800, a ecrit:

On 12/2/24 10:12 AM, Samuel Thibault wrote:

Please factorize these with the linux port, by putting them into a
shared file that is linked-in in both ports cases.

Do you mean having the following structure?
   /- hurd-hwlock-rtc.c \
hwclock.c   hwclock-rtc.c
   \- linux-hwlock-rtc.c /

hwclock-rtc.c contains close_rtc, open_rtc, etc.


Yes.

I think another of supporting hwclock in Hurd is implementing more ioctl
calls (RTC_UIE_ON, RTC_PARAM_GET, etc) for rtc. The current compile errors
seem to be mainly due to the lack of RTC ioctl macros (i.e. RTC_UIE_ON,
etc).


That's also a solution, though more involved in terms of implementing
RPCs. Notably UIE_ON will have to be blocking.
I will try this solution first, because those RPCs will eventually be 
implemented in the future. There is no reason we don't finish them now :).


BTW, what do you mean by "blocking"?

--
Zhaoming Luo

[PATCH Hurd] lwip: Properly handle errors during initialization

[Zhaoming Luo]

---
 lwip/main.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/lwip/main.c b/lwip/main.c
index ff9051db..0d92589f 100644
--- a/lwip/main.c
+++ b/lwip/main.c
@@ -218,7 +218,7 @@ main (int argc, char **argv)
 
   task_get_bootstrap_port (mach_task_self (), &bootstrap);
   if (bootstrap == MACH_PORT_NULL)
-error (-1, 0, "Must be started as a translator");
+error (1, 0, "Must be started as a translator");
 
   /* Create portclass to install on the bootstrap port. */
   if (lwip_protid_portclasses[lwip_bootstrap_portclass] != NULL)
@@ -228,13 +228,13 @@ main (int argc, char **argv)
 trivfs_add_protid_port_class (&lwip_protid_portclasses
  [lwip_bootstrap_portclass]);
   if (err)
-error (1, 0, "error creating control port class");
+error (1, err, "error creating control port class");
 
   err =
 trivfs_add_control_port_class (&lwip_cntl_portclasses
   [lwip_bootstrap_portclass]);
   if (err)
-error (1, 0, "error creating control port class");
+error (1, err, "error creating control port class");
 
   /* Reply to our parent */
   err = trivfs_startup (bootstrap, 0,
@@ -244,9 +244,7 @@ main (int argc, char **argv)
lwip_bucket, &lwipcntl);
   mach_port_deallocate (mach_task_self (), bootstrap);
   if (err)
-{
-  return (-1);
-}
+error (1, err, "trivfs_startup failed");
 
   /* Initialize status from underlying node.  */
   lwip_owner = lwip_group = 0;
-- 
2.45.2

Re: [PATCH Hurd] lwip: Properly handle errors during initialization

[Zhaoming Luo]

On 12/8/24 4:28 PM, Sergey Bugaev wrote:

On Sun, Dec 8, 2024 at 7:53 AM Zhaoming Luo  wrote:

  lwip/main.c | 10 --
  1 file changed, 4 insertions(+), 6 deletions(-)


Makes sense to me, thanks!

Reviewed-by: Sergey Bugaev 


Thanks for the review.

(...but I don't know exactly what you're supposed to do with that R-b
line. I asked on libc-alpha last year [0], and didn't get a reply.)
[0]: https://sourceware.org/pipermail/libc-alpha/2023-June/149094.html
What do you mean by R-b line? Does that refer to the patches I submitted 
for the rtc translator?


--
Zhaoming Luo

Re: [PATCH Hurd] lwip: Properly handle errors during initialization

[Zhaoming Luo]

On 12/8/24 5:15 PM, Sergey Bugaev wrote:

On Sun, Dec 8, 2024 at 11:54 AM Zhaoming Luo  wrote:

Reviewed-by: Sergey Bugaev 


Thanks for the review.

(...but I don't know exactly what you're supposed to do with that R-b
line. I asked on libc-alpha last year [0], and didn't get a reply.)
[0]: https://sourceware.org/pipermail/libc-alpha/2023-June/149094.html

What do you mean by R-b line? Does that refer to the patches I submitted
for the rtc translator?


I mean the "Reviewed-by" line. (And no, I was talking about this very
patch, not the RTC ones.) You can find some docs about it at
[0][1][2],

[0]: https://git-scm.com/docs/SubmittingPatches#sign-off
[1]: 
https://docs.kernel.org/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
[2]: https://www.x.org/wiki/Development/Documentation/SubmittingPatches/

but basically the idea is that once someone (in this case, me) has
reviewed a patch and agrees with it, they can "offer" a "Reviewed-by:
That Person " line to the patch author, just like I
did above. Frequently a reviewer would actually point out some small
changes to be made in the patch, and then say something like: "With
those changes, Reviewed-by: ... <...@example.com>", meaning the R-b
line is valid if the patch author accepts the proposed changes to
their patch.

The Reviewed-by line(s) offered by the reviewer(s) is supposed to end
up in subsequent iterations of the patch (unless the patch gets
changed substantially?) and in the Git commit once the patch is
pushed, right next to other "trailers" like Signed-off-by and
Suggested-by. What's unclear to me is exactly how this is supposed to
work. Well, in this specific case, assuming this will be the only
iteration of the patch, let's hope Samuel notices this thread :) and
appends my R-b line to your commit message, but I don't understand how
this is supposed to work in general.

I see. It's quite new to me. I cc Samuel. Let's hope together :).

--
Zhaoming Luo

Re: [PATCH Web] Add an introduction about a mig-mutate.h file

[Zhaoming Luo]

On 12/8/24 9:26 PM, jbra...@dismail.de wrote:

December 7, 2024 at 7:11 PM, "Zhaoming Luo" mailto:zhming...@163.com?to=%22Zhaoming%20Luo%22%20%3Czhmingluo%40163.com%3E > wrote:





Add a link pointing to an introduction about a mig-mutate.h file


I do think this is a good contribution to the wiki, but I personally
think it would be a little better if we just put the text in a new
wiki page instead of linking to the email.  Just my opinion.

Fair enough. The subject of the email may be confusing. I have added it 
in my TODO list.




  * microkernel/mach/mig/documentation.mdwn: new further relevant documentation
---
  microkernel/mach/mig/documentation.mdwn | 1 +
  1 file changed, 1 insertion(+)

diff --git a/microkernel/mach/mig/documentation.mdwn 
b/microkernel/mach/mig/documentation.mdwn
index 740949e0..06536386 100644
--- a/microkernel/mach/mig/documentation.mdwn
+++ b/microkernel/mach/mig/documentation.mdwn
@@ -85,6 +85,7 @@ pp. 67--77."
  
  * MIG *in action*: [[hurd/io_path]].
  
+ * [*Introduction to a mig-mutate.h file*](https://mail.gnu.org/archive/html/bug-hurd/2024-11/msg00045.html), a text by Sergey Bugaev
  
  ## IRC, freenode, #hurd, 2013-09-04
  
--

2.47.1



--
Zhaoming Luo

Re: [util-linux PATCH v2] Support hwclock for GNU Hurd

[Zhaoming Luo]

On 12/9/24 12:43 AM, Samuel Thibault wrote:

Hello,

Hi, thanks for the review.


Zhaoming Luo, le ven. 06 déc. 2024 11:03:26 +0800, a ecrit:

diff --git a/sys-utils/hwclock-cmos.c b/sys-utils/hwclock-cmos.c
index 7e5eecc..cc672cb 100644
--- a/sys-utils/hwclock-cmos.c
+++ b/sys-utils/hwclock-cmos.c
@@ -352,7 +352,9 @@ static int i386_iopl(const int level)
  # else
  static int i386_iopl(const int level __attribute__ ((__unused__)))
  {
+   #ifndef __gnu_hurd__
extern int ioperm(unsigned long from, unsigned long num, int turn_on);
+   #endif
return ioperm(clock_ctl_addr, 2, 1);
  }
  # endif


This seems unrelated, do you get an issue without it?


Got the following errors without it:
```
sys-utils/hwclock-cmos.c: In function 'i386_iopl':
sys-utils/hwclock-cmos.c:355:20: warning: nested extern declaration of 
'ioperm' [-Wnested-externs]
  355 | extern int ioperm(unsigned long from, unsigned long 
num, int turn_on);

  |^~
sys-utils/hwclock-cmos.c:355:20: warning: redundant redeclaration of 
'ioperm' [-Wredundant-decls]

In file included from sys-utils/hwclock-cmos.c:68:
/usr/include/i386-gnu/sys/io.h:29:12: note: previous declaration of 
'ioperm' with type 'int(long unsigned int,  long unsigned int,  int)'
   29 | extern int ioperm (unsigned long int __from, unsigned long int 
__num,

  |^~
  CCLD hwclock
```



diff --git a/sys-utils/hwclock-rtc.c b/sys-utils/hwclock-rtc.c
index 2796f2e..c285c42 100644
--- a/sys-utils/hwclock-rtc.c
+++ b/sys-utils/hwclock-rtc.c
@@ -8,10 +8,15 @@
   *
   * rtc.c - Use /dev/rtc for clock access
   */
+#ifdef __gnu_hurd__


Rather use __GNU__ like in other places of the code.

OK.



+#include 
+#include 
+#else
  #include 
-#include 
  #include 
  #include 
+#endif /* GNU_HURD */
+#include 
  #include 
  #include 
  #include 



diff --git a/sys-utils/hwclock.c b/sys-utils/hwclock.c
index 2b33dfb..e1a105e 100644
--- a/sys-utils/hwclock.c
+++ b/sys-utils/hwclock.c
@@ -989,7 +989,7 @@ static void determine_clock_access_method(const struct 
hwclock_control *ctl)
if (ctl->directisa)
ur = probe_for_cmos_clock();
  #endif
-#ifdef __linux__
+#if defined(__linux__) || defined(__gnu_hurd__)
if (!ur)
ur = probe_for_rtc_clock(ctl);
  #endif
diff --git a/sys-utils/hwclock.h b/sys-utils/hwclock.h
index 2522d6c..485e904 100644
--- a/sys-utils/hwclock.h
+++ b/sys-utils/hwclock.h
@@ -39,6 +39,9 @@ struct hwclock_control {
  #ifdef __linux__
char *rtc_dev_name;
uint32_t param_idx; /* --param-index  */
+#endif
+#ifdef __gnu_hurd__
+   char *rtc_dev_name;
  #endif


Better factorize:

#if defined(__linux__) || defined(__GNU__)
char *rtc_dev_name;
#endif
#ifdef __linux__
uint32_t param_idx; /* --param-index  */
#endif

OK.

--
Zhaoming Luo

[PATCH] hwclock: Support GNU Hurd

[Zhaoming Luo]

* configure.ac: add HURD so it can be used in conditional in am files
* sys-utils/Makemodule.am: compile hwclock for GNU Hurd
* sys-utils/hwclock-rtc.c: compile for GNU Hurd
* sys-utils/hwclock.c: compile for GNU Hurd
* sys-utils/hwclock.h: compile for GNU Hurd

Signed-off-by: Zhaoming Luo 
---
 configure.ac|  6 +-
 sys-utils/Makemodule.am |  5 +
 sys-utils/hwclock-rtc.c | 15 ---
 sys-utils/hwclock.c |  2 +-
 sys-utils/hwclock.h |  4 +++-
 5 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index 698da36..8de6af6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -263,16 +263,20 @@ AC_PATH_PROG([XSLTPROC], [xsltproc])
 
 linux_os=no
 bsd_os=no
+gnu_os=no
 AS_CASE([${host_os}],
   [*linux*],
  [linux_os=yes],
   [*darwin*],
  [darwin_os=yes],
   [*bsd*],
- [bsd_os=yes])
+ [bsd_os=yes],
+  [gnu*],
+ [gnu_os=yes])
 AM_CONDITIONAL([LINUX], [test "x$linux_os" = xyes])
 AM_CONDITIONAL([DARWIN], [test "x$darwin_os" = xyes])
 AM_CONDITIONAL([BSD], [test "x$bsd_os" = xyes])
+AM_CONDITIONAL([HURD], [test "x$gnu_os" = xyes])
 
 AS_IF([test  "x$darwin_os" = xyes], [
   AC_DEFINE([_DARWIN_C_SOURCE], [1], [Enable MAP_ANON in sys/mman.h on Mac OS 
X])
diff --git a/sys-utils/Makemodule.am b/sys-utils/Makemodule.am
index 209b656..8cc69be 100644
--- a/sys-utils/Makemodule.am
+++ b/sys-utils/Makemodule.am
@@ -570,6 +570,11 @@ hwclock_SOURCES += \
lib/monotonic.c
 hwclock_LDADD += $(REALTIME_LIBS)
 endif
+if HURD
+hwclock_SOURCES += \
+   sys-utils/hwclock-rtc.c \
+   lib/monotonic.c
+endif
 if HAVE_AUDIT
 hwclock_LDADD += -laudit
 endif
diff --git a/sys-utils/hwclock-rtc.c b/sys-utils/hwclock-rtc.c
index 2796f2e..7162ae9 100644
--- a/sys-utils/hwclock-rtc.c
+++ b/sys-utils/hwclock-rtc.c
@@ -8,10 +8,15 @@
  *
  * rtc.c - Use /dev/rtc for clock access
  */
+#ifdef __GNU__
+#include 
+#include 
+#else
 #include 
-#include 
 #include 
 #include 
+#endif /* __GNU__ */
+#include 
 #include 
 #include 
 #include 
@@ -28,6 +33,7 @@
 
 #include "hwclock.h"
 
+#ifndef __GNU__
 #ifndef RTC_PARAM_GET
 struct rtc_param {
__u64 param;
@@ -60,6 +66,7 @@ const struct hwclock_param *get_hwclock_params(void)
 {
return hwclock_params;
 }
+#endif /* __GNU__ */
 
 /*
  * /dev/rtc is conventionally chardev 10/135
@@ -99,12 +106,12 @@ static int open_rtc(const struct hwclock_control *ctl)
/* --rtc option has been given */
if (ctl->rtc_dev_name) {
rtc_dev_name = ctl->rtc_dev_name;
-   rtc_dev_fd = open(rtc_dev_name, O_RDONLY);
+   rtc_dev_fd = open(rtc_dev_name, O_RDWR);
} else {
for (i = 0; i < ARRAY_SIZE(fls); i++) {
if (ctl->verbose)
printf(_("Trying to open: %s\n"), fls[i]);
-   rtc_dev_fd = open(fls[i], O_RDONLY);
+   rtc_dev_fd = open(fls[i], O_RDWR);
 
if (rtc_dev_fd < 0) {
if (errno == ENOENT || errno == ENODEV)
@@ -411,6 +418,7 @@ int set_epoch_rtc(const struct hwclock_control *ctl)
 
 
 
+#ifndef __GNU__
 static int resolve_rtc_param_alias(const char *alias, __u64 *value)
 {
const struct hwclock_param *param = &hwclock_params[0];
@@ -609,3 +617,4 @@ int rtc_vl_clear(const struct hwclock_control *ctl)
 
return 0;
 }
+#endif /* __GNU__ */
diff --git a/sys-utils/hwclock.c b/sys-utils/hwclock.c
index 2b33dfb..2714775 100644
--- a/sys-utils/hwclock.c
+++ b/sys-utils/hwclock.c
@@ -989,7 +989,7 @@ static void determine_clock_access_method(const struct 
hwclock_control *ctl)
if (ctl->directisa)
ur = probe_for_cmos_clock();
 #endif
-#ifdef __linux__
+#if defined(__linux__) || defined(__GNU__)
if (!ur)
ur = probe_for_rtc_clock(ctl);
 #endif
diff --git a/sys-utils/hwclock.h b/sys-utils/hwclock.h
index 2522d6c..4cbbff9 100644
--- a/sys-utils/hwclock.h
+++ b/sys-utils/hwclock.h
@@ -36,8 +36,10 @@ struct hwclock_control {
 #if defined(__linux__) && defined(__alpha__)
char *epoch_option;
 #endif
-#ifdef __linux__
+#if defined(__linux__) || defined(__GNU__)
char *rtc_dev_name;
+#endif
+#ifdef __linux__
uint32_t param_idx; /* --param-index  */
 #endif
char *param_get_option;
-- 
2.45.2

[PATCH v3] Support hwclock for GNU Hurd

[Zhaoming Luo]

* configure.ac: add HURD so it can be used in conditional in am files
* sys-utils/Makemodule.am: compile hwclock for GNU Hurd
* sys-utils/hwclock-rtc.c: compile for GNU Hurd
* sys-utils/hwclock.c: compile for GNU Hurd
* sys-utils/hwclock.h: compile for GNU Hurd

---
 configure.ac|  6 +-
 sys-utils/Makemodule.am |  5 +
 sys-utils/hwclock-rtc.c | 15 ---
 sys-utils/hwclock.c |  2 +-
 sys-utils/hwclock.h |  4 +++-
 5 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index 698da36..8de6af6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -263,16 +263,20 @@ AC_PATH_PROG([XSLTPROC], [xsltproc])
 
 linux_os=no
 bsd_os=no
+gnu_os=no
 AS_CASE([${host_os}],
   [*linux*],
  [linux_os=yes],
   [*darwin*],
  [darwin_os=yes],
   [*bsd*],
- [bsd_os=yes])
+ [bsd_os=yes],
+  [gnu*],
+ [gnu_os=yes])
 AM_CONDITIONAL([LINUX], [test "x$linux_os" = xyes])
 AM_CONDITIONAL([DARWIN], [test "x$darwin_os" = xyes])
 AM_CONDITIONAL([BSD], [test "x$bsd_os" = xyes])
+AM_CONDITIONAL([HURD], [test "x$gnu_os" = xyes])
 
 AS_IF([test  "x$darwin_os" = xyes], [
   AC_DEFINE([_DARWIN_C_SOURCE], [1], [Enable MAP_ANON in sys/mman.h on Mac OS 
X])
diff --git a/sys-utils/Makemodule.am b/sys-utils/Makemodule.am
index 209b656..8cc69be 100644
--- a/sys-utils/Makemodule.am
+++ b/sys-utils/Makemodule.am
@@ -570,6 +570,11 @@ hwclock_SOURCES += \
lib/monotonic.c
 hwclock_LDADD += $(REALTIME_LIBS)
 endif
+if HURD
+hwclock_SOURCES += \
+   sys-utils/hwclock-rtc.c \
+   lib/monotonic.c
+endif
 if HAVE_AUDIT
 hwclock_LDADD += -laudit
 endif
diff --git a/sys-utils/hwclock-rtc.c b/sys-utils/hwclock-rtc.c
index 2796f2e..7162ae9 100644
--- a/sys-utils/hwclock-rtc.c
+++ b/sys-utils/hwclock-rtc.c
@@ -8,10 +8,15 @@
  *
  * rtc.c - Use /dev/rtc for clock access
  */
+#ifdef __GNU__
+#include 
+#include 
+#else
 #include 
-#include 
 #include 
 #include 
+#endif /* __GNU__ */
+#include 
 #include 
 #include 
 #include 
@@ -28,6 +33,7 @@
 
 #include "hwclock.h"
 
+#ifndef __GNU__
 #ifndef RTC_PARAM_GET
 struct rtc_param {
__u64 param;
@@ -60,6 +66,7 @@ const struct hwclock_param *get_hwclock_params(void)
 {
return hwclock_params;
 }
+#endif /* __GNU__ */
 
 /*
  * /dev/rtc is conventionally chardev 10/135
@@ -99,12 +106,12 @@ static int open_rtc(const struct hwclock_control *ctl)
/* --rtc option has been given */
if (ctl->rtc_dev_name) {
rtc_dev_name = ctl->rtc_dev_name;
-   rtc_dev_fd = open(rtc_dev_name, O_RDONLY);
+   rtc_dev_fd = open(rtc_dev_name, O_RDWR);
} else {
for (i = 0; i < ARRAY_SIZE(fls); i++) {
if (ctl->verbose)
printf(_("Trying to open: %s\n"), fls[i]);
-   rtc_dev_fd = open(fls[i], O_RDONLY);
+   rtc_dev_fd = open(fls[i], O_RDWR);
 
if (rtc_dev_fd < 0) {
if (errno == ENOENT || errno == ENODEV)
@@ -411,6 +418,7 @@ int set_epoch_rtc(const struct hwclock_control *ctl)
 
 
 
+#ifndef __GNU__
 static int resolve_rtc_param_alias(const char *alias, __u64 *value)
 {
const struct hwclock_param *param = &hwclock_params[0];
@@ -609,3 +617,4 @@ int rtc_vl_clear(const struct hwclock_control *ctl)
 
return 0;
 }
+#endif /* __GNU__ */
diff --git a/sys-utils/hwclock.c b/sys-utils/hwclock.c
index 2b33dfb..2714775 100644
--- a/sys-utils/hwclock.c
+++ b/sys-utils/hwclock.c
@@ -989,7 +989,7 @@ static void determine_clock_access_method(const struct 
hwclock_control *ctl)
if (ctl->directisa)
ur = probe_for_cmos_clock();
 #endif
-#ifdef __linux__
+#if defined(__linux__) || defined(__GNU__)
if (!ur)
ur = probe_for_rtc_clock(ctl);
 #endif
diff --git a/sys-utils/hwclock.h b/sys-utils/hwclock.h
index 2522d6c..4cbbff9 100644
--- a/sys-utils/hwclock.h
+++ b/sys-utils/hwclock.h
@@ -36,8 +36,10 @@ struct hwclock_control {
 #if defined(__linux__) && defined(__alpha__)
char *epoch_option;
 #endif
-#ifdef __linux__
+#if defined(__linux__) || defined(__GNU__)
char *rtc_dev_name;
+#endif
+#ifdef __linux__
uint32_t param_idx; /* --param-index  */
 #endif
char *param_get_option;
-- 
2.45.2

Re: [util-linux PATCH v2] Support hwclock for GNU Hurd

[Zhaoming Luo]

On 12/9/24 7:54 AM, Samuel Thibault wrote:

Zhaoming Luo, le lun. 09 déc. 2024 07:51:38 +0800, a ecrit:

On 12/9/24 12:43 AM, Samuel Thibault wrote:

Hello,

Hi, thanks for the review.


Zhaoming Luo, le ven. 06 déc. 2024 11:03:26 +0800, a ecrit:

diff --git a/sys-utils/hwclock-cmos.c b/sys-utils/hwclock-cmos.c
index 7e5eecc..cc672cb 100644
--- a/sys-utils/hwclock-cmos.c
+++ b/sys-utils/hwclock-cmos.c
@@ -352,7 +352,9 @@ static int i386_iopl(const int level)
   # else
   static int i386_iopl(const int level __attribute__ ((__unused__)))
   {
+   #ifndef __gnu_hurd__
extern int ioperm(unsigned long from, unsigned long num, int turn_on);
+   #endif
return ioperm(clock_ctl_addr, 2, 1);
   }
   # endif


This seems unrelated, do you get an issue without it?


Got the following errors without it:
```
sys-utils/hwclock-cmos.c: In function 'i386_iopl':
sys-utils/hwclock-cmos.c:355:20: warning: nested extern declaration of
'ioperm' [-Wnested-externs]
   355 | extern int ioperm(unsigned long from, unsigned long num, int
turn_on);
   |^~
sys-utils/hwclock-cmos.c:355:20: warning: redundant redeclaration of
'ioperm' [-Wredundant-decls]
In file included from sys-utils/hwclock-cmos.c:68:
/usr/include/i386-gnu/sys/io.h:29:12: note: previous declaration of 'ioperm'
with type 'int(long unsigned int,  long unsigned int,  int)'
29 | extern int ioperm (unsigned long int __from, unsigned long int
__num,
   |^~
   CCLD hwclock
```


Ok. Let's see what upstream thinks about it, they'll probably want to
just get rid of the declaration entirely.


Should I send the warning above to the util-linux mail list?

--
Zhaoming Luo

[util-linux PATCH v2] Support hwclock for GNU Hurd

[Zhaoming Luo]

* configure.ac: add HURD so it can be used in conditional in am files
* sys-utils/Makemodule.am: compile hwclock for GNU Hurd
* sys-utils/hwclock-cmos.c: avoid nested declaration warning
* sys-utils/hwclock-rtc.c: compile for GNU Hurd
* sys-utils/hwclock.c: compile for GNU Hurd
* sys-utils/hwclock.h: compile for GNU Hurd

---
 configure.ac |  6 +-
 sys-utils/Makemodule.am  |  5 +
 sys-utils/hwclock-cmos.c |  2 ++
 sys-utils/hwclock-rtc.c  | 15 ---
 sys-utils/hwclock.c  |  2 +-
 sys-utils/hwclock.h  |  3 +++
 6 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 698da36..8de6af6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -263,16 +263,20 @@ AC_PATH_PROG([XSLTPROC], [xsltproc])
 
 linux_os=no
 bsd_os=no
+gnu_os=no
 AS_CASE([${host_os}],
   [*linux*],
  [linux_os=yes],
   [*darwin*],
  [darwin_os=yes],
   [*bsd*],
- [bsd_os=yes])
+ [bsd_os=yes],
+  [gnu*],
+ [gnu_os=yes])
 AM_CONDITIONAL([LINUX], [test "x$linux_os" = xyes])
 AM_CONDITIONAL([DARWIN], [test "x$darwin_os" = xyes])
 AM_CONDITIONAL([BSD], [test "x$bsd_os" = xyes])
+AM_CONDITIONAL([HURD], [test "x$gnu_os" = xyes])
 
 AS_IF([test  "x$darwin_os" = xyes], [
   AC_DEFINE([_DARWIN_C_SOURCE], [1], [Enable MAP_ANON in sys/mman.h on Mac OS 
X])
diff --git a/sys-utils/Makemodule.am b/sys-utils/Makemodule.am
index 209b656..8cc69be 100644
--- a/sys-utils/Makemodule.am
+++ b/sys-utils/Makemodule.am
@@ -570,6 +570,11 @@ hwclock_SOURCES += \
lib/monotonic.c
 hwclock_LDADD += $(REALTIME_LIBS)
 endif
+if HURD
+hwclock_SOURCES += \
+   sys-utils/hwclock-rtc.c \
+   lib/monotonic.c
+endif
 if HAVE_AUDIT
 hwclock_LDADD += -laudit
 endif
diff --git a/sys-utils/hwclock-cmos.c b/sys-utils/hwclock-cmos.c
index 7e5eecc..cc672cb 100644
--- a/sys-utils/hwclock-cmos.c
+++ b/sys-utils/hwclock-cmos.c
@@ -352,7 +352,9 @@ static int i386_iopl(const int level)
 # else
 static int i386_iopl(const int level __attribute__ ((__unused__)))
 {
+   #ifndef __gnu_hurd__
extern int ioperm(unsigned long from, unsigned long num, int turn_on);
+   #endif
return ioperm(clock_ctl_addr, 2, 1);
 }
 # endif
diff --git a/sys-utils/hwclock-rtc.c b/sys-utils/hwclock-rtc.c
index 2796f2e..c285c42 100644
--- a/sys-utils/hwclock-rtc.c
+++ b/sys-utils/hwclock-rtc.c
@@ -8,10 +8,15 @@
  *
  * rtc.c - Use /dev/rtc for clock access
  */
+#ifdef __gnu_hurd__
+#include 
+#include 
+#else
 #include 
-#include 
 #include 
 #include 
+#endif /* GNU_HURD */
+#include 
 #include 
 #include 
 #include 
@@ -28,6 +33,7 @@
 
 #include "hwclock.h"
 
+#ifndef __gnu_hurd__
 #ifndef RTC_PARAM_GET
 struct rtc_param {
__u64 param;
@@ -60,6 +66,7 @@ const struct hwclock_param *get_hwclock_params(void)
 {
return hwclock_params;
 }
+#endif /* GNU_HURD */
 
 /*
  * /dev/rtc is conventionally chardev 10/135
@@ -99,12 +106,12 @@ static int open_rtc(const struct hwclock_control *ctl)
/* --rtc option has been given */
if (ctl->rtc_dev_name) {
rtc_dev_name = ctl->rtc_dev_name;
-   rtc_dev_fd = open(rtc_dev_name, O_RDONLY);
+   rtc_dev_fd = open(rtc_dev_name, O_RDWR);
} else {
for (i = 0; i < ARRAY_SIZE(fls); i++) {
if (ctl->verbose)
printf(_("Trying to open: %s\n"), fls[i]);
-   rtc_dev_fd = open(fls[i], O_RDONLY);
+   rtc_dev_fd = open(fls[i], O_RDWR);
 
if (rtc_dev_fd < 0) {
if (errno == ENOENT || errno == ENODEV)
@@ -411,6 +418,7 @@ int set_epoch_rtc(const struct hwclock_control *ctl)
 
 
 
+#ifndef __gnu_hurd__
 static int resolve_rtc_param_alias(const char *alias, __u64 *value)
 {
const struct hwclock_param *param = &hwclock_params[0];
@@ -609,3 +617,4 @@ int rtc_vl_clear(const struct hwclock_control *ctl)
 
return 0;
 }
+#endif /* GNU_HURD */
diff --git a/sys-utils/hwclock.c b/sys-utils/hwclock.c
index 2b33dfb..e1a105e 100644
--- a/sys-utils/hwclock.c
+++ b/sys-utils/hwclock.c
@@ -989,7 +989,7 @@ static void determine_clock_access_method(const struct 
hwclock_control *ctl)
if (ctl->directisa)
ur = probe_for_cmos_clock();
 #endif
-#ifdef __linux__
+#if defined(__linux__) || defined(__gnu_hurd__)
if (!ur)
ur = probe_for_rtc_clock(ctl);
 #endif
diff --git a/sys-utils/hwclock.h b/sys-utils/hwclock.h
index 2522d6c..485e904 100644
--- a/sys-utils/hwclock.h
+++ b/sys-utils/hwclock.h
@@ -39,6 +39,9 @@ struct hwclock_control {
 #ifdef __linux__
char *rtc_dev_name;
uint32_t param_idx; /* --param-index  */
+#endif
+#ifdef __gnu_hurd__
+   char *rtc_dev_name;
 #endif
char *param_get_option;
char *param_set_option;
-- 
2.45.2

Re: [util-linux PATCH] Support hwclock for GNU Hurd

[Zhaoming Luo]

On 12/5/24 9:53 PM, Sergey Bugaev wrote:

On Thu, Dec 5, 2024 at 3:39 PM Zhaoming Luo  wrote:

-   rtc_dev_fd = open(rtc_dev_name, O_RDONLY);
+   rtc_dev_fd = open(rtc_dev_name, O_RDONLY | O_WRONLY);


It's called "xxx-only" for a reason :) On standard Unix, you should
use O_RDWR for this.

Now, on the Hurd, these are bitflags: O_RDONLY = O_READ, O_WRONLY =
O_WRITE, O_RDWR = O_READ | O_WRITE. Not so on classic Unix, where
commonly O_RDONLY is 0, O_WRONLY is 1, and O_RDWR is 2.


 } else {
 for (i = 0; i < ARRAY_SIZE(fls); i++) {
 if (ctl->verbose)
 printf(_("Trying to open: %s\n"), fls[i]);
-   rtc_dev_fd = open(fls[i], O_RDONLY);
+   rtc_dev_fd = open(fls[i], O_RDONLY | O_WRONLY);


Ditto.


Thanks for the review. I have corrected it in the new patch.

--
Zhaoming Luo

[PATCH v2] hwclock: Support GNU Hurd

[Zhaoming Luo]

* configure.ac: add HURD so it can be used in conditional in am files
* sys-utils/Makemodule.am: compile hwclock for GNU Hurd
* sys-utils/hwclock-rtc.c: compile for GNU Hurd
* sys-utils/hwclock.c: compile for GNU Hurd
* sys-utils/hwclock.h: compile for GNU Hurd

Signed-off-by: Zhaoming Luo 
---
 configure.ac|  6 +-
 sys-utils/Makemodule.am |  5 +
 sys-utils/hwclock-rtc.c | 19 ++-
 sys-utils/hwclock.c |  2 +-
 sys-utils/hwclock.h |  4 +++-
 5 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 698da36c6..8de6af616 100644
--- a/configure.ac
+++ b/configure.ac
@@ -263,16 +263,20 @@ AC_PATH_PROG([XSLTPROC], [xsltproc])
 
 linux_os=no
 bsd_os=no
+gnu_os=no
 AS_CASE([${host_os}],
   [*linux*],
  [linux_os=yes],
   [*darwin*],
  [darwin_os=yes],
   [*bsd*],
- [bsd_os=yes])
+ [bsd_os=yes],
+  [gnu*],
+ [gnu_os=yes])
 AM_CONDITIONAL([LINUX], [test "x$linux_os" = xyes])
 AM_CONDITIONAL([DARWIN], [test "x$darwin_os" = xyes])
 AM_CONDITIONAL([BSD], [test "x$bsd_os" = xyes])
+AM_CONDITIONAL([HURD], [test "x$gnu_os" = xyes])
 
 AS_IF([test  "x$darwin_os" = xyes], [
   AC_DEFINE([_DARWIN_C_SOURCE], [1], [Enable MAP_ANON in sys/mman.h on Mac OS 
X])
diff --git a/sys-utils/Makemodule.am b/sys-utils/Makemodule.am
index 209b656b0..8cc69be60 100644
--- a/sys-utils/Makemodule.am
+++ b/sys-utils/Makemodule.am
@@ -570,6 +570,11 @@ hwclock_SOURCES += \
lib/monotonic.c
 hwclock_LDADD += $(REALTIME_LIBS)
 endif
+if HURD
+hwclock_SOURCES += \
+   sys-utils/hwclock-rtc.c \
+   lib/monotonic.c
+endif
 if HAVE_AUDIT
 hwclock_LDADD += -laudit
 endif
diff --git a/sys-utils/hwclock-rtc.c b/sys-utils/hwclock-rtc.c
index 2796f2e8a..7acf09d43 100644
--- a/sys-utils/hwclock-rtc.c
+++ b/sys-utils/hwclock-rtc.c
@@ -8,10 +8,15 @@
  *
  * rtc.c - Use /dev/rtc for clock access
  */
+#ifdef __GNU__
+#include 
+#include 
+#else
 #include 
-#include 
 #include 
 #include 
+#endif /* __GNU__ */
+#include 
 #include 
 #include 
 #include 
@@ -28,6 +33,7 @@
 
 #include "hwclock.h"
 
+#ifndef __GNU__
 #ifndef RTC_PARAM_GET
 struct rtc_param {
__u64 param;
@@ -60,6 +66,7 @@ const struct hwclock_param *get_hwclock_params(void)
 {
return hwclock_params;
 }
+#endif /* __GNU__ */
 
 /*
  * /dev/rtc is conventionally chardev 10/135
@@ -99,12 +106,20 @@ static int open_rtc(const struct hwclock_control *ctl)
/* --rtc option has been given */
if (ctl->rtc_dev_name) {
rtc_dev_name = ctl->rtc_dev_name;
+#ifdef __GNU__
+   rtc_dev_fd = open(rtc_dev_name, O_RDWR);
+#else
rtc_dev_fd = open(rtc_dev_name, O_RDONLY);
+#endif
} else {
for (i = 0; i < ARRAY_SIZE(fls); i++) {
if (ctl->verbose)
printf(_("Trying to open: %s\n"), fls[i]);
+#ifdef __GNU__
+   rtc_dev_fd = open(fls[i], O_RDWR);
+#else
rtc_dev_fd = open(fls[i], O_RDONLY);
+#endif
 
if (rtc_dev_fd < 0) {
if (errno == ENOENT || errno == ENODEV)
@@ -411,6 +426,7 @@ int set_epoch_rtc(const struct hwclock_control *ctl)
 
 
 
+#ifndef __GNU__
 static int resolve_rtc_param_alias(const char *alias, __u64 *value)
 {
const struct hwclock_param *param = &hwclock_params[0];
@@ -609,3 +625,4 @@ int rtc_vl_clear(const struct hwclock_control *ctl)
 
return 0;
 }
+#endif /* __GNU__ */
diff --git a/sys-utils/hwclock.c b/sys-utils/hwclock.c
index 2b33dfbce..2714775f9 100644
--- a/sys-utils/hwclock.c
+++ b/sys-utils/hwclock.c
@@ -989,7 +989,7 @@ static void determine_clock_access_method(const struct 
hwclock_control *ctl)
if (ctl->directisa)
ur = probe_for_cmos_clock();
 #endif
-#ifdef __linux__
+#if defined(__linux__) || defined(__GNU__)
if (!ur)
ur = probe_for_rtc_clock(ctl);
 #endif
diff --git a/sys-utils/hwclock.h b/sys-utils/hwclock.h
index 2522d6c7d..4cbbff957 100644
--- a/sys-utils/hwclock.h
+++ b/sys-utils/hwclock.h
@@ -36,8 +36,10 @@ struct hwclock_control {
 #if defined(__linux__) && defined(__alpha__)
char *epoch_option;
 #endif
-#ifdef __linux__
+#if defined(__linux__) || defined(__GNU__)
char *rtc_dev_name;
+#endif
+#ifdef __linux__
uint32_t param_idx; /* --param-index  */
 #endif
char *param_get_option;
-- 
2.47.1

Re: [PATCH Web] Add an introduction about a mig-mutate.h file

[Zhaoming Luo]

On 12/8/24 9:26 PM, jbra...@dismail.de wrote:

December 7, 2024 at 7:11 PM, "Zhaoming Luo" mailto:zhming...@163.com?to=%22Zhaoming%20Luo%22%20%3Czhmingluo%40163.com%3E > wrote:





Add a link pointing to an introduction about a mig-mutate.h file


I do think this is a good contribution to the wiki, but I personally
think it would be a little better if we just put the text in a new
wiki page instead of linking to the email.  Just my opinion.

I got stuck at the layout of the wiki page. My opinion is creating a 
wiki page in a Q&A form, just like the IRC log pieces, but it seems to 
be different to the IRC log pieces (it's longer). Do you any 
recommendations? Or any existing wiki page I can emulate (I think it's 
important to make the wiki consistent).


--
Zhaoming Luo

[PATCH Web] Add an introduction about a mig-mutate.h file

[Zhaoming Luo]

Add a link pointing to an introduction about a mig-mutate.h file

* microkernel/mach/mig/documentation.mdwn: new further relevant 
documentation
---
 microkernel/mach/mig/documentation.mdwn | 1 +
 1 file changed, 1 insertion(+)

diff --git a/microkernel/mach/mig/documentation.mdwn 
b/microkernel/mach/mig/documentation.mdwn
index 740949e0..06536386 100644
--- a/microkernel/mach/mig/documentation.mdwn
+++ b/microkernel/mach/mig/documentation.mdwn
@@ -85,6 +85,7 @@ pp. 67--77."
 
   * MIG *in action*: [[hurd/io_path]].
 
+  * [*Introduction to a mig-mutate.h 
file*](https://mail.gnu.org/archive/html/bug-hurd/2024-11/msg00045.html), a 
text by Sergey Bugaev
 
 ## IRC, freenode, #hurd, 2013-09-04
 
-- 
2.47.1

[RFC PATCH glibc v3] mach: Add CLOCK_MONOTONIC case in clock_gettime()

[Zhaoming Luo]

mach: Add CLOCK_MONOTONIC case in clock_gettime()

The Mach RPC host_get_uptime64() is implemented. It returns the elapsed time
value since bootup. See

https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=fc494bfe3fb6363e1077dc035eb119970d84a9d1

In this patch, the RPC is used to implement the monotonic clock for
mach.

* config.h.in: Add HAVE_HOST_GET_UPTIME64 config entry
* sysdeps/mach/clock_gettime.c: Add CLOCK_MONOTONIC case
* sysdeps/mach/configure: Check the existence of host_get_uptime64 RPC
* sysdeps/mach/configure.ac: Check the existence of host_get_uptime64 RPC

---
 config.h.in  |  3 +++
 sysdeps/mach/clock_gettime.c | 25 +
 sysdeps/mach/configure   | 30 ++
 sysdeps/mach/configure.ac|  2 ++
 4 files changed, 60 insertions(+)

diff --git a/config.h.in b/config.h.in
index c26f98ccd6..cdbd555366 100644
--- a/config.h.in
+++ b/config.h.in
@@ -163,6 +163,9 @@
 /* Mach specific: define if the `host_page_size' RPC is available.  */
 #undef HAVE_HOST_PAGE_SIZE
 
+/* Mach specific: define if the `host_get_uptime64' RPC is available.  */
+#undef HAVE_HOST_GET_UPTIME64
+
 /* Mach specific: define if the `thread_set_name' RPC is available.  */
 #undef  HAVE_MACH_THREAD_SET_NAME
 
diff --git a/sysdeps/mach/clock_gettime.c b/sysdeps/mach/clock_gettime.c
index 6fffad39f5..b29acab908 100644
--- a/sysdeps/mach/clock_gettime.c
+++ b/sysdeps/mach/clock_gettime.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Get the current time of day, putting it into *TS.
Returns 0 on success, -1 on errors.  */
@@ -31,6 +32,30 @@ __clock_gettime (clockid_t clock_id, struct timespec *ts)
 
   switch (clock_id) {
 
+case CLOCK_MONOTONIC:
+/* If HAVE_HOST_GET_UPTIME64 is not defined, CLOCK_MONOTONIC will be equivalent
+   to CLOCK_REALTIME.  */
+#ifdef HAVE_HOST_GET_UPTIME64
+  {
+   time_value64_t tv;
+   err = __host_get_uptime64 (__mach_host_self (), &tv);
+
+   if (err)
+ {
+   if (err == MIG_BAD_ID)
+ {
+   /* Not supported by the running kernel.  */
+   __set_errno (EINVAL);
+ }
+   else
+ __set_errno (err);
+   return -1;
+ }
+   TIME_VALUE64_TO_TIMESPEC (&tv, ts);
+   return 0;
+  }
+#endif
+
 case CLOCK_REALTIME:
   {
/* __host_get_time can only fail if passed an invalid host_t.
diff --git a/sysdeps/mach/configure b/sysdeps/mach/configure
index abfe084fda..8aa6bbb18b 100644
--- a/sysdeps/mach/configure
+++ b/sysdeps/mach/configure
@@ -461,6 +461,36 @@ if test $libc_cv_mach_rpc_host_page_size = yes; then
 
 fi
 
+{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for host_get_uptime64 
in mach_host.defs" >&5
+printf %s "checking for host_get_uptime64 in mach_host.defs... " >&6; }
+if test ${libc_cv_mach_rpc_host_get_uptime64+y}
+then :
+  printf %s "(cached) " >&6
+else case e in #(
+  e) cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+#include 
+
+_ACEOF
+if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
+  $EGREP_TRADITIONAL "host_get_uptime64" >/dev/null 2>&1
+then :
+  libc_cv_mach_rpc_host_get_uptime64=yes
+else case e in #(
+  e) libc_cv_mach_rpc_host_get_uptime64=no ;;
+esac
+fi
+rm -rf conftest*
+ ;;
+esac
+fi
+{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: 
$libc_cv_mach_rpc_host_get_uptime64" >&5
+printf "%s\n" "$libc_cv_mach_rpc_host_get_uptime64" >&6; }
+if test $libc_cv_mach_rpc_host_get_uptime64 = yes; then
+  printf "%s\n" "#define HAVE_HOST_GET_UPTIME64 1" >>confdefs.h
+
+fi
+
 { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for thread_set_name in 
gnumach.defs" >&5
 printf %s "checking for thread_set_name in gnumach.defs... " >&6; }
 if test ${libc_cv_mach_rpc_thread_set_name+y}
diff --git a/sysdeps/mach/configure.ac b/sysdeps/mach/configure.ac
index 6dfa2b3518..08e5fdefe9 100644
--- a/sysdeps/mach/configure.ac
+++ b/sysdeps/mach/configure.ac
@@ -92,6 +92,8 @@ fi
 
 mach_RPC_CHECK(mach_host.defs, host_page_size,
   HAVE_HOST_PAGE_SIZE)
+mach_RPC_CHECK(mach_host.defs, host_get_uptime64,
+  HAVE_HOST_GET_UPTIME64)
 mach_RPC_CHECK(gnumach.defs, thread_set_name,
   HAVE_MACH_THREAD_SET_NAME)
 mach_RPC_CHECK(gnumach.defs, thread_get_name,
-- 
2.45.2

[RFC PATCH glibc v2 1/1] hurd: Add CLOCK_MONOTONIC case in clock_gettime()

[Zhaoming Luo]

hurd: Add CLOCK_MONOTONIC case in clock_gettime()

The Mach RPC host_get_uptime64() is implemented. It returns the elapsed time
value since bootup. See

https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=fc494bfe3fb6363e1077dc035eb119970d84a9d1

In this patch, the RPC is used to implement the monotonic clock for
mach.

* config.h.in: Add HAVE_HOST_GET_UPTIME64 config entry
* sysdeps/mach/clock_gettime.c: Add CLOCK_MONOTONIC case
* sysdeps/mach/configure: Check the existence of host_get_uptime64 RPC
* sysdeps/mach/configure.ac: Check the existence of host_get_uptime64 RPC

---
 config.h.in  |  3 +++
 sysdeps/mach/clock_gettime.c | 25 +
 sysdeps/mach/configure   | 30 ++
 sysdeps/mach/configure.ac|  2 ++
 4 files changed, 60 insertions(+)

diff --git a/config.h.in b/config.h.in
index c26f98ccd6..cdbd555366 100644
--- a/config.h.in
+++ b/config.h.in
@@ -163,6 +163,9 @@
 /* Mach specific: define if the `host_page_size' RPC is available.  */
 #undef HAVE_HOST_PAGE_SIZE
 
+/* Mach specific: define if the `host_get_uptime64' RPC is available.  */
+#undef HAVE_HOST_GET_UPTIME64
+
 /* Mach specific: define if the `thread_set_name' RPC is available.  */
 #undef  HAVE_MACH_THREAD_SET_NAME
 
diff --git a/sysdeps/mach/clock_gettime.c b/sysdeps/mach/clock_gettime.c
index 6fffad39f5..546514b8ee 100644
--- a/sysdeps/mach/clock_gettime.c
+++ b/sysdeps/mach/clock_gettime.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Get the current time of day, putting it into *TS.
Returns 0 on success, -1 on errors.  */
@@ -31,6 +32,30 @@ __clock_gettime (clockid_t clock_id, struct timespec *ts)
 
   switch (clock_id) {
 
+case CLOCK_MONOTONIC:
+/* If HAVE_HOST_GET_UPTIME64 is not defined, CLOCK_MONOTONIC will be equivalent
+   to CLOCK_REALTIME.  */
+#ifdef HAVE_HOST_GET_UPTIME64
+  {
+   time_value64_t tv;
+   err = __host_get_uptime64 (__mach_host_self (), &tv);
+
+   if (err)
+ {
+   if (err == MIG_BAD_ID)
+ {
+   /* Not supported by the running kernel.  */
+   __set_errno(EINVAL);
+ }
+   else
+ __set_errno(err);
+   return -1;
+ }
+   TIME_VALUE64_TO_TIMESPEC (&tv, ts);
+   return 0;
+  }
+#endif
+
 case CLOCK_REALTIME:
   {
/* __host_get_time can only fail if passed an invalid host_t.
diff --git a/sysdeps/mach/configure b/sysdeps/mach/configure
index abfe084fda..8aa6bbb18b 100644
--- a/sysdeps/mach/configure
+++ b/sysdeps/mach/configure
@@ -461,6 +461,36 @@ if test $libc_cv_mach_rpc_host_page_size = yes; then
 
 fi
 
+{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for host_get_uptime64 
in mach_host.defs" >&5
+printf %s "checking for host_get_uptime64 in mach_host.defs... " >&6; }
+if test ${libc_cv_mach_rpc_host_get_uptime64+y}
+then :
+  printf %s "(cached) " >&6
+else case e in #(
+  e) cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+#include 
+
+_ACEOF
+if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
+  $EGREP_TRADITIONAL "host_get_uptime64" >/dev/null 2>&1
+then :
+  libc_cv_mach_rpc_host_get_uptime64=yes
+else case e in #(
+  e) libc_cv_mach_rpc_host_get_uptime64=no ;;
+esac
+fi
+rm -rf conftest*
+ ;;
+esac
+fi
+{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: 
$libc_cv_mach_rpc_host_get_uptime64" >&5
+printf "%s\n" "$libc_cv_mach_rpc_host_get_uptime64" >&6; }
+if test $libc_cv_mach_rpc_host_get_uptime64 = yes; then
+  printf "%s\n" "#define HAVE_HOST_GET_UPTIME64 1" >>confdefs.h
+
+fi
+
 { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for thread_set_name in 
gnumach.defs" >&5
 printf %s "checking for thread_set_name in gnumach.defs... " >&6; }
 if test ${libc_cv_mach_rpc_thread_set_name+y}
diff --git a/sysdeps/mach/configure.ac b/sysdeps/mach/configure.ac
index 6dfa2b3518..08e5fdefe9 100644
--- a/sysdeps/mach/configure.ac
+++ b/sysdeps/mach/configure.ac
@@ -92,6 +92,8 @@ fi
 
 mach_RPC_CHECK(mach_host.defs, host_page_size,
   HAVE_HOST_PAGE_SIZE)
+mach_RPC_CHECK(mach_host.defs, host_get_uptime64,
+  HAVE_HOST_GET_UPTIME64)
 mach_RPC_CHECK(gnumach.defs, thread_set_name,
   HAVE_MACH_THREAD_SET_NAME)
 mach_RPC_CHECK(gnumach.defs, thread_get_name,
-- 
2.45.2

[RFC PATCH glibc v2 0/1] hurd: Add CLOCK_MONOTONIC case in clock_gettime()

[Zhaoming Luo]

Compared with v1: follow the following emails suggestions:
https://mail.gnu.org/archive/html/bug-hurd/2025-01/msg00011.html
https://mail.gnu.org/archive/html/bug-hurd/2025-01/msg2.html
https://mail.gnu.org/archive/html/bug-hurd/2025-01/msg00019.html

Is there anything I need to add before submitting the 1/1 patch to
glibc? I think the website mentions I need to mention my assignment form
status. Not sure where to add it. Should I add it in cover-letter?

Zhaoming Luo (1):
  hurd: Add CLOCK_MONOTONIC case in clock_gettime()

 config.h.in  |  3 +++
 sysdeps/mach/clock_gettime.c | 25 +
 sysdeps/mach/configure   | 30 ++
 sysdeps/mach/configure.ac|  2 ++
 4 files changed, 60 insertions(+)

-- 
2.45.2

Re: [RFC PATCH glic] hurd: Add CLOCK_MONOTONIC case in clock_gettime()

[Zhaoming Luo]

On 1/1/25 5:50 PM, Sergey Bugaev wrote:

Happy New Year!

Happy New Year


On Wed, Jan 1, 2025 at 12:25 PM Zhaoming Luo  wrote:


---
  sysdeps/mach/clock_gettime.c | 12 
  1 file changed, 12 insertions(+)

diff --git a/sysdeps/mach/clock_gettime.c b/sysdeps/mach/clock_gettime.c
index 6fffad39f5..22faf85730 100644
--- a/sysdeps/mach/clock_gettime.c
+++ b/sysdeps/mach/clock_gettime.c
@@ -31,6 +31,18 @@ __clock_gettime (clockid_t clock_id, struct timespec *ts)

switch (clock_id) {

+case CLOCK_MONOTONIC:
+  {
+   /* __host_get_uptime64 can only fail if passed an invalid host_t.
+  __mach_host_self could theoretically fail (producing an
+  invalid host_t) due to resource exhaustion, but we assume
+  this will never happen.  */
+   time_value64_t tv;
+   __host_get_uptime64 (__mach_host_self (), &tv);


mach_host_self () cannot really fail, it just always returns 2 (the
cached result of the underlying mach_host_self Mach trap, see
glibc:mach/mach_init.c). So indeed no need to consider that case.

host_get_uptime64 was just added (by you) to gnumach, right? So what
can quite likely happen is:

- it's not present in the version of Mach that glibc is being built against
- it's not present in the version of Mach that glibc is being run on

in the latter case, you should get MIG_BAD_ID from the kernel, so you
can detect that.
What's the best way to handle the MIG_BAD_ID case. I tried perror(NULL) 
but it gave my output '(ipc/mig) bad request message ID'. To be honest I 
don't think it's a very useful output. Is there a better option?


It's also a good idea to handle RPCs failing for misc reasons, so
please don't just ignore the return code. If there's nothing better to
do with it, assert_perror (err) will abort with the error message, but
maybe in this case it would make more sense to propagate the failure
to the caller, even if it's not supposed to happen.

OK. I will do the following:
```
__set_errno(err);
return -1;
```

--
Zhaoming Luo

Re: [RFC PATCH glic] hurd: Add CLOCK_MONOTONIC case in clock_gettime()

[Zhaoming Luo]

On 1/1/25 5:51 PM, Zhaoming Luo wrote:

---
  sysdeps/mach/clock_gettime.c | 12 
  1 file changed, 12 insertions(+)
The website[0] mentions making `gettimeofday()` use the CLOCK_MONOTONIC. 
Does that refer to this one[1]?


[0]: https://darnassus.sceen.net/~hurd-web/open_issues/clock_gettime/
[1]: 
https://sourceware.org/git?p=glibc.git;a=blob;f=time/gettimeofday.c;h=bf92756cae906b9afff44d302800babbb1413b4a;hb=HEAD#l26


diff --git a/sysdeps/mach/clock_gettime.c b/sysdeps/mach/clock_gettime.c
index 6fffad39f5..22faf85730 100644
--- a/sysdeps/mach/clock_gettime.c
+++ b/sysdeps/mach/clock_gettime.c
@@ -31,6 +31,18 @@ __clock_gettime (clockid_t clock_id, struct timespec *ts)
  
switch (clock_id) {
  
+case CLOCK_MONOTONIC:

+  {
+   /* __host_get_uptime64 can only fail if passed an invalid host_t.
+  __mach_host_self could theoretically fail (producing an
+  invalid host_t) due to resource exhaustion, but we assume
+  this will never happen.  */
+   time_value64_t tv;
+   __host_get_uptime64 (__mach_host_self (), &tv);
+   TIME_VALUE64_TO_TIMESPEC (&tv, ts);
+   return 0;
+  }
+
  case CLOCK_REALTIME:
{
/* __host_get_time can only fail if passed an invalid host_t.


--
Zhaoming Luo

[PATCH Web] Translator: Add the introduction to the rtc translator

[Zhaoming Luo]

 * hurd/translator.mdwn: Add an entry for the rtc translator
 * hurd/translator/rtc.mdwn: Add the introduction to the rtc translator

Signed-off-by: Zhaoming Luo 
---
 hurd/translator.mdwn |  1 +
 hurd/translator/rtc.mdwn | 17 +
 2 files changed, 18 insertions(+)
 create mode 100644 hurd/translator/rtc.mdwn

diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn
index 324c5f8c..fe669a12 100644
--- a/hurd/translator.mdwn
+++ b/hurd/translator.mdwn
@@ -121,6 +121,7 @@ The [[concept|concepts]] of translators creates its own 
problems, too:
 * [[term]]
 * [[checkperms]]
 * [[usermux]]
+* [[rtc]]
 * ...
 
 
diff --git a/hurd/translator/rtc.mdwn b/hurd/translator/rtc.mdwn
new file mode 100644
index ..40fe8725
--- /dev/null
+++ b/hurd/translator/rtc.mdwn
@@ -0,0 +1,17 @@
+[[!meta copyright="Copyright © 2025 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+The *rtc* translator implements a real-time clock driver. It can be used to add
+the `rtc` device files.
+
+# Usage Example
+Setup a `rtc` device file in `/tmp`:
+
+settrans -c /tmp/rtc /hurd/rtc
-- 
2.47.1

[PATCH Web v2] Translator: Add the introduction to the rtc translator

[Zhaoming Luo]

 * hurd/translator.mdwn: Add an entry for the rtc translator
 * hurd/translator/rtc.mdwn: Add the introduction to the rtc translator

---
 hurd/translator.mdwn |  1 +
 hurd/translator/rtc.mdwn | 31 +++
 2 files changed, 32 insertions(+)
 create mode 100644 hurd/translator/rtc.mdwn

diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn
index 324c5f8c..fe669a12 100644
--- a/hurd/translator.mdwn
+++ b/hurd/translator.mdwn
@@ -121,6 +121,7 @@ The [[concept|concepts]] of translators creates its own 
problems, too:
 * [[term]]
 * [[checkperms]]
 * [[usermux]]
+* [[rtc]]
 * ...
 
 
diff --git a/hurd/translator/rtc.mdwn b/hurd/translator/rtc.mdwn
new file mode 100644
index ..7a917b46
--- /dev/null
+++ b/hurd/translator/rtc.mdwn
@@ -0,0 +1,31 @@
+[[!meta copyright="Copyright © 2025 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+The *rtc* translator implements a real-time clock driver. It can be used to add
+the `rtc` device files, with those files, we can access the underlying
+real-time clock using `ioctl()`. The description of `ioctl()` can be found
+[here](https://www.gnu.org/software/libc/manual/html_node/IOCTLs.html).
+
+The operation macros are required to access the real-time clock. They are
+defined as `RTC_*` in `hurd/rtc.h`.
+
+The `hwclock` command from `util-linux` can use the `rtc` device files to
+access the real-time clock devices.
+
+# Usage Example
+Setup a `rtc` device file in `/tmp`:
+
+settrans -c /tmp/rtc /hurd/rtc
+
+Read the time value through the `rtc` device file:
+ 
+int fd = open("/tmp/rtc", O_RDONLY);
+struct rtc_time time;
+ioctl(fd, RTC_RD_TIME, &time);
-- 
2.47.1

Re: [PATCH Mach] kern: Add a mach host operation which returns elapsed time since bootup

[Zhaoming Luo]

On 12/29/24 9:28 AM, Samuel Thibault wrote:

Hello,

Zhaoming Luo, le mar. 24 déc. 2024 09:57:51 +0800, a ecrit:

Add host_get_uptime64() mach interface operation. It can be used to get
the time passed since the boot up.

* doc/mach.texi: Add the documentation for the operation
* include/mach/mach_host.defs: Add the interface
* include/mach/time_value.h: Extend the mappable time variable
* kern/mach_clock.c: Operation implementation
* kern/mach_clock.h: Add a new variable for storing uptime


Applied, thanks!

The glibc part is now needed in clock_gettime


Do you mean adding CLOCK_MONOTONIC case in clock_gettime()?

--
Zhaoming Luo

Re: [PATCH Mach] kern: Add a mach host operation which returns elapsed time since bootup

[Zhaoming Luo]

On 12/29/24 5:21 PM, Samuel Thibault wrote:

Zhaoming Luo, le dim. 29 déc. 2024 12:44:27 +0800, a ecrit:

On 12/29/24 9:28 AM, Samuel Thibault wrote:

Hello,

Zhaoming Luo, le mar. 24 déc. 2024 09:57:51 +0800, a ecrit:

Add host_get_uptime64() mach interface operation. It can be used to get
the time passed since the boot up.

* doc/mach.texi: Add the documentation for the operation
* include/mach/mach_host.defs: Add the interface
* include/mach/time_value.h: Extend the mappable time variable
* kern/mach_clock.c: Operation implementation
* kern/mach_clock.h: Add a new variable for storing uptime


Applied, thanks!

The glibc part is now needed in clock_gettime


Do you mean adding CLOCK_MONOTONIC case in clock_gettime()?


Yes.

Does it worth to expose the CLOCK_MONOTONIC part in /dev/time device?

--
Zhaoming Luo

Re: vim testsuite: Test_platform_name

[Zhaoming Luo]

On Mon, Feb 03, 2025 at 02:14:14PM +0800, Yuqian Yang wrote:
> On 2025-02-03 12:58, Zhaoming Luo wrote:
> 
> > ... I haven't found a
> > practical method to track where the BSD macro is defined during
> > compilation.
> 
> It is defined in `/usr/include/x86_64-gnu/bits/param.h'.
> 
> The including chain is,
> 
> vim/src/evalfunc.c
> vim/src/os_unix.h
> /usr/include/x86_64-gnu/sys/param.h
> /usr/include/x86_64-gnu/bits/param.h
> 
> In /usr/include/x86_64-gnu/bits/param.h:
>   #define BSD 199306

Cool how to you find it?

> 
> Though I don't know why there is a macro BSD, vim seems to use it
> to detect BSD.
> 
> -- 
> Yuqian Yang 

Re: vim testsuite: Test_keep_pty_open

[Zhaoming Luo]

On Mon, Feb 03, 2025 at 08:39:09AM +0100, Samuel Thibault wrote:
> Hello,
> 
> Zhaoming Luo, le lun. 03 févr. 2025 12:22:11 +0800, a ecrit:
> > It's still the case with different sleep times. I believe the issue is
> > related to:
> > 
> > ```
> >   5.80 on 0: Closing channel because all readable fds are closed
> >   5.80 on 0: Closing channel
> > ```
> 
> I'm not really surprised since it sets out_io and err_io to null. And it
> is indeed saying it's back to waiting, and should be then waiting for
> the process to actually finish. You can try to add printing debugging in
> the waiting function up to the one that would be supposed to actually
> wait.
> 
> Also, to rule out python implementation concerns, maybe replace the
> python script call with your own C program that does the wait and make
> it emit debugging stuff to a /tmp file, to make sure that it's really
> still alive after the sleep.

I did the experiments using my own C waiting program and `sleep` shell
command respectively. They gave me the same result. It seems the sleep
program was not executed at all.

The C program:
```
#include 
#include 

int
main ()
{
FILE *log;
log = fopen ("log", "w");
fprintf (log, "Sleep!\n");
sleep (3);
fprintf (log, "Wake up!\n");
return 0;
}
```

Invoke vim with `./vim --clean --log vimlog`.

Run it in vim:
```
let job = job_start('/bin/sh' . ' -c "/path/to/sleep-prog"', {'out_io': 'null', 
'err_io': 'null', 'pty': 1})
```

On my Arch GNU/Linux I can see the `log` generated by the sleep program,
but on Hurd I can't, so tracking job_start may be the direction.

Another interesting thing I found is the difference between the vim logs
in the cases.

Hurd (failed):
```
...
24.49 : Starting job: /bin/sh  -c  /home/1speaker/my_sleep/main
24.50 on 0: Created channel
24.50 on 0: using pty /dev/ttyp3 on fd 4
24.50 : SafeState: Start triggering
24.50 : raw terminal output: "^[[?25l^[[1;1H^[[34h^[[?25h"
24.50 : looking for messages on channels
24.50 on 0: Closing channel because all readable fds are closed
24.50 on 0: Closing channel
24.50 : SafeState: back to waiting, triggering SafeStateAgain
24.50 : closing logfile vimlog
24.51 : looking for messages on channels
24.51 on 0: Job ended
...
```

GNU/Linux (success):
```
...
8.807417131 : Starting job: /bin/sh  -c  /home/1speaker/my_sleep/main
8.807635262 on 0: Created channel
8.807640822 on 0: using pty /dev/pts/6 on fd 4
8.809397111 : SafeState: Start triggering
8.809395859 : closing logfile vimlog
8.809519562 : raw terminal output: "[?25l[1;1H[?12l[?25h"
8.809534540 : looking for messages on channels
8.809556542 : SafeState: back to waiting, triggering SafeStateAgain
... (some key input terminal output Safestate stuff)
11.638185297 : looking for messages on channels
11.638224641 : SafeState: back to waiting, triggering SafeStateAgain
11.820336612 on 0: Job ended
11.820453161 : looking for messages on channels
11.820458742 on 0: Closing channel because all readable fds are closed
11.820463010 on 0: Closing channel
...
```

On the Hurd the channels are closed before 'Job ended', but on GNU/Linux
'Job ended' is before 'Closing channel'.

Zhaoming

Re: [PATCH 0/1] Exclude GNU/Hurd from has('bsd') feature

[Zhaoming Luo]

On Mon, Feb 03, 2025 at 04:41:13PM +0800, Zhaoming Luo wrote:
> 
> Zhaoming Luo (1):
>   Exclude GNU/Hurd from has('bsd') feature
> 
>  src/evalfunc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
As it seems not to be the correct way of submitting patch to Vim, so I
opened a RP at github[0]. Like what the vim mantainer said, I will add a
'hurd' feature so has('hurd') can return 1.

[0]: https://github.com/vim/vim/pull/16580

Zhaoming

[RFC PATCH Vim] Add support for Hurd

[Zhaoming Luo]

Please have a look, I hope the semantics are correct :).

Zhaoming

---
 runtime/doc/builtin.txt| 1 +
 src/evalfunc.c | 9 -
 src/testdir/test_functions.vim | 2 ++
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/runtime/doc/builtin.txt b/runtime/doc/builtin.txt
index d7ed7320f..310268b00 100644
--- a/runtime/doc/builtin.txt
+++ b/runtime/doc/builtin.txt
@@ -12639,6 +12639,7 @@ gui_win32s  idem, and Win32s system being 
used (Windows 3.1)
 haiku  Haiku version of Vim.
 hangul_input   Compiled with Hangul input support. |hangul|
 hpux   HP-UX version of Vim.
+hurd   Hurd version of Vim
 iconv  Can use iconv() for conversion.
 insert_expand  Compiled with support for CTRL-X expansion commands in
Insert mode. (always true)
diff --git a/src/evalfunc.c b/src/evalfunc.c
index d81480b50..27b54b7f0 100644
--- a/src/evalfunc.c
+++ b/src/evalfunc.c
@@ -6409,7 +6409,7 @@ f_has(typval_T *argvars, typval_T *rettv)
 #endif
},
{"bsd",
-#if defined(BSD) && !defined(MACOS_X)
+#if defined(BSD) && !defined(MACOS_X) && !defined(__GNU__)
1
 #else
0
@@ -6420,6 +6420,13 @@ f_has(typval_T *argvars, typval_T *rettv)
1
 #else
0
+#endif
+   },
+   {"hurd",
+#ifdef __GNU__
+   1
+#else
+   0
 #endif
},
{"linux",
diff --git a/src/testdir/test_functions.vim b/src/testdir/test_functions.vim
index f80754f0a..ca9137df3 100644
--- a/src/testdir/test_functions.vim
+++ b/src/testdir/test_functions.vim
@@ -2760,6 +2760,7 @@ func Test_platform_name()
   " Is Unix?
   call assert_equal(has('bsd'), has('bsd') && has('unix'))
   call assert_equal(has('hpux'), has('hpux') && has('unix'))
+  call assert_equal(has('hurd'), has('hurd') && has('unix'))
   call assert_equal(has('linux'), has('linux') && has('unix'))
   call assert_equal(has('mac'), has('mac') && has('unix'))
   call assert_equal(has('qnx'), has('qnx') && has('unix'))
@@ -2777,6 +2778,7 @@ func Test_platform_name()
 call assert_equal(uname =~? 'QNX', has('qnx'))
 call assert_equal(uname =~? 'SunOS', has('sun'))
 call assert_equal(uname =~? 'CYGWIN\|MSYS', has('win32unix'))
+call assert_equal(uname =~? 'GNU', has('hurd'))
   endif
 endfunc
 
-- 
2.47.2

Re: vim testsuite: Test_keep_pty_open

[Zhaoming Luo]

On Tue, Feb 04, 2025 at 09:12:18AM +0100, Samuel Thibault wrote:
> 
> Only out_io and err_io are supposed to be readable. Or did they mean
> from the point of view of the executed process. Again, it means check
> what exactly happens to end up with "all readable fds are closed"
> 

Try to keep the consistency of the mail list thread so I reply to this
email.

The investigation shows that the code[0] avoiding closing channel was
not executed because the conditional statement[1] didn't return true as
expected.

I tried to run `rpctrace -o rpclog ./vim --clean` and 
`let job = job_start('python3' . ' -c "import time;time.sleep(5)"', {'out_io': 
'null', 'err_io': 'null', 'pty': 1})
to collect the rpc log. However, it just hanged with a lot of 
`rpctrace: get an unknown send right from process 8898` and made my
terminal messy.

Intead I wrote the following program to reproduce the error:

```
#include 
#include 
#include 

int
main ()
{
int f;
int is_term;

f = open ("/dev/ttyp4", 0);

if (f == -1)
  {
  printf ("open() failed\n");
  return 0;
  }

printf ("fd: %d\n", f);

is_term = isatty (f);
if (is_term == 1)
printf ("Its refering to a terminal!\n");
else
printf ("Its not refering to a terminal!\n");

return 0;
}
```

The /dev/ttyp4 is what vim tried to check in mch_isatty:

```
...
10.22 : Starting job: python3  -c  import time;time.sleep(5)
10.22 on 0: Created channel
10.22 on 0: using pty /dev/ttyp4 on fd 4
10.22 : SafeState: Start triggering
...
```

The rpctrace log is:

```
15<--38(pid8634)->dir_lookup ("dev/ttyp4" 0 0) = 0 1 ""52<--47(pid8634)
52<--47(pid8634)->term_getctty () = 0x4009 (Bad file descriptor)
52<--47(pid8634)->term_getctty () = 0x4009 (Bad file descriptor)
23<--33(pid8634)->io_stat_request () = 0 {14 805 0 0 0 1686195767 0 8397200 1 
1001 5 0 0 1738719524 0 1738719524 0 1738719524 0 512 8 0 0 0 0 0 0 0 0 0 0 
0}
30<--42(pid8634)->io_write_request ("Its not refering to a terminal!\n" -1) = 0 
32
```

So it seems it is from the source code[2].

On GNU/Linux the program successfully opened '/dev/pts/8' (this is what
vim tried to open).

[0]: https://github.com/vim/vim/blob/master/src/channel.c#L1395
[1]: https://github.com/vim/vim/blob/master/src/channel.c#L1394
[2]: https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/term/users.c#n367

Zhaoming

Re: vim testsuite: Test_keep_pty_open

[Zhaoming Luo]

On Mon, Feb 03, 2025 at 01:21:44PM +0100, Samuel Thibault wrote:
> Zhaoming Luo, le lun. 03 févr. 2025 20:05:38 +0800, a ecrit:
> > I did the experiments using my own C waiting program and `sleep` shell
> > command respectively. They gave me the same result. It seems the sleep
> > program was not executed at all.
> 
> I'm just surprised since it has out_io and err_io set to null.

I think the test writer just didn't want to be bothered by the error
message of the sleep command [0][1].

[0]: https://vimhelp.org/channel.txt.html#job-out_io
[1]: https://vimhelp.org/channel.txt.html#job-err_io

Zhaoming

Re: vim testsuite: Test_keep_pty_open V2

[Zhaoming Luo]

On Sat, Feb 08, 2025 at 08:55:31AM +0800, Zhaoming Luo wrote:
> On Fri, Feb 07, 2025 at 01:57:01PM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le ven. 07 févr. 2025 18:44:50 +0800, a ecrit:
> > > This is V2 of figuring out the issue. V1 is abandoned due to my mistake,
> > > but this time I can confirm the source of issue. This time I ran
> > > rpctrace directly on vim, and used two printfs to locate the isatty().
> > > 
> > > ```
> > > printf ("Start isatty!\n");
> > > if (mch_isatty(in))
> > > channel->ch_to_be_closed |= (1U << PART_IN);
> > > printf ("Finish isatty!\n");
> > > ```
> > > 
> > > rpctrace output:
> > > ```
> > > ...
> > > 30<--44(pid920)->io_write_request ("Start isatty!\n" -1) = 0 14
> > > 56<--24(pid920)->term_getctty () = 0x402d (Operation not supported)
> > > 30<--44(pid920)->io_write_request ("Finish isatty!\n" -1) = 0 15
> > > ...
> > > ```
> > > 
> > > The error seems to be from [2].
> > 
> > Indeed, if it was plugged to another translator you'd get a mig bad id
> > error.
> > 
> > My guess is that it's cred->pi.class != tty_class that fails, indeed:
> > 
> > int ret = openpty(&master, &slave, s, &term, &win);
> > printf("%d\n", isatty(master));
> > printf("%d\n", isatty(slave));
> > 
> > says 0 for master on the Hurd while it says 1 on Linux
> > 
> > The pi.class != tty_class condition was previously because of a lookup,
> > but nowadays with the protected payloads we didn't need a lookup any
> > more and it was replaced with a check that we find cred in the proper
> > place. I'd say we should also accept the class being pty_class, it
> > does not seem it would harm: in the uses of term_getctty that I can see,
> > it matches the obtained cttyid with the one of the process, or it's an
> > explicit request.
> 
> Ok, I will submit a patch so EOPNOSUPP will be returned when
> cred->pi.class != pty_class is also true.
> 

I got stuck at the patch since I'm not sure whether I should add a
condition like:

```
   if (!cred
   || cred->pi.bucket != term_bucket
-  || cred->pi.class != tty_class)
+  || (cred->pi.class != tty_class && cred->pi.class != pty_class))
 return EOPNOTSUPP;
```

Or directly remove cred->pi.class != tty_class. Please feel free to
submit the patch, I can confirm that accepting pty_class can pass the
vim test Test_keep_pty_open (and a few other tests \o/).

Zhaoming

[PATCH] term: The term_getctty() accepts pty_class

[Zhaoming Luo]

The term_getctty() should accept pty_class

See
https://mail.gnu.org/archive/html/bug-hurd/2025-02/msg00061.html

* term/users.c: The term_getctty() accepts pty_class
---
 term/users.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/term/users.c b/term/users.c
index 3f449c71..bb5a9e09 100644
--- a/term/users.c
+++ b/term/users.c
@@ -358,7 +358,7 @@ S_term_getctty (struct trivfs_protid *cred,
 
   if (!cred
   || cred->pi.bucket != term_bucket
-  || cred->pi.class != tty_class)
+  || (cred->pi.class != tty_class && cred->pi.class != pty_class))
 return EOPNOTSUPP;
 
   pthread_mutex_lock (&global_lock);
-- 
2.47.2

Re: vim testsuite: Test_keep_pty_open V2

[Zhaoming Luo]

On Fri, Feb 07, 2025 at 01:57:01PM +0100, Samuel Thibault wrote:
> Zhaoming Luo, le ven. 07 févr. 2025 18:44:50 +0800, a ecrit:
> > This is V2 of figuring out the issue. V1 is abandoned due to my mistake,
> > but this time I can confirm the source of issue. This time I ran
> > rpctrace directly on vim, and used two printfs to locate the isatty().
> > 
> > ```
> > printf ("Start isatty!\n");
> > if (mch_isatty(in))
> > channel->ch_to_be_closed |= (1U << PART_IN);
> > printf ("Finish isatty!\n");
> > ```
> > 
> > rpctrace output:
> > ```
> > ...
> > 30<--44(pid920)->io_write_request ("Start isatty!\n" -1) = 0 14
> > 56<--24(pid920)->term_getctty () = 0x402d (Operation not supported)
> > 30<--44(pid920)->io_write_request ("Finish isatty!\n" -1) = 0 15
> > ...
> > ```
> > 
> > The error seems to be from [2].
> 
> Indeed, if it was plugged to another translator you'd get a mig bad id
> error.
> 
> My guess is that it's cred->pi.class != tty_class that fails, indeed:
> 
>   int ret = openpty(&master, &slave, s, &term, &win);
>   printf("%d\n", isatty(master));
>   printf("%d\n", isatty(slave));
> 
> says 0 for master on the Hurd while it says 1 on Linux
> 
> The pi.class != tty_class condition was previously because of a lookup,
> but nowadays with the protected payloads we didn't need a lookup any
> more and it was replaced with a check that we find cred in the proper
> place. I'd say we should also accept the class being pty_class, it
> does not seem it would harm: in the uses of term_getctty that I can see,
> it matches the obtained cttyid with the one of the process, or it's an
> explicit request.

Ok, I will submit a patch so EOPNOSUPP will be returned when
cred->pi.class != pty_class is also true.

Zhaoming
> 
> > [0]: https://mail.gnu.org/archive/html/bug-hurd/2025-02/msg9.html
> > [1]: https://github.com/vim/vim/blob/master/src/channel.c#L1394
> > [2]: https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/term/users.c#n362

Re: Should hurd_select returns directly when nfds == 0?

[Zhaoming Luo]

On Fri, Feb 07, 2025 at 03:00:08PM +0300, Sergey Bugaev wrote:
> On Fri, Feb 7, 2025 at 2:36 PM Zhaoming Luo  wrote:
> > Hi,
> 
> Hi,
> 
> > Thread 4 hit Breakpoint 1, __GI___select (nfds=0, readfds=0x103cc20, 
> > writefds=0x103cc40, exceptfds=0x103cc60, timeout=0x103cc84)
> > at ../sysdeps/mach/hurd/select.c:31
> > ```
> >
> > When I continue, it hangs at mach_msg[0]:
> >
> > gdb backtrace:
> > ```
> > #0  0x011a206c in __GI___mach_msg_trap () at 
> > ./build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
> > #1  0x011a2800 in __GI___mach_msg (msg=0x103cad4, option=1282, send_size=0, 
> > rcv_size=40, rcv_name=13, timeout=5, notify=0)
> 
> So, there is a timeout passed to select, and the same timeout was
> forwarded to mach_msg, it all seems to make sense?
> 
> > If my comprehension is correct, nfds == 0 means that no descriptor needs
> > to be tested:
> >
> > From POSIX:
> > ```
> > The nfds argument specifies the range of descriptors to be tested. The 
> > first nfds descriptors shall be checked in each set; that is, the 
> > descriptors from zero through nfds-1 in the descriptor sets shall be 
> > examined.
> > ```
> >
> > So probably we should directly return from hurd_select when nfds == 0?
> 
> "If the readfds, writefds, and errorfds arguments are all null
> pointers and the timeout argument is not a null pointer, select()
> blocks for the time specified, or until interrupted by a signal. If
> the readfds, writefds, and errorfds arguments are all null pointers
> and the timeout argument is a null pointer, select() blocks until
> interrupted by a signal."
> 
Thanks for the remind. I supposed `the readfds, writefds, and errorfds
arguments are all null` means readfds == writefds == errorfds == NULL.
So it will block the program for a period of time.

Zhaoming

Re: vim testsuite: Test_keep_pty_open

[Zhaoming Luo]

On Thu, Feb 06, 2025 at 02:03:26AM +0100, Samuel Thibault wrote:
> Zhaoming Luo, le mer. 05 févr. 2025 10:33:04 +0800, a ecrit:
> > On Tue, Feb 04, 2025 at 09:12:18AM +0100, Samuel Thibault wrote:
> > > Only out_io and err_io are supposed to be readable. Or did they mean
> > > from the point of view of the executed process. Again, it means check
> > > what exactly happens to end up with "all readable fds are closed"
> > 
> > Try to keep the consistency of the mail list thread so I reply to this
> > email.
> 
> Threads don't have to be linear :) On the contrary, it's useful to
> answer the mail that you want to answer to, to keep context together.
> The other small piece of thread will just remain in its own corner.

OK
> 
> > Intead I wrote the following program to reproduce the error:
> > 
> > ```
> > #include 
> > #include 
> > #include 
> > 
> > int
> > main ()
> > {
> > int f;
> > int is_term;
> > 
> > f = open ("/dev/ttyp4", 0);
> 
> Oh, does it really open it with neither O_RDONLY nor WRONLY?
> 

Err I forgot to check which system call vim uses to get the file
descriptor. My bad. After some investigation, it seems posix_openpt is
what vim uses[0]. I supposed open is the only system call that can be
used for opening file :-|.

Though I don't know why gdb tells me it uses the implementation in
$(glibc)/unix/bsd/getpt.c. Is it expected?

gdb bt:
```
#0  __x86.get_pc_thunk.bx () at ../sysdeps/i386/i686/multiarch/memset-sse2.S:97
#1  0x029a1919 in __posix_openpt (oflag=3) at ../sysdeps/unix/bsd/getpt.c:87
#2  0x00196325 in mch_openpty (ttyn=0x141946c) at pty.c:194
#3  0x00181586 in open_pty (pty_master_fd=0x1419498, pty_slave_fd=0x1419494, 
name1=0x20004574, name2=0x20004570) at os_unix.c:4613
#4  0x00182ea6 in mch_job_start (argv=0x20036720, job=0x20004560, 
options=0x1419588, is_terminal=0) at os_unix.c:5770
#5  0x002facba in job_start (argvars=0x1419d18, argv_arg=0x0, opt_arg=0x0, 
term_job=0x0) at job.c:1462
...
```

[0]: https://github.com/vim/vim/blob/master/src/pty.c#L194

Zhaoming

Re: vim testsuite: Test_keep_pty_open

[Zhaoming Luo]

On Thu, Feb 06, 2025 at 10:54:30AM +0800, Zhaoming Luo wrote:
> On Thu, Feb 06, 2025 at 02:03:26AM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le mer. 05 févr. 2025 10:33:04 +0800, a ecrit:
> > > Intead I wrote the following program to reproduce the error:
> > > 
> > > ```
> > > #include 
> > > #include 
> > > #include 
> > > 
> > > int
> > > main ()
> > > {
> > > int f;
> > > int is_term;
> > > 
> > > f = open ("/dev/ttyp4", 0);
> > 
> > Oh, does it really open it with neither O_RDONLY nor WRONLY?
> > 
> 
> Err I forgot to check which system call vim uses to get the file
> descriptor. My bad. After some investigation, it seems posix_openpt is
> what vim uses[0]. I supposed open is the only system call that can be
> used for opening file :-|.
> 
> Though I don't know why gdb tells me it uses the implementation in
> $(glibc)/unix/bsd/getpt.c. Is it expected?
> 
> gdb bt:
> ```
> #0  __x86.get_pc_thunk.bx () at 
> ../sysdeps/i386/i686/multiarch/memset-sse2.S:97
> #1  0x029a1919 in __posix_openpt (oflag=3) at ../sysdeps/unix/bsd/getpt.c:87
> #2  0x00196325 in mch_openpty (ttyn=0x141946c) at pty.c:194
> #3  0x00181586 in open_pty (pty_master_fd=0x1419498, pty_slave_fd=0x1419494, 
> name1=0x20004574, name2=0x20004570) at os_unix.c:4613
> #4  0x00182ea6 in mch_job_start (argv=0x20036720, job=0x20004560, 
> options=0x1419588, is_terminal=0) at os_unix.c:5770
> #5  0x002facba in job_start (argvars=0x1419d18, argv_arg=0x0, opt_arg=0x0, 
> term_job=0x0) at job.c:1462
> ...
> ```
> 
> [0]: https://github.com/vim/vim/blob/master/src/pty.c#L194

So I tried to open /dev/ttyp4 with O_RDWR | O_NOCTTY. The issue is
permission denied:

```
  16<--34(pid2144)->dir_lookup ("dev/ttyp4" 3 0) = 0x400d (Permission 
denied)
  31<--28(pid2144)->io_stat_request () = 0 {14 1097 0 0 0 1686195791 0 8397200 
1 1001 5 0 0 1738811410 0 1738811410 0 1738811410 0 512 8 0 0 0 132145264 
102787024 132262720 132147840 102788912 494940384 132323120 132272016}
  25<--40(pid2144)->io_write_request ("open() failed\n" -1)open() failed
```

When I run with sudo, it hanged.

Zhaoming

Should hurd_select returns directly when nfds == 0?

[Zhaoming Luo]

Hi,

When I'm checking curl test 546. I found that it went into a situation
that:

```
Thread 4 hit Breakpoint 1, __GI___select (nfds=0, readfds=0x103cc20, 
writefds=0x103cc40, exceptfds=0x103cc60, timeout=0x103cc84)
at ../sysdeps/mach/hurd/select.c:31
```

When I continue, it hangs at mach_msg[0]:

gdb backtrace:
```
#0  0x011a206c in __GI___mach_msg_trap () at 
./build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
#1  0x011a2800 in __GI___mach_msg (msg=0x103cad4, option=1282, send_size=0, 
rcv_size=40, rcv_name=13, timeout=5, notify=0)
at ./mach/msg.c:111
#2  0x011cb633 in _hurd_select (nfds=, pollfds=, 
readfds=, writefds=,
exceptfds=, timeout=, sigmask=) at ./hurd/hurdselect.c:423
```

If my comprehension is correct, nfds == 0 means that no descriptor needs
to be tested:

>From POSIX:
```
The nfds argument specifies the range of descriptors to be tested. The first 
nfds descriptors shall be checked in each set; that is, the descriptors from 
zero through nfds-1 in the descriptor sets shall be examined.
```

So probably we should directly return from hurd_select when nfds == 0?

Best,
Zhaoming

[0]:https://sourceware.org/git/?p=glibc.git;a=blob;f=hurd/hurdselect.c;h=7ece4aa371e2da050a17230e2398a7304488;hb=HEAD#l423

vim testsuite: Test_keep_pty_open V2

[Zhaoming Luo]

Hi,

This is V2 of figuring out the issue. V1 is abandoned due to my mistake,
but this time I can confirm the source of issue. This time I ran
rpctrace directly on vim, and used two printfs to locate the isatty().

```
printf ("Start isatty!\n");
if (mch_isatty(in))
channel->ch_to_be_closed |= (1U << PART_IN);
printf ("Finish isatty!\n");
```

rpctrace output:
```
...
30<--44(pid920)->io_write_request ("Start isatty!\n" -1) = 0 14
56<--24(pid920)->term_getctty () = 0x402d (Operation not supported)
30<--44(pid920)->io_write_request ("Finish isatty!\n" -1) = 0 15
...
```

The error seems to be from [2].

Best,
Zhaoming

[0]: https://mail.gnu.org/archive/html/bug-hurd/2025-02/msg9.html
[1]: https://github.com/vim/vim/blob/master/src/channel.c#L1394
[2]: https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/term/users.c#n362

Re: [PATCH] Add source code link to sidebar.

[Zhaoming Luo]

On Wed, Jan 29, 2025 at 05:28:05PM +0800, Yuqian Yang wrote:
> > That's a good idea!  Thanks for the contribution!
> 
> You are so welcome.
> 
> After struggling about my own things for several months, I turn back to Hurd
> now. I'm reading the doc now and recording some things for bootstrap of
> contributing to Hurd. So I'll mainly contribute to doc recently.
> 
> BTW, do you still remember I told you something about Lunar/Chinese New
> Year.[1] We also made some misunderstanding but reached a good agreement
> finally at that time. Briefly, the festival is just like Christmas Day in
> our culture.
> 
> TODAY IS THE DAY! Happy Lunar/Chinese New Year to Hurd community! :)
> 
> Sorry that I'm unfamiliar with most contributors here. But the same blessing
> to everyone here! Especially  Zhaoming Luo, haha!
> 
Happy New Year guys! I know this celebration is not too late ;).

Zhaoming Luo

Re: Debug into glibc with source code display in gdb on Debian

[Zhaoming Luo]

On Sun, Feb 02, 2025 at 12:00:17PM +0100, Samuel Thibault wrote:
> Zhaoming Luo, le dim. 02 févr. 2025 18:55:49 +0800, a ecrit:
> > ```
> > Thread 2 hit Breakpoint 1, _hurd_select (nfds=7, pollfds=0x0, 
> > readfds=0x103cc20, writefds=0x103cc40, exceptfds=0x103cc60,
> > timeout=0x103cba4, sigmask=0x0) at ./hurd/hurdselect.c:51
> > 51  ./hurd/hurdselect.c: No such file or directory.
> > ```
> > 
> > I expected it will show me the source code of hurdselect.c.
> 
> You need to download it with `apt source glibc` and cd into it,
> otherwise gdb can't magically invent it :)

But I invoked the gdb using the following command in $(curl-src)/tests/:

```
~/curl/tests$ ./runtests.pl 546 -g
```

I haven't found a greate way to run the command in glibc directory, as
it seems `runtests.pl` found the curl binary using relative path :/. Are
there some methods like adding a environment variable so gdb will search
in the glibc source code. And I was quite surprised that gdb in
different distributions can have different behavior :-).

Best,
Zhaoming

vim testsuite: Test_keep_pty_open

[Zhaoming Luo]

Hi,

I hope this is the right place to post the discussion like this, as I
can confirm the test failed reason is not related to vim and it's quite
hard for me to track the issue alone. I think some discussion will be
helpful to solve the issue.

In the build log[0]:

```
>From test_channel.vim:
Found errors in Test_keep_pty_open():
Run 1, 13:51:24 - 13:51:24 in  0.02 seconds:
command line..script 
/<>/src/vim-gtk3/testdir/runtest.vim[617]..function 
RunTheTest[57]..Test_keep_pty_open line 6: Expected range 200 - 1000, but got 20
Run 2, 13:51:26 - 13:51:26 in  0.03 seconds:
command line..script 
/<>/src/vim-gtk3/testdir/runtest.vim[658]..function 
RunTheTest[57]..Test_keep_pty_open line 6: Expected range 200 - 1000, but got 30
Run 3, 13:51:30 - 13:51:30 in  0.03 seconds:
command line..script 
/<>/src/vim-gtk3/testdir/runtest.vim[658]..function 
RunTheTest[57]..Test_keep_pty_open line 6: Expected range 200 - 1000, but got 30
Flaky test failed too often, giving up
```

The test source code (in vim script):
```
func Test_keep_pty_open()
  CheckUnix

  let job = job_start(s:python . ' -c "import time;time.sleep(0.2)"',
\ {'out_io': 'null', 'err_io': 'null', 'pty': 1})
  let elapsed = WaitFor({-> job_status(job) ==# 'dead'})
  call assert_inrange(200, 1000, elapsed)
  call job_stop(job)
endfunc
```

The `let job = job_start...` command in Debian Hurd can be represented using
the following command:

```
let job = job_start('python3' . ' -c "import time;time.sleep(0.2)"', {'out_io': 
'null', 'err_io': 'null', 'pty': 1})
```

When I run the vim command with running `vim --log vimlog`, I saw the
following log:

```
...
  5.79 : Starting job: python3  -c  import time;time.sleep(0.2)
  5.80 on 0: Created channel
  5.80 on 0: using pty /dev/ttyp5 on fd 4
  5.80 : SafeState: Start triggering
  5.80 : raw terminal output: 
  5.80 : looking for messages on channels
  5.80 on 0: Closing channel because all readable fds are closed
  5.80 on 0: Closing channel
  5.80 : SafeState: back to waiting, triggering SafeStateAgain
  5.80 : closing logfile vimlog
  5.81 : looking for messages on channels
  5.81 on 0: Job ended
...
```

It's still the case with different sleep times. I believe the issue is
related to:

```
  5.80 on 0: Closing channel because all readable fds are closed
  5.80 on 0: Closing channel
```

but I have no idea where to go next.

[0]: 
https://buildd.debian.org/status/fetch.php?pkg=vim&arch=hurd-i386&ver=2%3A9.1.0967-2&stamp=1736521254&raw=0

Best,
Zhaoming

vim testsuite: Test_platform_name

[Zhaoming Luo]

Hi,

This test failed is quite interesting. (source code [0])

Error log after running "make test_functions":

```
...
1 FAILED:
Found errors in Test_platform_name():
command line..script /home/1speaker/vim/src/testdir/runtest.vim[617]..function 
RunTheTest[57]..Test_platform_name line 18: Expected 0 but got 1
...
```

The issue is on this line[1].

So the story in short is that vim thinks it is compiled for bsd kernel.
You can reproduce the issue by running `:echo has('bsd')` in vim on
Hurd. The implementation of `has()` is in [2]. The `has('bsd')` is
covered by `#if defined(BSD) && !defined(MACOS_X)`[3]. I haven't found a
practical method to track where the BSD macro is defined during
compilation.

[0]: 
https://github.com/vim/vim/blob/v9.1.0967/src/testdir/test_functions.vim#L2755-L2781
[1]: 
https://github.com/vim/vim/blob/v9.1.0967/src/testdir/test_functions.vim#L2773
[2]: https://github.com/vim/vim/blob/v9.1.0967/src/evalfunc.c#L6194
[3]: https://github.com/vim/vim/blob/v9.1.0967/src/evalfunc.c#L6227-L6232

Best,
Zhaoming

Re: vim testsuite: Test_platform_name

[Zhaoming Luo]

On Mon, Feb 03, 2025 at 07:32:42AM +0100, Samuel Thibault wrote:
> Hello,
> 
> Zhaoming Luo, le lun. 03 févr. 2025 12:58:13 +0800, a ecrit:
> > So the story in short is that vim thinks it is compiled for bsd kernel.
> > You can reproduce the issue by running `:echo has('bsd')` in vim on
> > Hurd. The implementation of `has()` is in [2]. The `has('bsd')` is
> > covered by `#if defined(BSD) && !defined(MACOS_X)`[3]. I haven't found a
> > practical method to track where the BSD macro is defined during
> > compilation.
> 
> GNU/Hurd is indeed a BSD-based system. So it should be excluded
> explicitly from this test like is done for MACOS_X.

Ok I will send a patch to vim to exclude has('bsd') using
defined(__GNU__), do you think adding a has() (maybe has('hurd')?) for Hurd
should also be submitted with the patch?

Zhaoming

[PATCH 0/1] Exclude GNU/Hurd from has('bsd') feature

[Zhaoming Luo]

Hi,

I'm not sure if I should add a feature (like has('hurd')) for GNU/Hurd,
and if it should be in this patch or in a seperate patch.

Zhaoming Luo (1):
  Exclude GNU/Hurd from has('bsd') feature

 src/evalfunc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.47.2