> I was thinking about implementing something that kept /var/run/mtab up > to date. One idea is to let it at a simple file that fs-like > translators could voluntarily update - but that's moderately ugly. > > More elegant IMO would be a translator sitting there (or wherever). > ext2fs and friends would still need to provide it with the info, of > course ... so how do they get the connection to the mtab-server? I think that this will be difficult. The ext2fs server, and any other Hurd server for that matter, uses stores when dealing with large unformatted data blocks. A store is expressed using lengths and runs. Therefore, you will not get, e.g. /dev/hd0s2, when you are expressing file stores, memory stores, layered stores or interleaved stores. Take a look at the code in hurd/libstore/open.c to see how store names are parsed and generated. > How does sush get a port to the passwd server? Through a well-known > path? Look in <hurd/paths.h> and you will find the _SERVERS_PASSWORD macro. You can then use that and the file_name_lookup function found in <hurd.h> to get a send right to the password server: file_t server; server = file_name_lookup (_SERVERS_PASSWORD, 0, 0); You do not need to specify any flags (the second parameter) or the open mode (the third) as you are not going to be using any io functions (i.e. those found in <hurd/io.defs> and <hurd/fs.defs>). You can then, using MiG, generate user side stubs from <hurd/password.defs> to talk to the password server.
Attachment:
pgpUYW1w8iwl7.pgp
Description: PGP signature