Garrett D'Amore writes: > In the OSS code, there are literally dozens of ioctls spread around. > Rather than creating custom copy-in/copy-out code for each command, I > have common a small bit of common code which looks at the encoded size > and direction and handles the copying. The savings is probably hundreds > of lines of code. It makes for a much smaller/simpler architecture. > (Admittedly it only works for OSS because the structures themselves do > not contain any pointers, so a single copyin/copyout is sufficient.) It > is especially important that I'm able to do this in the common framework > because of the complexities of M_COPYIN/M_COPYOUT handling in STREAMs code.
That's fine; you can define your own personal macros for these things. > Its not the first time that this problem has annoyed me either. In the > past (~a decade ago), I've personally made design decisions to avoid > large structures in ioctl arguments, if I was going to use these macros, > or avoided the macros altogether, because of the encoding limitations. There's no real limit here. It's only the ioctl number that's at issue; the actual copy in/out is done by the kernel module that receives the ioctl, and it can copy *any* amount of data it wants. > > That's not true. I pointed out earlier that you can add your own > > decoder into truss, and do anything you like with ioctl arguments. > > Just add a new case to show_ioctl(), and use Pread to grab the data > > you want. > > > Yes, I could write custom handlers for each of the ioctls. I have > dozens of the them to deal with. And that's just in this one > subsystem. Its not a clean approach. The common code should be able to > handle it. The only thing busted is the stupid too-small mask from > ancient 4.x legacy. Of course, that doesn't really do anyone much good, even if that "stupid" mask is fixed. The best truss can do (if it doesn't have ioctl-specific code) is to spew out the buffers in hex. Wading through that is an ugly job. I'd either add the handlers to truss (if I cared to do so, and if I thought there'd be actual users who'd also care), or ignore it and rely on dtrace (where I can use structures) instead. > As I said, I won't even bother with this if I can't do this in some > common fom. Special casing ioctls that should be able to be handled by > common code is just plain wrong, IMO. It's how truss has worked since ... well ... forever. For the cases where the ioctls matter enough to dump the buffers in some readable format, add a handler. If the ioctls are just some internal goop that's of interest to one or a very limited number of projects, then don't bother. There's certainly a judgement call to be made here, but I can't seem to end up in the case where I want truss to dump out large buffers and I'd prefer to count the bytes while looking at the structure in the header file to figure out what's going on. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
