[haiku-development] Re: Writing Device Drivers Publishing notes

  • From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 16 May 2011 02:06:56 +0200

On Sun, 15 May 2011 15:48:45 -0700 (PDT) Earl Pottinger 
<earl_colby_pottinger@xxxxxxxxx> wrote:
[...]
> So here are my questions:
> In testing the code I am getting diffirent error results depending if I
> test with Alpha1, Alpha2 or the latest nightly release (presently using
> r41339-x86gcc2hybrid).  Should I drop working with the Alphas?  And which
> nightly should I be using to best match Alpha3?

Currently the latest trunk revision will be the closest to alpha 3. The plan is 
to create the release branch in a few days. When you release your driver, it 
might be better to build it under an official Haiku release, though. While we 
don't really promise binary compatibility of the alphas, we do at least try to 
avoid breaking it. Random trunk revision have a much higher likelihood of some 
breakage.

> Part of my problems appear to be caused by Haiku Disk Caching software,
> how do I mark a HaikuFS formatted drive to not be cached when it is written
> to?

I assume with HaikuFS you mean BFS? AFAIK there's no way to disable caching in 
general. There are two kinds of caches BFS uses: The file cache (per file) and 
the block cache (for the whole underlying partition). The file cache can be 
disabled on a per-file basis by using the open mode O_NOCACHE. So that can only 
be done by the client opening the file. The block cache cannot be disabled at 
all.

> Part of my problems seem to be caused but delays generated by my driver as
> it reads and writes large blocks data to/from storage.

Note that journaling file systems (like BFS) have to write one or more blocks 
relatively often and synchronously. If, as a consequence, you write a large 
data block each time, that might explain delays.

> Is there a max
> latency that Haiku's kernel needs?

What kind of latency do you mean?

> Should I turn off interrupts while
> read/writting data tracks?

That will only yield you a panic(). Even if it did work, it would make the 
whole system unresponsive while interrupts are disabled. Whenever you disable 
interrupts, you want to do that only for as short a time as possible (a few 
microseconds at most).

> A possible but unlikely possibility is HaikuFS issuing additional
> read/writes to the driver before the previous one is done, does HaikuFS honor 
> the
> block/non-blocking IO flags?

BFS ignores those flags (I'd wager disk based FSs on most platforms do that). 
IIRC POSIX does not specify any semantics regarding using those flags with 
regular files. I don't think that is related anyway.

Concurrent writes of the upper I/O layers are relatively likely. I/O is not 
serialized until the first point that requires it. That is usually the (disk) 
device driver that knows how it has to communicate with the device -- if the 
device supports concurrent I/O, serialization won't be necessary at all.

> If not, I can add my own blocking code to the
> read/write hooks but I would like to avoid adding any code that will slow
> the drive down if possible.

If you need I/O operations to be serialized, it is your own responsibility to 
do that. Most disk device drivers use an I/O scheduler (private API: 
src/system/kernel/device_manager/IOSchedulerSimple.h (or IOCache.h for 
read-only media)) to perform the serialization. It does not only serialize but 
also group, order, and prioritize I/O operations.

> Malloc() vs Create_Area() which is better for creating a few very large
> (64MB - 1.5GB) buffers?

malloc() simply uses create_area() directly for large (> 0.5 MB) allocations. 
The only difference is that create_area() gives you more control over the area 
attributes.

> Where, oh where should I post/upload my test drivers for other developers
> to see?  I am ready to upload my simple drivers that I know work ok to
> Haikuware but I am not sure that is the right place to upload the debugging
> versions as they can not be consider stable or for general usage.
> If I do upload them to Haikuware, is adding the string 'DEBUGGING VERSION'
> and posting warnings in large read letters in the read-me file enough?

I suppose so.

CU, Ingo

Other related posts: