Date: Tue, 15 Jul 2008 08:14:28 -0500 From: Stacey Son <sson@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, freebsd-arch@freebsd.org Subject: Re: ksyms pseudo driver Message-ID: <487CA2B4.7070604@freebsd.org> In-Reply-To: <20080715093402.GO17123@deviant.kiev.zoral.com.ua> References: <4875A5D2.8030902@freebsd.org> <20080711155232.A96384@grasshopper.cs.duke.edu> <48780661.5050002@freebsd.org> <20080712045837.GD17123@deviant.kiev.zoral.com.ua> <487AD49F.6040304@freebsd.org> <20080715093402.GO17123@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Kostik Belousov wrote: >> The snapshot of the consolidated symbol table is made when /dev/ksyms is >> opened. The storage for the snapshot is allocated in the memory map of >> the calling process. No kernel address space is used for the snapshot. >> > Again, why this is done this way ? Why not creating snapshot when the > user process issues ioctl that supplies neccessary usermode memory > to the driver ? > The main reason it is written as a pseudo driver is so it can be used with standard command-line utilities. For example, see the ksyms example in the dtrace manual (http://wikis.sun.com/display/DTrace/Structs+and+Unions). I guess it could still be possible to do in the way you are suggesting but it would require a special 'cat', or something, to allocate the user space buffer and then pass that in driver before it starts reading the symbol table. You could then pipe the output of the "special ksyms cat" to the actual command-line program you wanted to use. Of course, if you had to use a "special ksyms cat" then there would be no reason to make this a pseudo driver. You could simply make it a system call and eliminate a lot of code and calls into the kernel. >> BTW, you may have noticed the ksyms driver now uses your per-open file >> private data code which I like much better than using clone_create() for >> per-descriptor storage. >> > Does it work ? Do you have any suggestions for the KPI ? > Yes, it seems to work much better than the previous method (clone_create) but more testing is needed. I was having problems with the clone_create() method when I was running some testing code that would rapidly open /dev/ksyms. open() would fail. I am guessing there may be a race condition between when the device is cloned and actually open'ed. I'll let you know if I have some suggestions for the KPI. -stacey.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?487CA2B4.7070604>