[[!meta copyright="Copyright © 2010, 2011, 2013, 2014, 2015 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_glibc open_issue_hurd]] [[!toc]] # [[glibc]]'s `fd_to_filename` # IRC, freenode, #hurd, June (?) 2010 is there a way (POSIX or Hurdish) to get the corresponding file name for a fd or a hurd port? there is a way marcusb: which one would that be? I forgot there is an implementation in libc realpath has a similar job but that's not what I mean pochu: maybe I am misremembering. But it was something where you keep looking up .. and list that directory, looking for the node with the ID of the node you had .. for maybe it works only for directories yeah pochu: check the getcwd() implementation of libc sysdeps/mach/hurd/getcwd.c _hurd_canonicalize_directory_name_internal  * pochu looks marcusb: interesting though that is for dirs, and doesn't seem to be extensible to files, as you cannot lookup for ".." under a file right oh you already said that :) actually, I am not sure that's correct it's probably correct, but there is no reason why looking .. up on a file couldn't return the directory it's contianed in I don't know the interfaces or the Hurd internals very well yet, but it would look strange to me if you could do that the hurd is strange it sounds like if you could `ls getcwd.c/..` to get sysdeps/mach/hurd/ :-) yep ok. interesting you wouldn't find "ls foo.zip/.." very strange, wouldn't you? I guess not if `ls foo.zip` listed the contents of foo.zip there you go or the other way round: would you be surprised if "cat somedir" would work? I think so. if it did, what would it do? originally, cat dir would list the directory content! in the old unix times I was surprised the first time I typed `vi somedir` by accident and some early BSDs * pochu feels young :-) he don't worry, I didn't see those times either technically, files and directories are implemented in the same way in the hurd, they both are objects implementing the fs.defs interface which combines file and directory operations of course, files and directories implement those functions differently marcusb: do you know why this behavior (cat on directories) was changed? ## IRC, freenode, #hurd, 2013-03-07 * pinotree ponders about sending as RFC his patch for /proc/$pid/maps Including a scheme for providing the names of mapped files? ;-D that would be really great indeed I have not yet researched how Linux does this. Perhaps store the filename used for first opening a file as a string somewhere? tschwinge: eh, indeed that's lacking in my patch i'm not sure we should aim at doing it the same way I was wondering about having interfaces for naming tasks, threads, objects that'd be useful for debugging in general yes i don't think we need to take namespaces into account a simple name or path should be quite enough Agreed. "Just something!" So, a Java toString() method for ports. ;-) yes Oh, and could this also work recursively? The ext2fs instance on /home asks its parent fs about its own path -- can it do that? (And then cache that, most likely?) Would one get rooted filesnames that way? i really don't think we should link it to the VFS it should merely be a name for debugging yep, same for me I'd say it's the linker's task of just setting a sane name first, keeping it isolated prevents increasing complexity next, it doesn't reduce performance youpi: Linker? braunr: Ack. yes, ld is the one creating the mappings tschwinge: the one that loads libraries Ah, for /proc/*/maps, right. I've been thinking more globally. ## task_get_name, task_set_name RPCs The following needs to be updated now that [[microkernel/mach/gnumach/interface/task_set_name]] has been implemented. [[!message-id "518AA5B0.6030409@verizon.net"]] ## IRC, freenode, #hurd, 2013-05-10 tschwinge's suggestion to put names on ports instead of tasks would be useful too do you get task ports as easily as you get tasks in kdb ? there is task->itk_self & such or itk_space I don't remember which one is used by userspace i mean when you use the debugger, can you easily find its ports ? the task ports i mean or thread ports or whatever once you have a task, it's a matter of getting the itk_self port s/port/field member/ so the debugger provides you with the addresses of the structs right ? yes, that's what we have already then ok bddebian: do that :p hehe see show all thread (haven't used kdb in a long time) So, adding a name to ports like I did with tasks? remove what you did for tasks move it to ports it's very similar but hm i'm not sure where the RPC would be this RPC would exist for *all* ports or only for kernel objects if added to gnumach.defs it's just about moving the char array field to another structure and plugging that But mach_task_self is a syscal, it looks like itk_self is just a pointer to an ipc_port ? so ? you take that pointer and you get the port just like vm_map gets a struct vm_map from a task So I am just adding ipc_port_name to the ipc_port struct in this case? yes actually don't do anything just yet we need to sort a few details out first see bug-hurd ## IRC, freenode, #hurd, 2013-12-05 braunr: no more room for vm_map_find_entry in 80220a40 80220a40 <- is that a task ? or a vm_map, not sure probably a vm_map hm let's fix this kind of reporting :) let one process register for kernel log messages make a rich interface, say klog_thread and friends a userspace process gets the port name, looks it up in proc, logs nicely to syslog if noone registered for this notifications, fall back to the old reporting i tend to think using internal names is probably better how would i use them to see wich process caused the issue ? you give the name of the task (which means tasks have names, yes) ok the reason is that reporting is often used for debugging and debugging usually means there is a bug if the bug prevents from reporting, it's not very useful and we're talking about the kernel here, the low level stuff incidentally, i got myself a stuck process ah, got it killed braunr: so you propose to add a task rpc to set a name ? i don't want to push such things which is why this hasn't been done until now but that's what i'd do in x15, yes y not ? and instead of a process registered to gather kernel messages, i'd use a dmesg-like interface, where the kernel manages its message buffer itself i didn't feel the need to the tools i've had until now were sufficient don't forget you still need to fix mtab :p or is it done ? i sometimes see tasks deallocating invalid ports no there is an un-acked patche series on the list ok so, i want to identify which process caused it is that possible right now ? not easily, no so that's a valid use case it is good :) so proc would register a string describing each task and mach would use this for printing nicer messages ? for example, yes one problem with that approach is that it doesn't fit well with subhurds *bingbingbing but i personally wouldn't care much, they're kernel messages in the future, we could make mach more a hypervisor, and register names for each domains yet unanswered proposal about hierachical proc servers on the list... that'd also fix subhurds, so that the parents processes won't appear in the subhurd making it sandboxier and killall5 couldn't slaughter the host system if the subhurd shuts down with sysvinit ## IRC, freenode, #hurd, 2014-01-20 i wonder if it would not be best to add a description to mach tasks i think it would to aid fixing these kind of issues in x15, i actually add descriptions (names) to all kernel objects that's probably a good idea, yes well, not all, but many ## IRC, OFTC, #debian-hurd, 2014-02-05 youpi: about that patch implementing task_set_name, may i merge the amended version ? yes # IRC, freenode, #hurd, 2011-07-13 A related issue: rbraun@nordrassil:~$ vminfo $$ | wc -l 1039 any idea why a shell would consume more than 1039 map entries ? (well, not more actually) even the kernel and ext2fs have around 100 (the kernel has actually only 23, which is very good and expected) braunr: I agree that having some sort of debugging information for memory objects et al. would be quite hand. To see where they're coming from, etc. tschwinge: this would require naming objects at the mach level e.g. when creating an object giving it the path of a file for example braunr: I have recently seen something (due to youpi fixing a bug) that bash is doing its own memory management. Perhaps all these are such regions? braunr: For example, yes. what ? ?! braunr: http://lists.gnu.org/archive/html/bug-bash/2011-04/msg00097.html i see Also see email thread starting at [[!message-id "20110714082216.GA8335@sceen.net"]]. Justus: Once [[!message-id desc="these patches" "1375178364-19917-4-git-send-email-4winter@informatik.uni-hamburg.de"]] are merged, there will be a way to map from ports to file names, at least for libdiskfs and libnetfs, one would only have to make this information available somehow.