Date: Mon, 26 Mar 2012 11:10:54 -0400 From: John Baldwin <jhb@freebsd.org> To: arch@freebsd.org Subject: [PATCH] Teach procstat/fstat about details of a shm_open() object Message-ID: <201203261110.54527.jhb@freebsd.org>
next in thread | raw e-mail | index | archive | help
This patch changes the kernel to export a few details (mode, size, and path) of an object created via shm_open() to userland via the kinfo_file structure. It then updates fstat and procstat to parse these details. A few questions I had: 1) Rather than creating a new sub-structure in kinfo_file for shm objects, I just populate two of the fields in the existing kf_file. 2) For the non-path details I just ran fo_stat() on the shm and used the returned buffer. In hindsight, it seems it might have been nice to make kinfo_file just include a 'struct stat' and use fo_stat() to populate it for each fd. Would have reduced the need for some of the current type-specific logic I think. 3) I think we should probably change procstat to always try to print the path if it is set (so make the current VNODE|SHM, etc. case the "default" case). 4) I made fstat print out the pathname of the shm in the "MOUNT" field. Not sure how to document this sanely in the fstat manpage though. 5) I make anonymous objects created with SHM_ANON report a path of "SHM_ANON". They could just as easily report a path of "-" like an unlinked shm, I just made this different so I could tell them apart. However, perhaps that is too weird and they should report an empty path instead (like an unlinked shm or unlinked file). http://www.FreeBSD.org/~jhb/patches/shm_info.patch I did not bother doing this for in-kernel POSIX semaphores since they are deprecated. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203261110.54527.jhb>