On Thu, Apr 08, 2004 at 03:01:09 -0400, Guillaume Thouvenin wrote:
> Selon Guillaume Thouvenin <guillaume.thouvenin@polymtl.ca>:
>
> > > ---- NEW HEADER FILE ----
> > > #ifndef __LINUX_ELSA_H
> > > #define __LINUX_ELSA_H
> > >
> > > struct bank_root_s;
> > > enum elsa_opcode {BANK_INIT,BANK_ALLOC,BANK_FREE,BANK_ADD,BANK_REMOVE};
> > >
> > > /*
> > > * sys_elsa() interface.
> > > *
> > > * int sys_elsa(int opcode, unsigned int arg0,
> > > * unsigned int arg1, unsigned int arg2)
> > > */
> > >
> > > #ifdef __KERNEL__
> > >
> > > Now, I can compile the test program. Therefore, my question is :
> > > Is it a correct solution
> >
> > There is a problem with this solution because the can declare the structure
> > bank_root_s in the user program but the compiler will not know the size of
> > the structure as the type is incomplete....
>
> In fact, I think the problem is that a user MUST NOT interact directly with
CANNOT
> kernel structure. So, struct bank_root_s shouldn't be visible from userland.
needn't
Kernel memory is not readable by user-space. You can give userland
pointers to it -- but only as magic cookies that will be passed back --
userland can't access them and thus does not need to know the size.
I would probably not add a syscall (which must be linked in kernel), but
use some generic interface on (device or proc) filehandles (ioctl, read,
write). It is a little more work, but can be done in module and is
generaly less invasive.
In any case, you can have kernel follow user-space pointers (quite
common with ioctls), though only until the syscall returns (you
shouldn't rely on user-space not freeing the memory then) and you can't
have user-space inspect kernel pointers. So you will need different
semantics for the user-space and kernel parts. And will need to do
pointer resolution in the syscall.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb@ucw.cz>
Attachment:
signature.asc
Description: Digital signature
