SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
02-18-2008, 09:34 AM
| ||||
| ||||
 Re: Adding another facility to ktrace - for syscall arguments >> It's somewhat bothersome that ktrace doesn't dump the actual values for the >> structures that were passed in as the arguments to a syscall. All you see >are >> addresses, and may be you can see some translated to names, but that's >about >> it. It would be nice if one can see inside the actual structures, >> which would be >> operation specific. >> >> Would it be reasonable to add another facility, define the structures for >> ktr_header.ktr_buf, to be able to accommodate arbitrary structures and the >> definitions of such, and then start instrumenting the syscalls, >> where feasible, >> to dump their arguments into trace stream ? >> >> So, why is this a stupid idea ? > >I wouldn't say it's a stupid idea. > >However, this will require a lot of work in ktrsyscall() in the kernel, >to know which arguments are pointers to structs, and need to have their >contents fetched and put in the (extended) ktr_syscall structure. > >You'll also need a way to report copyin() failures, for each struct. > >Apart from that, feel free to do this. Scratch your itch, and if you >come up with a diff which does not turn ktrace into something >unmaintainable, why not. ioctl and setsockopt and such in particular will make this difficult.      |
Linear Mode
