On Wed, Feb 23, 2005 at 05:01:46 -0800, Gaurav Dhiman wrote: > > Hi Jan, > > Well can you put some light why this code is not good. > I know that using the top most level functions of any > system call in kernel (like sys_open, sys_close, any > function whcih starts with "sys_") will put alot of > extra overload and might not be the optimum way to do > things in kernel, but i think functionality wise it > will be same, as these function handle all the > senarios need to be handled. No, in this case it's not the same functionalitywise. The reason is, that sys_open returns a file descriptor. It is just a number, that is an index to an array of the actual file structures. This array is stored in current and is different for each progress. So by calling sys_open you create a filehandle visible to userland, but only of the process in the context of which it was called. But as each function of a kernel module might be called in different context (init_module is always called in context of the insmod, which exits short after init_modules is done -- and since files descriptors are closed when the process exits...), file descriptors are NOT what you want. What you want is file structure, which is the underlying actual descriptor. It is not directly visible and as a reference-counted object it will stay with you as long as you need it. Thus you really want to call the functions that operate on struct file. And for the operations on it, you usualy want to call the function pointers from it's ops member. > I think its the easiest and safest way but definitely > not the optimum way, so we shud not use such things in > production code, but they can be used for experimental > or learning codes. As explained above, it will NOT work in the filesystem case. On the other hand, the kernel_thread() function is implemented by calling sys_fork (or sys_clone, I don't remember exactly). On some architectures directly and on others even by actualy doing a syscall (yes, on i386 it actualy does int 0x80). But fork is a little special in this respect -- it uses the state saved by kernel entry. ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
