ksyms pseudo driver

[Stacey Son]

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.