Date: Tue, 15 Jul 2008 16:18:01 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Stacey Son <sson@freebsd.org> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, freebsd-arch@freebsd.org Subject: Re: ksyms pseudo driver Message-ID: <20080715131801.GS17123@deviant.kiev.zoral.com.ua> In-Reply-To: <487CA2B4.7070604@freebsd.org> 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> <487CA2B4.7070604@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Tue, Jul 15, 2008 at 08:14:28AM -0500, Stacey Son wrote: > 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. Would dd bs=<some large value> work as the "special cat" ? procfs' /proc/pid/map has the similar problem, and there was a procmap program in ports. I believe dd is enough. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkh8o4gACgkQC3+MBN1Mb4gk6wCgudTjZWHagF5Xyr8kkJhDno0l iKAAoLZCuZpw2ZNArz/qAyNzHZeh6Ryg =10Cr -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080715131801.GS17123>