|
Be
Driven
|
Device Drivers in the Be Os |
|
|
|
|
|
Q
& A : Kernel |
|
Questions and Answers
-
This is probably going to grow quite large.
-
This is NOT an alternative for reading the Rest of the document.
-
This is an Attempt to cover not so Obvious questions that always
cause Hell when askded.
-
Every time an Q&A is added to this, the un-obvious aspect
is placed back into the main document.Tricky Kernel Address Questions
Q:
how can I then solve the problem of irregularly sending data to the
app at times that the driver/hardware determines?
A:
You can do it with a shared memory area and a semaphore. The kernel
driver puts the data into a shared memory area that it creates and
releases a semaphore when it has put data in there. You can arrange
the area as a circular buffer and you're all set. Alternatively you
could send the thread a signal to let it know that data is available.
-Dominic Giampaolo (dbg@be.com)
Q:
When a User calls a driver, what thread does a function call to read()
in the driver come from, Kernel or User Space.
A:
User space is only visible from the driver when it has been entered
on
behalf of the user program (i.e. open, read, write, ioctl, close).
You would not be able to access user space from an interrupt handler.
--Dominic Giampaolo (dbg@be.com)
A:
I see. I think I was confused by the fact that the driver specific
functions (read(), write() etc.) is mediated through the kernel
but has nothing to do with the threads of the kernel itself. When
the app calls a driver function it is executed when the calling
app runs, not when any kernel thread runs
--thoan@ifm.liu.se
Q:
Can I submit a function pointer in 'data' (in the ioctl()-call) and
call that from the driver? (Does it point to a valid address space?)
A:
Possible, but not desirable. Remember, it would want to only be valid
for that ONE call. You couldn't call it willy nilly, as you might
be in another team, of which then you couldn't access this function.
In short, don't do it.. Try architecting your system differently.Q:
Can you send signals across team boundaries??
A:
Yes. But I don't see how it's necessary, or even desirable. Signals
are really low bandwidth (they can't take any arguments) so an application
still has to take steps to make sure it "knows" what the
signal actually means. There is also a very limited number of distinguishable
signals available.
-hplus@zilker.net
Q:
Does the kernel guarantee that the client address space of a given
driver call will be valid (i.e. accessible) when that driver call
is handled by the client?
A:
If I spawn a kernel thread from the driver, does that not live in
the same space as the spawning thread? Or is the driver a very special
kind of kernel thread?
Q:
Should I send data unbuffered to the Caller?
A:
Don't Do Unbuffered Data Passing.
Every time you pass data to another thread, it is possible that
the kernel needs to perform a context switch between the threads to
let the data be handled. A context switch takes in the order of 5000
cycles to complete,
meaning that a 66MHz BeBox for example can't do more than about 10k
of them per second before being completely flooded under the overhead
of the switch itself.
This applies to any method, be it shared, semaphore protected areas
or message ports. Always try to buffer at least a dozen or so characters
inside the driver, and send the entire contents of the buffer it at
all possible at once
(send 1 word, another thread processes it, meanwhile 10 new words
buffer up at the hardware, next time the driver is given CPU time
it should send all 10 words as a single operation).
-Osma Ahvenlampi (oahvenla@cc.hut.fi)
The Communal Be Documentation Site
1999 - bedriven.miffy.org |