On 31/07/07, Ravid Baruch Naali <[EMAIL PROTECTED]> wrote: > > It's a POSIX matter when you open a file (being a block device or any > other) you get a file descriptor which is an index to an array which holds > pointers which in turns point to a vnode in the kernel, which among other > things point to the sys call specific implementation. > ioctl is one such sys call which operate according to it's parameters, one > of them is the ioctl number. > when you customize or develope your own device you can add to the function > ioctl any functionality you desire. > > Sorry if all that I wrote so far is obvious, but continuing from here, if > you follow Gilad's suggestion, you may build your module (load it when > required) and use it as a back door to the kernel, one of the parameters you > want to give it is the file descriptor you wish to inquire about. > wrapping it all in shared object which you will load with your application > or an executable which can be executed from the shell, you can make it look > like a sys call. >
I'm not sure what you are trying to get at - I know what's ioctl. The point is that the first parameter to the call will have to be the file descriptor of the device in order to trigger my new version of ioctl, but I want the call to operate on a completely different file descriptor (one which by definition isn't open to this special device), that's why I think I'll have to pass it some other way, maybe as a field in a struct pointed to by the third parameter to ioctl. Cheers, --Amos
