Problems about device drivers handling

[Jeko]

I have some problems about device drivers handling. I use the structure of unix and linux device drivers (functions are open, close, read, write, ioctl). But with this method how can I handle the drivers that wants more than only one parameter?

For example, video drivers must have the function for drawing a line:

Code: Select all

int DrawLine(int x1, int y1, int x2, int y2, int color);

that needs at least 5 parameters. With ioctl I can pass only one parameter. How can I do?
I've the same problem for other drivers, such as PCI driver.

[~]

What about passing them the same number of parameters, and let each driver to utilize only those that it knows it needs?

Or, since each driver is different, why not simply have each API call pass the correct number of parameters? Isn't it done like that anyway?

[Jeko]

What about passing them the same number of parameters, and let each driver to utilize only those that it knows it needs?

Or, since each driver is different, why not simply have each API call pass the correct number of parameters? Isn't it done like that anyway?

I don't understand. I'm using unix interface for device drivers with only open, write, read, close, ioctl. What are you saying?

[frank]

You could pass a pointer to a struct as that one parameter.

[Jeko]

You could pass a pointer to a struct as that one parameter.

Is this a good method?
I thinked I can pass the struct with write.

[frank]

You could pass a pointer to a struct as that one parameter.

Is this a good method?
I thinked I can pass the struct with write.

For most of the device drivers that only require one parameter you could just pass it as normal. For device drivers that require more than one parameter you could put all of the information in a structure and pass a pointer to the structure, casting it to whatever the type of that one parameter is. All of your existing device drivers would still work and only the device drivers that thought that they were getting a pointer to a struct would treat it as such.

[mystran]

that needs at least 5 parameters. With ioctl I can pass only one parameter. How can I do?

Easiest thing is to pass a single parameter, which is the combination of the 5 parameters:

Code: Select all

struct drawline_paremeters {
   int x1,y1,x2,y2,color;
};

 ...
   struct drawline_paramaeters dp = { 1, 1, 10, 10, red};
   ioctl(graphics_fd, __ioctl_graphics_drawline, &dp);

In other words, pass a pointer to a struct containing the parameters.

That said:

Code: Select all

NAME
       ioctl - control device

SYNOPSIS
       #include <sys/ioctl.h>

       int ioctl(int d, int request, ...);

DESCRIPTION
       The ioctl function manipulates the underlying device parameters of special
       files.  In particular, many operating characteristics of character special
       files  (e.g.  terminals) may be controlled with ioctl requests.  The argu-
       ment d must be an open file descriptor.

       The second argument is a device-dependent request code.  The  third  argu-
       ment is an untyped pointer to memory.  It's traditionally char *argp (from
       the days before void * was valid C), and will be so named for this discus-
       sion.

       An ioctl request has encoded in it whether the argument is an in parameter
       or out parameter, and the size of the argument argp in bytes.  Macros  and
       defines  used  in  specifying  an  ioctl  request  are located in the file
       <sys/ioctl.h>.

So you can just have it take variable number of arguments kinda like printf, if you want. Passing a struct is potentially a bit cleaner though.

[Candy]

So you can just have it take variable number of arguments kinda like printf, if you want. Passing a struct is potentially a bit cleaner though.

What's the point of "clean" in the presence of ioctl?

[mystran]

So you can just have it take variable number of arguments kinda like printf, if you want. Passing a struct is potentially a bit cleaner though.

What's the point of "clean" in the presence of ioctl?

....

Indeed, that's pretty good summary: ioctl is a kludge to begin with.

[Kevin McGuire]

that needs at least 5 parameters. With ioctl I can pass only one parameter. How can I do?
I've the same problem for other drivers, such as PCI driver.

Why would you want to force many devices that have completely different functionality to use a interface that would not be efficient for them to use? You might just want to widen the conceptual scope and break it into logical 'functionality blocks'.

I have some problems about device drivers handling. I use the structure of unix and linux device drivers (functions are open, close, read, write, ioctl). But with this method how can I handle the drivers that wants more than only one parameter?

The Linux kernel does not subject all it's drivers to using one interface with five methods such as: open, close, read, write, ioctl.

Here is a interface that is specific to the PCI subsystem.

Code: Select all

static struct pci_driver xl_3c359_driver = {
	.name		= "3c359",
	.id_table	= xl_pci_tbl,
	.probe		= xl_probe,
	.remove		= __devexit_p(xl_remove_one),
};

There are many other interfaces in the Linux kernel. I call them interfaces, but they may very well be called something else but I still think they operate in the same manner.

In my own opinion I do not feel a driver should even worry about being opened or closed. It should do nothing more than get that device into the appropriate states and export the functionality of that device..and nothing else. If you want more then break it away from the driver, and place it in front of the driver and really drivers if you have multiple ones. It helps remove the bulk and make things smaller and more compact which can fit into cache easier. This could also be known as removing redundancy. I always like keeping redundancy in mind since it is a important factor in all aspects of life.

[mystran]

Actually, depending on the device, it might or might not want to worry about opening/closing...

Say, an audio driver might want to know about every open() and close() so it can allocate/deallocate buffers. This might not make any sense for SoundBlaster ofcourse since you're forced to mix in software when the card only provide a single output. But with a more advanced card with hardware mixing, you might just as well take advantage of that.

But I agree with the point that the interface a program uses on a file descriptor need not be the same interface you actually talk to the devices. It makes more sense for a block device to provide blocks, and then some higher level code to figure out how to deal with read/write/lseek.

ioctl() then is a hack to talk to device drivers directly from userspace, without all higher layers on top of the device driver needing to care about some special case stuff that only applies to this device and your grandmother's dog, so that you don't need to make a million and one special case system calls.

Personally, I'd actually separate graphics drivers into two parts: a small piece of kernel code that implements a totally driver specific ioctl()-interface and mmap(), and then the actual graphics driver which can run as a normal process, and provides some standard interface for you GUI to use. This is (more or less) how X11 works with modern graphics cards. Programs can then communicate with the GUI just like they'd communicate with any other server: sending messages through pipes/sockets/whatever. This is a good design. The reason X11 is slow crap has to do with the braindead protocol.

[hakware]

For ioctls, you could use varargs (I'm assuming you're doing this in c). Though varargs might involve a bit of extra coding on the library function side (like it does in d), it'd probably be worth it in the long run

[os64dev]

for a gui i would do the struct thingy and use as a format the opengl structures. If at one point you'll be able to do opengl then you can transfer the structure directly to the hardware card. i think