[[!meta copyright="Copyright © 2013 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]]."]]"""]] [[!tag open_issue_hurd]] # IRC, freenode, #hurd, 2013-04-17 thinking how to get the listing. traversing would be ineffecient, trying to come up with something better what listing ? and traversing what ? mtab well i assumed so be more precise please when the translator is done initalized are written to /etc/mtab will be provided by the translator, and when some one want to read the info just read it this way if their is some credentials like ftp sites pass username can be masked by the translator if some trans dont want to list them, no need to write to file | while unmounting (sorry i couldnt find the right word) , it will pass the mount node address | will have special structure to remove/add mounts example "a /mount-to /mount-from" = add , "r /mount-to" = remove here "/mount-to" will be unique for every mount this have a draw back , we would have to trust trans for the listed data | also "/mount-to" + "/mount-from" could be used a combination for making sure that other trans unable remove others trans mount data sorry but "also "/mount-to" + "/mount-from" could be used a combination for making sure that other trans unable remove others trans mount data" this is a bad idea if we had to print the whole thing braunr, whats ur opinion? you don't need a mtab to "unmount" things on hurd kuldeepdhaka: hum, have you read the project idea ? http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/mtab/ A more promising approach is to have mtab exported by a special translator, which gathers the necessary information on demand. This could work by traversing the tree of translators, asking each one for mount points attached to it. pinotree, not to unmount, i mean is to remove the for a first implementation, i'd suggest a recursive traversal of root-owned translators braunr, hum, but it did stated it as inefficient where ? para 5 , line 3 and line 6 no traversing "all" nodes would be inefficient translators which host the nodes of other translators could maintain a simple list of active translators ext2fs, e.g. (if that's not already the case) could keep the list of the translators it started we can already see that list with pstree for example but this new list would only retain those relevant for mtab i.e. root-owned ones i would not limit to those though and then filter on their type (e.g. file system ones) pinotree: why ? this way you could have proper per-user /proc/$pid/mounts info we could also very easily have a denial of service but how will the mount point and source point will be listed? they're returned by the translator k you ask /, it returns its store and its options, and asks its children recursively a /home translator would return its store and its options etc.. each translator would build the complete path before returning it sort of, it's very basic but that would be a very hurdish way to do it shall /etc/mtab should be made seek-able and what should be the filesize? content are generated on demand so, it could arise problem (fsize:0 , seek-able:no), ur opinions? kuldeepdhaka: it should have all the properties of a regular file the filesize would be determined after it's generated being empty doesn't imply it's not seekable content is generated on demand so, could cause problem while seeking and filesize, shall i still program as regular file? in two different read, it could generate different content, though same seek pos is used... what ? the content is generated on open ooh, ok # IRC, freenode, #hurd, 2013-06-04 how to see list of all connected translators? you can't directly you can use ps to list processes and guess which are translators (e.g. everything starting with /hurd/) a recursive call to obtain such a list would be useful similar to what's needed to implement /proc/mounts # IRC, freenode, #hurd, 2013-06-25 In context of [[microkernel/mach/mig/documentation/structured_data]]. should I go for an iterator like interface instead? btw, what's the expected roundtrip time? don't think that way consider the round trip delay as varying y, is it that bad? no but the less there is the better we think the same with system calls even if they're faster the delay itself isn't the real issue look at how proc provides information (in procfs for example) ## IRC, freenode, #hurd, 2013-06-26 so tell me about the more hurdish way of dealing with that issue creating a specialized translator for this? 11:45 < pinotree> there's also http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/mtab/ about that topic you need to avoid thinking with centralization in mind the hurd is a distributed system in practice i think proc is the only centralized component in there braunr: would having an mtab translator and having fs translators register to thae be acceptable? that* teythoon: why do you want to centralize it ? translators already register themselves when they get attached to a node we don't want an additional registration have you read the link we gave you ? I did and I got the message, but isn't the concept of /proc/mounts or a mtab file already a centralized one? that doesn't mean the implementation has to be and no, i don't think it's centralized actually it's just a file you can build a file from many sources or if we do it your way recursing on fs translators *but* restricting this to root owned translators also suffering from centralization wrt to the root user? I mean the concept of all mounted filesystems does not apply cleanly to the hurd i don't understand restricting to the root user doesn't mean it's centralized trust has nothing to do with being centralized I guess I'm not used to thinking this way teythoon: i guess that's the main reason why so few developers work on the hurd also the way fs notification is done is also centralized, that could also be done recursively what doyou call fs notification ? and the information I need could just be stuffed into the same mechanism fs translators being notified of system shutdown right that gets a bit complicated because the kernel is also a centralized component it knows every memory object and their pagers it manages all virtual memory there are two different issues here syncing memory and shutting down file systems the latter could be done recursively, yes i wonder if the former could be delegated to external pagers as well teythoon: but that's not the focus of your work aiui, it would take much time sure, but missing an mtab file or better yet /proc/mounts could be an issue for me, at least a cosmetic one, if not a functional one i understand and hacking up a quick solution for that seemed like a good exercise i suggest you discuss it with your mentors they might agree to a temporary centralized solution although i don't think it's much simpler than the recursive one braunr: would that be implemented in libdiskfs and friends? teythoon: i'm not sure, it might be a generic fs operation libnetfs etc.. are also mount points so where would it go if it was generic? libfshelp perhaps translator startup is handled in start-translator-long.c, so in case a startup is successful, I'd add it to a list? i'd say so, yes would that cover all cases, passive and active translators? that's another question do we consider passive translators as mounted ? ah, that was not what i meant i know but it's related start b/c of accessing a passive one vs. starting an active one using settrans start_translator_xxx only spawn active translators it's the same ok the definition of a passive translator is that it starts the active translator on access yeah I can see how that wouldn't be hard to implement i think we want to include passive translators in the mount table so registration must happen before starting the active one so it's a) keeping a list of active translators and b) add an interface to query fs translators for this list and c) an interface to query mtab style information? keeping a list of all translators attached and yes well a is easy b is the real work c would be procfs using b oh? I thought recursing on the translators and querying info would be separate operations? why so ? the point is querying recursively :) and when i say recursively, it's only a logical view ok, yes, it can be implemented this way, so we construct the list while recursing on the translators i think it would be better to implement it the way looking up a node is done in a loop, using a stack? iteratively a translator would provide information about itself (if supported), and referrences to translators locally registered to it could you point me to the node lookup? ah, yes eg., you ask /, it tells you it's on /dev/hd0, read-write, with options, and send rights to /home, /proc, etc.. well rights, references it could be the path itself rights as in a port to the translators? i think the path would be better but i'm not sure it would also allow you to check the permissions of the node before querying path would be nicer in the presence of stacked translators and obviously you'd have the path right away, no need to provide it in the reply true braunr: if we want to list passive translators (and I agree, we should), it isn't sufficient to touch libfshelp, as setting a passive translator is not handled there, only the startup teythoon: doesn't mean you can't add something there that other libraries will use so yes, not sufficient ## IRC, freenode, #hurd, 2013-06-29 braunr: diskfs_S_fsys_set_options uses diskfs_node_iterate to recurse on active translators if do_children is given braunr: I wonder how fast that is in practice braunr: if it's fast enough, there might not even be a need for a new function in fsys.defs and no need to keep a list of translators for that reason braunr: if it's not fast enough, then diskfs_S_fsys_set_options could use the list to speed this up teythoon: on all nodes ? braunr: i believe so, yes, see libdiskfs/fsys-options.c teythoon: well, if it really is all node, you clearly don't want that ## IRC, freenode, #hurd, 2013-07-01 I've ment to ask, the shiny new fsys_get_translators interface, should it return the options for the queried translator or not? i don't think it should ok let's walk through why it shouldn't may I assume that the last argument returned by fsys_get_options is the "source"? how would you know these options ? the source ? I wouldn't actually yes, you wouldn't you'd have to ask the translators for that so the only thing you can do is point to them well, the device to include in the mtab file and the client asks i don't know fsys_get_options tbh well, both tmpfs and ext2fs print an appropriate value for "device" as last argument looks like a bad interface to me options should be options there should be a specific call for the device but if everyone agrees with the options order, you can do it that way for now i guess one that could be used to recreate the "mount" using either mount or settrans just comment it where appropriate I thought that'd be the point? ? % fsysopts tmp /hurd/tmpfs --writable --no-inherit-dir-group --no-sync 48K where is the device ? % settrans -ca tmp $(fsysopts tmp) 15:56 < teythoon> well, both tmpfs and ext2fs print an appropriate value for "device" as last argument 48K i don't see it really ? yes what about ext2fs ? hm ok i see % fsysopts / ext2fs --writable --no-inherit-dir-group --sync=10 --store-type=typed device:hd0s1 i don't think you should consider that as devices but really translator specific options agree I don't ;) b/c the translator calling convention is hardcoded in the mount utility ? I think it's reasonable to assume that this mapping can be reversed theorically you can write a translator that takes no arguments, but just options the 48K string for tmpfs is completely meaningless in fstab, it should be none "tmpfs" the linux equivalent is the size option no, none it's totally ignored and it's recommended to set none rather than the type to avoid confusion u sure? % settrans -cga tmp /hurd/tmpfs --mode=666 6M % settrans -cga tmp /hurd/tmpfs --mode=666 6M % fsysopts tmp /hurd/tmpfs --writable --no-inherit-dir-group --no-sync 6M i've not explained myself clearly it's not ignored by the translator but in fstab, it should be in the options field it's not the source clearly not ah now i'm talking about fstab, but iirc the format is similar in mtab/mounts close, but not the same yes, close ok, so I'll put a method into libfshelp so that translators can explicitly set a device and patch all existing translators to do so? teythoon: what i meant is that, for virtual vile systems (actually file systems with no underlying devices), the device field is normally ignored teythoon: why do you need that for exactly right do they even have a "device" field? (i can see why but i'd like more visibility) pinotree: not yet pinotree: that's what he wants to add but i'd like to see if there is another way to get the information 16:05 < braunr> teythoon: why do you need that for exactly well if I'm constructing a mtab entry I need a value for the device field do we actually need it to be valid ? not necessarily I guess discuss it with your mentors then it has to be valid for e2fsck checks etc. doesn't e2fsck check fstab actually ? i.e. actually for the cases where it's trivial fstab doesn't tell it whether it's mounted I mean fsck checking whether it's mounted not fsck -a oh couldn't we ask the device instead ? looks twisted too that'd mean patching a lot of applications which do similar checks yes teythoon: propose an interface for that with your mentors then yeah, but couldn't you lay it out a little, I mean would it be one procedure or like three? 16:04 < teythoon> ok, so I'll put a method into libfshelp so that translators can explicitly set a device and patch all existing translators to do so? ok why three ? no, I mean when adding stuff to fsys.defs i understood that but why three ? :) it'd be more generic really ? please show a quick example of what you have in mind i honestly don't know, thus I'm asking ;) well first, this device thing bothers me when you look at how we set up our ext2fs translators, you can see they use device:xxx and not /dev/xxx but ok, let's assume it's harmless ok, but isn't the first way actually better? i think it ends up being the same ideally, that's what we want to use as device path but you can recreate a storeio translator using the device:xxx info, the node is useless for that so that we don't need to explicitely set it ? what do you mean ? well, fsysopts / tells currently tells me device:hd0s1 for /, there isn't much choice /dev isn't there yet ah, got it that's why it differs... differs ? from what ? other ext2fs translators are set the same way by the debian installer for example % fsysopts /media/scratch /hurd/ext2fs --writable --no-inherit-dir-group /dev/hd1s1 here it uses the path to the node that's weird was that done by the debian installer ? ah no, that was me :p $ fsysopts /home /hurd/ext2fs --writable --no-inherit-dir-group --store-type=device hd0s6 so as you can see, it's not that simple to infer the device path oho, yet another way ;) right then isn't device:hd0s1 as shortcut for specifying the store type, as done with --store-type=device hd0s1? but perhaps we don't need to yes it is iirc it's something libstore does, per-store prefixes ah that sucks teythoon: you may need to normalize those strings so that they match what's in fstab i.e. unix /dev paths otherwise e2fsck still won't be able to find the translators mounting the device well, if it's mounted actually it just needs to find the matching line in mtab aiui so perhaps a libfshelp function for that, yes braunr: so you suggest adding a normalizing function to libfshelp that creates a /dev/path? yes used by the call you intend to add, which returns that device string as found in fstab found in fstab? so this would only work for translators managed by fstab? no ah a string like the ones found in fstab? yes so that fsck and friends are able to know whether a device is mounted or not i don't see any other purpose for that string in mtab you'd take regular paths as they are, convert device:xxx to /dev/xxx, and return "none" for the rest i suppose ok i'm not even sure it's right youpi: are you sure it's required ? well it's a start and I think it's not too much work aiui, e2fsck may simply find the mount point in fstab, and ask the translator if it's mounted we can refine this later on maybe? or rather, init scripts, using mountpoint, before starting e2fsck teythoon: sure there's this mountpoint issue... I need to run fsysopts / --update early in the boot process otherwise the device ids returned by stat(2)ing / are wrong and mountpoint misbehaves i guess b/c it's the rootfs device ids ? % stat / | grep Device Device: 3h/3d Inode: 2 Links: 22 do you mean the major/minor identifiers ? I do. if I don't do the --update i get seemingly random values i guess that's expected we don't have major/minor values well, they're emulated well, if that's fixable, that'd be really nice ;) we'll never have major/minor values yeah, I understand that but they could be fixed by MAKEDEV when creating device nodes but not having to call fsys_set_options on the rootfs to get the emulation up to speed try doing it from grub not sure it's possible but worth checking by means of an ext2fs flag? yes if there is one i don't know the --update flag, is it new from your work ? braunr: no, it's been there before. -oremount gets mapped to that it's documented by fsysopts, but not by the ext2fs translators libdiskfs source says something about flushing buffers iirc -s what does it do ? teythoon: ok braunr: so the plan is to automatically generate a device path from the translators argz vector but to provide the functionality so translators can set a more appropriate value? did I get the last part of the discussion right? not set, return yeah return from the procedure but settable using libfshelp? why settable ? you'd have a fsys call to obtain the dev string, and the server side would call libfshelp on the fly to obtain a normalized value and return it ah, make a function overrideable that returns an appropriate response? overrideable ? like netfs_append_args you wouldn't change the command line, no isn't that done using weak references or something? no I know sorry i'm lost then never mind, I'll propose a patch early to get your feedback braunr: am I sure that _what_ is required? the device? e2fsck surely needs it, yes a valid device path, yes it can't rely only on fstab yes since users may mount things by hand i've used strace on it and it does perform lookups there (although i also saw uuid magic that i guess wouldn't work yet on the hurd) ## IRC, freenode, #hurd, 2013-07-03 I added a procedure to fsys.defs, added a server stub to my tmpfs translator and wrote a simple client, but something hasn't picked up the new message yet % ./mtab tmp ./mtab: get_translator_info: (ipc/mig) bad request message ID I guess it's libhurduser.so from glibc, not sure though... glibc would only have the client calls what is "% ./mtab tmp" ? mtab is my mtab tool/soon to be a translator testing thing, tmp is an active tmpfs with the appropriate server stub so mtab has the client call, right ? yes then tmpfs doesn't so what to do about it? i set LD_LIBRARY_PATH to my hurd builds lib dir, is that preserved by settrans -a? not really not at all there is a wiki entry about that iirc http://darnassus.sceen.net/~hurd-web/hurd/debugging/translator/ yeah, I read it too once ah on the other hand, using export to set the environment should do the work yes, that did the trick, thanks :) * teythoon got his EOPNOPSUPP... *nomnomnom ? same error ? well I stubbed it out oh no, that's what I've been expecting ;) great :) yes that's better than "mig can't find it" braunr: in that list of active and passive translators that will have to be maintained, do you expect it should carry more information other than the relative path to that translator? like what ? dunno, maybe like a port to any active translator there should we care if any active translator dies and remove the entry if there's no passive translator that could restart it again? don't add anything until you see it's necessary or really useful yes think of something like sshfs when you kill it, it's not reported by mount any more well, for a dynamically allocated list of strings I could use the argz stuff, but if we'd ever add anything else, we'd need a linked list or something, maybe a hash table yes, I thought that'd be useful use libihash for no now braunr: but what would I use as keys? the relative path should be unique (unless translators are stacked... hmmm), but that's the value I'd like to store and ihash keys are pointers stacked translators are an kinda interesting case for mtab anyways... why not store the string address ? i suppose that, for stacked translators, the code querying information would only return the topmost translator since this is the one which matters for regular clients (if i'm right) wouldn't that map strings that are equal but stored at different locations to different values? that'd defeat the point I suppose so, yes then add a layer that looks for existing strings before adding the list should normally be small so a linear lookup is fine yeah sure, but then there's little advantage of using ihash in the first place, isn't it? over what ? over not using it at all how would you store the list then ? it's either ll or ll+ihash uh no let me check there is ihash_iterate so you don't need a linked list so how do I store my list of strings to deduplicate the keys? you store pointers and on addition, you iterate over all entries, making sure none matches the new one and if it does, you replace it i guess depending on how you design the rest in an dynamically allocated region of memory? i don't understand your strings should be dynmaically allocate, yes no the array of char * your data structure being managed by libihash, you don't care about allocation what array ? ah, got it... right. there is only one structure here, an ihash of char * yes, I got the picture ;) goo d actually, the lookup wouldn't be linear since usually, hash tables have stale entries heh... what forest?!? but that's ok teythoon: ? the one I couldn't make out b/c of all the trees... ? ah, it's not important. there is this saying over here, not sure if there's an english equivalent ok got it we have the same in french I ran into a problem with my prototype if an translator is set in e. g. diskfs_S_file_set_translator, how do I get the path to that node? I believe there cannot be a way to do that, b/c the mapping is not bijective it doesn't have to be ok, so how do I get *a* path for this node? that's another question do you see how the node is obtained ? np = cred->po->np; yes the translation occurred earlier you need to find where then perhaps, you'll need to carry the path along or if you're lucky, it will still be there somewhere the translation from path to node? yes doesn't that happen in the client? and the client hands a file_t to the file_set_translator routine? the relative lookup can't happen in the client the server can (and often does) retain information between two RPCs uh, I can access information from a previous rpc? is that considered safe? think of open() then read() a simple int doesn't carry enough information that's why it's a descriptor ah, the server retains some state, sure what it refers to is the state retained between several calls the object being invoked by clients teythoon: what is the "passive" parameter passed to diskfs_S_file_set_translator ? braunr: argz vector of the passive translator so it is a name but we also want active translators and what is active ? not the name of the node though active is the port (?) to the active translator I guess fsys_t, looks that way yes i suppose you could add the path to the peropen structure ok see diskfs_make_peropen braunr: but translation happens in dir_lookup in all places I've seen diskfs_make_peropen used, the path is not available why did you point me to diskfs_make_peropen? s/dir_lookup/diskfs_lookup/ diskfs_lookup operates on struct node, so the path would have to be stored there, right? teythoon: dir_lookup should call diskfs_make_peropen at least diskfs_S_dir_lookup does and the path is present there braunr: right hrm... I added a path field to struct peropen and initialize it properly in diskfs_make_peropen, but some bogus values keep creeping in :/ first of all, make it a dynamically allocated string it is not a fixed sized embedded array good yes if you really need help debugging what's happening, feel free to post your current changes somewhere there is a struct literal in fsys-getroot.c, but i fixed that as well % ./mtab tmp none tmp ../tmpfs/tmpfs writable,no-inherit-dir-group,no-sync 0 0 none tmp/bar ../tmpfs/tmpfs writable,no-inherit-dir-group,no-sync 0 0 none tmp/foo ../tmpfs/tmpfs writable,no-inherit-dir-group,no-sync 0 0 none tmp/foo/bar ../tmpfs/tmpfs writable,no-inherit-dir-group,no-sync 0 0 :) ## IRC, freenode, #hurd, 2013-07-10 btw, I read getcwd.c and got the idea however this situation is different afaict getcwd has a port to the current working directory, right? so they can do open_dir with .. as relative path but all I've got is a port referencing the node the translator is being attached to s/open_dir/dir_lookup/ and that is not necessarily a directory, so dir_lookup fails with not a directory as far as I can see it is not possible to get the directory a node is in from a port referencing that node dir_lookup has to be handled by all nodes, not just directories but file nodes only support "looking up" the empty string not empty, but null: This call is required to be supported by all files (even non-directories) if the filename is null, and should function in that case as a re-open of the file. */ why do you want the directory ? 10:40 < teythoon> as far as I can see it is not possible to get the directory a node is in from a port referencing that node to readdir(3) it and figure out the name of the node the translator is bound to similar to what getcwd does that's out of the question wasn't that was youpi was suggesting? you may have a lot of nodes in there, such a lookup shouldn't be done i didn't see that detail "│ Concerning storing the path, it's a bit sad to have to do that, and │ it'll become wrong if one moves the mount points. Another way would │ be to make the client figure it out by itself from a port to the mount │ point, much like glibc/sysdeps/mach/hurd/getcwd.c. It'll be slower, but │ should be safer. The RPC would thus return an array of ports to the │ mount points instead of an array of strings. yes i remember that but i didn't understand well how getcwd work s another scalability issue not a big one though, we rarely have translators in directories with thousands of nodes so why not teythoon: do it as youpi suggested well if you can eh if not, i don't know 10:47 < teythoon> │ it'll become wrong if one moves the mount points. Another way would yes, I know... :/ well, I'm not even sure it is possible to get the directory a node is in from the port referencing the node as in, I'm not sure if the information is even there b/c a filesystem is a tree, directories are nodes and files are leafs all non-leaf nodes reference their parent to allow traversing the tree starting from any directory but why would a leaf reference its parent(s - in case of hardlinks)? uh, for the same reason ? sure, it would be nice to do that, but I dont think this is possible on unixy systems ? you cannot say fchdir(2) to a fd that references a file do you mean /path/to/file/../ ? yes only that /path/to/file is given as fd or port when i pasted 10:49 < braunr> 10:47 < teythoon> │ it'll become wrong if one moves the mount points. Another way would i was actually wondering if it was true ah why can't the path be updated at the same time ? it's a relative path anyway completely managed by the parent translator ah right it's still kind of hacky, but I cannot see how to do this properly hacky ? but yes, updating the path should work I guess or sad what i find hacky is to set translators in two passes otherwise we'd only keep the translator paths not all paths true but then, it only concerns open nodes and again, there shouldn't be too many of them so actually it's ok braunr: I understand the struct nodes are cached in libdiskfs, so wouldn't it be easier to attach the path to that struct instead of struct peropen so that all peropen objects reference the same node object? so that the path can be updated if anyone dir_renames it *all peropen objects derived from the same file name that is teythoon: i'm not sure nodes could be real nodes (i.e. inodes) there can be several paths for the same inode braunr: I'm aware of that, but didn't we agree the other day that any path would do? i don't remember we did i don't know the details well, but i don't think setting a translator on a hard link should set the translator at the inode level on the other hand, if a new inode is created to replace the previous one (or stack over it), then storing the path there should be fine braunr: I don't think I can update the paths if they're stored in the peropen struct how would I get a reference to all those peropen objects? ? first, what's the context when you talkb about updating paths ? well, youpi was concerned about renaming a mount point and you implied that this could be managed can we actually do that btw ? what? renaming a mount point yep, just tried i mean, on a regular unix system like linux $ mv test blah mv: cannot move `test' to `blah': Device or resource busy (using sshfs so YMMV) do you have anything (shells, open files, etc) inside it? no i'll try with an empty loop-mounted ext4 I was testing on the Hurd, worked fine there even with a shell inside same thing i consider it a bug we may want to check what posix says about it o_O and decide not to support renaming why? start a discussion in ml, maybe roland can chime in it complicates things ah yes sure, but I can move or rename a directory, why should it be different with a mount point? because it's two of them they're stacked if we do want to support that, we must be very careful about atomically updating all the stack ok braunr: I'm trying to detect dying translators to remove them from the list of translators what port can I use for that purpose? if I use the bootstrap port, can I then use the same method as init/init.c uses? just defining a do_mach_notify_dead_name function and the multiplexer will call this? teythoon: possibly braunr: we'll see shortly... I get KERN_INVALID_CAPABILITY indicating that my bootstrap port is invalid when calling mach_port_request_notification to get the dead name notification I mean is the translator already started when you do that ? yes, at least I think so, I'm hooking into diskfs_S_file_set_translator and that gets an active translators port also the mach docs suggests that the notification port is invalid, not the name port referencing the translator i guess it shouldn't oh please show the code but beware, if the translator is started, assume it could die immediately braunr: http://paste.debian.net/15371/ line 87 teythoon: notify can't be bootstrap what do you have in mind when writing this ? i'm not sure i follow I want to be notified if an active translator goes away to remove it from the list of translators ok but then create a send-once right and wait on it also, why do you want to be notified ? isn't this already done ? or can't do it lazily on access attempt ? +you in the client? in the parent server what happens currently when a translator dies is the parent notified ? or does it give an invalid right ? ah, i think so then you don't need to do it again right, I overlooked that