aplication user and kernel mode (data access)



hi all,

i am trying to setup a program to use a device driver and am confusing buffer access between user and kernel mode. i think all applications running in user space have to communicate with the device drivers using io control calls and then have some functions called back from the driver app.


in this model, i guess the user app passes buffer pointer values to the driver
using the ioctl calls. is that what happens? for example, i have a session
context struct created by the user app using malloc. would that data have to
be copied to the driver for it to be used, or could i just pass a pointer to
the struct?

is using ioctl calls the only way to 'switch to kernel mode'??
also, am i right in saying the process running on the device driver is
separate from the one running in the application? how does that work in
relation to a threaded application? must a new thread be created with each
function call back?

you can probably tell i am very confused here, so any help is greatly
apreciated!

regards,

consider the line:
/usr/bin/echo "hello world" > /dev/tty

the shell will open /dev/tty and invoke /usr/bin/echo which will basicly simply execute a write() system call of fd 0. /dev/tty is a special file, so by opening it, we are communicating with the tty driver. yes, we can then do ioctl() calls and quite a few of them exist for tty's. most mostly we communicate with driver via the read() and write() system calls. most character drivers have read, write, and ioctl entry points. most versions of unix will have something like an init entry point that gets invokes during boot. but user code will communicate with character driver via read, write, and ioctl. there is only one process involved and it is the user process.

i over-simplify a bit here and my biggest lie is claiming that read and write still exist. most kernels scatter-gather i/o with systems calls like readv() and writev(). the old read and write is reduced to a special case and most drivers simply have readv and writev entry points which are invoked for read() and write().

not all drivers have all entry points and you can generally write a screwball driver with only an ioctl entry point. this is an underhanded way to add a pseudo system call to a version of unix to which you have no source code license. i have not seen this done in quite a while though. (these days people add screwball filesystems as an underhanded way to pseudo system calls.  )