bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Zhaoming Luo
Subject: Re: [RFC PATCH] Adding RTC device (work in progress)
Date: Wed, 6 Nov 2024 09:28:14 +0800
User-agent: Mozilla Thunderbird

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]