lkml.org 
[lkml]   [2000]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: module reentrancy
Hello,

> I could use a little advice on reentrancy issues for
> modules.
>
> I have written a device driver that is nothing more
> than a circular FIFO buffer in memory. The read and
> write methods access user space, so I know that those
> sections of code need to be reentrant. Since the
> module represents one shared buffer, I use a couple of
> global variables to keep track of the begin and end of
> the buffer. I understand that the filp->private field
> provides some protection for reentrancy, but don't
> know if that is appropriate in this case. Would a
> rwlock be a good solution? The buffer is going to be
> used to collect some information from a modified IDE
> subsystem, so it will be written to many times in
> short periods of time, and thus needs to have
> efficient write methods.
>
> I've read all I could find on reentrancy in the
> kernel docs and in Alessandro Rubini's excellent book.
> Any other pointers to things I could read (or good
> examples of reentrant modules) would be appreciated.
>

If you only have a couple of integers to set, you can probably
get away with atomic operations. Without knowing more though,
I'm not sure what else to suggest. But here's my advice:

-if you are checking against these values often, a rwlock is
probably the best choice (e.g. while(var < end) { foo() };)
-if you check begin+end once, atomic ops are the way to go
(e.g. start = buf+begin ; count = end-start)
-if you have to update begin/end non-atomically and check them
only once, use a spinlock, it's the least expensive lock

--
Eric Lowe
Software Engineer, Systran Corporation
elowe@systran.com


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.058 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site