Hi folks,
what do you think of ioctls, which are assembled not at compiletime but at
runtime in the form
ioctl(fd, req(read, size, 'g', msgtype ), &arg);
ioctl(fd, req(write, size, 'g', msgtype ), &arg);
ioctl(fd, req(rw, size, 'g', msgtype ), &arg);
The ioctl manpage defines it so:
int ioctl(int d, int request, ...)
I would like some comments on a request I am faced with while writing a device
driver. Because the FW of a card is still in development and the folks in that
department seem to be looking at kernel programming as supernatural, they want
me to write a driver with generic ioctls:
A set of ioctls shall put and get messages into/from a number of anonymous
buffers in the card which have descriptors/headers. Let's assume they have 32
buffers in each direction and use about 20 out of 100 different message types
over the time. A buffer will be 'bound' to 1 message type at boot time by the
cards firmware and there shall be ioctls that
1. put a message of type X into the matching buffer or complain
if no buffer was bound to Type X
2. get a message of type Y from the matching buffer or complain
if no buffer was bound to Type Y
Are there any reasons why this should not work, or be dangerous? The concept
makes it impossible to define the ioctls completely at compile time as I see it.
But I can't see a reason why the concept should not at all work so far. Are
there limitations on the bits in the ioctl's request argument, which I must not
touch at runtime? As I see it, I could e.g. make the lower 7 or 8 bits of
'request' variable and transport the type into the kernel. The size of the arg
data is up to 256 bytes as far as I can see. So that part can also be variable.
In the driver I will have to do some masking and parsing, but nothing really
complicating as it seems.
Are there any reasons, which speek against this concept?
The effect that shall be accomplished with the concept is that the guys want to
be free to define new message types in the FW of the card and write an
application that puts and gets the type without modifying the driver. They are
too frightend to modify or even compile a driver theirselves and don't want to
have to ask (pay) me to do it... Hmmm...
There will additionally be some 'normal' ioctls which are defined at compile
time and 2 read and 2 write interfaces per card for mass data.
Please CC me in replys, because my subscription to this list is currently still
in (human) process:
> has been forwarded to the owner of the "linux-kernel" list for approval
(I want my MailList-alias [email protected] to be subscribed)
Thanks,
--
Bernd Harries
[email protected] http://www.freeyellow.com/members/bharries
[email protected] Tel. +49 421 809 7343 priv. | MSB First!
[email protected] +49 421 457 3966 offi. | Linux-m68k
[email protected] 8.48'21" E 52.48'52" N | Medusa T40
Hi kernel hackers,
Is there a limit to the stack size (automatic variables) in driver methods, esp.
ioctl?
I was just implementing some generic ioctls where the size field and cmd field
are defined at runtime. For testing I use a kernbuf on the stack.
The driver's ioctl interface, which is normally a big case construction, looks
like this, the default case is another switch:
xyz_ioctl(..., ..., unsigned int request, unsigned long arg)
{
----some smaller declarations----
switch(request)
{
...
case IOR_GET_FIX:
{
fix_par_t fix_par; /* small struct */
----some code----
if(copy_to_user( , , sizeof(fix_par))) return(-EFAULT);
break;
}
...
default:
{
switch(request & 0xF000FF00)
{
case IOW_000_G_00:
{
UINT32 kernbuf[0x0400]; /* is this too much??? */
if(copy_from_user( , , dyn_size)) return(-EFAULT);
----some code----
break;
}
case IOR_000_G_00:
{
UINT32 kernbuf[0x0400]; /* how much is allowed??? */
----some code----
if(copy_to_user( , , dyn_size)) return(-EFAULT);
break;
}
}
/*endswitch(request & 0xF000FF00)*/
}
/*endcase default:*/
}
/*endswitch(request)*/
}
/*endproc()*/
Having this and testing not yet the generic ioctls, but the older, once working
'primitive' ioctls, I experienced that suddenly copy_to_user would not work any
more and return the complete length as remainder. The whole system seemed to
behave strange the more often I started the testprogram. Compiling the driver
module again would show strange error messages.
Observe, that the case-Block with the additional kernbuf was not even entered,
because the IOR_GET_FIX: returned an error "Bad address" or so.
Today I reduced the kernbuf to 4 * UINT32 and it seems to work. I will next try
to use a static kernbuf of 0x400 * UINT32...
In the Linux Device Drivers book I didn't find 'stack size' or similar in the
index. Are there any limits on the stacksize? If yes, how large are they and why
would the driver behave so stange and not oops or hang? I fear, my filesystem on
the test Box could be damaged. I saw this bad addres error quite some times and
suddenly make modules complained about strange contents in .config...
Does gcc grow the stack only at the beginning of a function, or can it save the
space and re-grow it on entering code_blocks also?
Thanks for any hints,
--
Bernd Harries
[email protected] http://www.freeyellow.com/members/bharries
[email protected] Tel. +49 421 809 7343 priv. | MSB First!
[email protected] +49 421 457 3966 offi. | Linux-m68k
[email protected] 8.48'21" E 52.48'52" N | Medusa T40
On Sun, Nov 05, 2000 at 01:08:40PM +0100, Bernd Harries wrote:
> Is there a limit to the stack size (automatic variables) in
> driver methods, esp. ioctl?
Yes, there is. It's INIT_TASK_SIZE. See include/linux/sched.h for
this.
> I was just implementing some generic ioctls where the size field and cmd field
> are defined at runtime. For testing I use a kernbuf on the stack.
kmalloc() and kfree() it instead.
> In the Linux Device Drivers book I didn't find 'stack size' or
> similar in the index. Are there any limits on the stacksize? If
> yes, how large are they and why would the driver behave so
> stange and not oops or hang? I fear, my filesystem on the test
> Box could be damaged. I saw this bad addres error quite some
> times and suddenly make modules complained about strange
> contents in .config...
Because it's an overall kernel limit. Once you are in kernel
mode, you have less than the above amount of stack. So don't use
it for sth. more complex then pointers or ints. And avoid
recursion as hell.
The kernel will not oops, but instead overwriting your
current task_struct.
> Does gcc grow the stack only at the beginning of a function, or
> can it save the space and re-grow it on entering code_blocks
> also?
Check the assembler stage output ;-)
Regards
Ingo Oeser
--
Feel the power of the penguin - run [email protected]
<esc>:x