Re: where can find S_fsys_startup?
More info so that you can look at the code; some of this duplicates in
other words what Marcus was explaining.
Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:
> In the server:
>
> Invoke the Mach system call mach_msg to receive the next message in
> the queue. -> The message is then dispatched (demuxed) using its
> message ID. The corresponding server stub is then invoked.
More specifically, for most Hurd servers this is done inside the
functions ports_manage_port_operations_one_thread and
ports_manage_port_operations_multithread in
libports/manage-one-thread.c and libports/manage-multithread.c.
The demuxer function passed into these functions is sometimes just a
MiG generated demuxer and sometimes it's a function that calls a bunch
of MiG demuxers. See libdiskfs/init-first.c (called at the end of
libdiskfs/init-main.c) and libdiskfs/demuxer.c for an example.
> So, function "fsys_startup" is provided in the client stub library,
> which is libhurd-user in the Hurd, and part of the glibc sources (but
> don't look for it, you won't find it: All the client stubs are
> automatically generated at build time. So if you build glibc, you
> will see all the RPC functions in generated files in
> build_dir/hurd/RPC_*.c or so).
So more specifically, the MiG specified demuxer (say,
diskfs_fsys_server) is a MiG-generated function, which looks at the
message which has been received, checks whether it is in the range of
fsys messages, and if it is, calls a function that unpacks it. That
function is sometimes called a "marshall" or a "stub". The former
name is because the task of packing and unpacking the message is
sometimes called marshalling and demarshalling. Then the stub calls
the real implementation of the RPC, which is the name with the capital
S (by convention). This stub is called _Xfsys_startup. What MiG
generates is a table of functions, and then it calls the one out of
this table which matches the incoming RPC. That's why you didn't see
any calls to _Xfsys_startup directly.
However, as my previous message noted, sometimes it doesn't get done
this way, and as it happens, fsys_startup isn't normally handled this
way. So pick something else to look for first, since fsys_startup is
special and weird in its implementation.
Thomas
Reply to: