Re: where can find S_fsys_startup?
I know more about hurd with your letter.
I am confused by MIG and the code produced by MIG.
It make the way more longer and harder to who want to hack hurd.
Why use it?
>> I am hacking hurd recently. And I found a lot of functions were easy to
>> their declarations,but difficult get their source code .
>> When I read source code in directory "hurd/trans", I am puzzled so much
>> the function S_fsys_startup was implemented ?
>As a general rule, lots of functions are implemented by libraries.
>For MiG server functions (that's what the S_ prefix means) they are
>often given special names indicating the library, like
>diskfs_S_fsys_startup (in libdiskfs/fsys-startup.c) or
>trivfs_S_fsys_startup (in libtrivfs/fsys-stubs.c).
>However, fsys_startup is a curiously unusual RPC. This is the RPC
>that newly starting filesystems call to their parent to "hook into"
>the rest of the filesystem hierarchy. Filesystems are normally
>started with the help of the function fshelp_start_translator_long in
>libfshelp/start-trans-long.c. If you look, you will see that it
>doesn't use MiG to process this RPC at all.
>So most implementations of fsys_startup are just stubs, and what
>matters is hidden inside fshelp_start_translator_long.
>The one exception (in libdiskfs/fsys-startup.c) is for bootstrapping,
>where it happens that the normal MiG stub is used to dispatch the
>fsys_startup RPC that the initial exec server makes, which is all
>really happening in libdiskfs/boot-start.c. This is because the first
>execserver translator is not actually started through
>fshelp_start_translator_long, but is instead loaded and started by the
>To UNSUBSCRIBE, email to debian-hurd-REQUEST@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact
--ÎÈ¶¨¿É¿¿µÄµç×ÓÐÅÏä ÓïÒôÓÊ¼þ ÒÆ¶¯ÊéÇ© ÈÕÀú·þÎñ ÍøÂç´æ´¢...ÒÚÓÊÎ´¾¡