03:21:02 [illumos-gate] 16649 SATL support for REPORT SUPPORTED OPERATION CODES -- Jason King 18:02:35 Other than open are there any syscalls that return a file descriptor? 18:04:14 I see open, open64 and openat 18:07:01 also socket, pipe, dup2, dup3, and the equivalent fcntl() calls 18:07:51 oh, and dup() 18:11:29 thanks, I was getting to dup and pipe, might have missed fcntl 18:14:02 on Solaris & illumos, the dup*() functions in libc actually call the fcntl system call, they don't have their own entry points to the kernel 18:14:19 https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libc/port/gen/dup.c 18:21:38 door_create()? 18:31:35 paulf: there are a number of ways to pass file descriptors over ipc. AF_UNIX lets you pass SCM_RIGHTS ancillary data (see socket.h(3HEAD)) 18:32:01 door_call() can pass descriptors as well. 18:32:38 (and close them in the sending process, too!) 18:39:29 (door_call can both send and receive descriptors; the server callback when a door is invoked can receive a descriptor, and door_return can send one and possibly close it) 18:40:30 I just want syscalls that return new file descriptors, at the syscall level 18:52:03 then yes, door_create 19:14:55 paulf: new in what sense? new to this process or new to the system? 19:15:21 sommerfeld: if I recall, paulf works on valgrind so probably new to the process 19:15:32 sommerfeld new to the process 19:15:38 and questions grittier than usual userland software 19:15:44 in that case you need to be aware of the descriptor-passing syscalls 19:16:05 because they can cause a descriptor to materialize in the process from outside. 19:16:46 richlowe yes this is for Valgrind, a new feature that checks that closed fds aren't being used inadvertently via a close then an open 19:18:22 oh, I forgot socketpair() in the list too 19:20:01 This feature is only a couple of days old, I don't think that we cover pipe and socketpair yet 19:32:56 thanks for the input, need to do the same for FreeBSD now 19:56:22 @paulf I don't know your background but remember the spectrum of OS interface boundaries, and whether or not they need distros: 19:56:23 https://hostux.social/@danmcd/111126696879472728 19:56:56 The illumos (and Solaris) interface boundary for programs is libc & friends, NOT the kernel syscall boundary. 19:57:27 valgrind is special, and knows the problems 19:57:29 I don't know FreeBSD's official stance per se. 19:57:51 danmcd we need to intercept all syscalls 19:58:12 as far as I know the FreeBSD interface is stable 19:58:12 Very good! 19:58:25 right, I'd class valgrind with truss & dtrace in needing to know the underlying implementation, not just the stable API for programs to call 19:59:19 Okay, I'm clearly missing the problem, and I take it you're from-or-working-with valgrind paulf -- sorry for muddying waters. 19:59:40 no worry 20:00:31 Valgrind 3.25 should be out soon, Illumos support should be a lot better 20:01:31 I haven't done as much for Solaris,I tried last week and there are some issues with reading ELF .data sections 20:02:09 I have one issue with Helgrind I wantr to fix, not sure that I'll have time before 3.25 is out 20:03:16 WOW! THANK YOU VERY MUCH! 20:08:04 time for bed 20:09:58 @andyf silly question: "go away" is an acceptable answer, and I expect it to be "not really, Dan" 20:10:15 The new MDB enhancements for $C/::stack ==> would those be easily usable by pstack(1) ? 20:11:35 oh that does remind me, andyf: You were going to email me diffs I think? 20:11:38 Not quite yet, but we talked about it. 20:11:40 I think at least the noreturn function handling should also be added to pstack, and at the same time the new heuristic functions for that should be moved somewhere common so they can be used in libproc as well as kmdb. 20:11:55 I haven't put much thought into adding the types to pstack output yet. 20:12:43 richlowe - ah yes, I'll email you what I have for the aarch64 heuristic function. 20:13:34 which is https://paste.omnios.org/?74bdec407461fc7e#7DXJqrrfabU3trGLF99y3CXLf62u4onYsenbB5bVFjmW but I'll drop it in an email 20:16:08 thanks