Re: Device Driver Etiquette

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Matthew,

On 6/1/07, Matthew Fredrickson <[email protected]> wrote:
Greetings,

I maintain a device driver that has been bitten by the transition to 4K
stacks.  It is a T1/E1 line interface PCI card driver that is
maintained outside of the kernel, although is used by a significant
number of people.  The card has a part for doing echo cancellation, but
it is accessed through a vendor API which (when we received it) was
quite stack heavy.  It used the stack for a number of large data
structures, although I have moved a great deal of them (particularly
the larger ones) onto the heap instead of the stack.  Although this has
reduced stack usage to the point where it is usable within 4K stacks,
on some code paths, it can still use quite a bit of stack space (though
under 4K) for local variables and a handful of small data structures.
The problem is that in order to initialize and use the echo canceler,
there is a firmware load portion which takes a noticeable period of
time (~5-10 seconds).  That is done through this stack heavy portion of
the code.

As Peter suggested earlier, the best strategy would be to
cleanup the code and make it stack-light in the first place ...

My question is this: is there a way to either work around the problem I
am seeing with the stack without recompiling the kernel with 8K stack
size or without disabling irqs for such a long period of time (which I
think is not a nice thing to do either)

There are standard mechanisms to push off long duration or
sleep-capable work from interrupts-disabled contexts to user
contexts. But those contexts can also, obviously, be interrupted,
so if you're stack-heavy and suffer a concurrent interrupt (which
you most definitely will in any codepath this long), there's always
the possibility of stack overflowing. I don't really see a better
solution to this than using bigger stacks or reducing your usage
of the same, but of course, better suggestions would be difficult
to give without looking at the code in question.

OR is it acceptable (although
not nice) to simply fix it this way, by disabling irqs while it loads
the firmware?

IMHO, *not*. You could try this, in any case, and learn it the
hard way :-)

Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux