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

  • From: Earl Pottinger <earl_colby_pottinger@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 18 May 2011 04:30:47 -0700 (PDT)

> Re: Writing Device Drivers Publishing notes> From: "Ingo Weinhold" 
> <ingo_weinhold@xxxxxx>
>> From: <earl_colby_pottinger@xxxxxxxxx> wrote:
>> And which nightly should I be using to best match Alpha3?> Currently the 
>> latest trunk revision will be the closest to alpha 3.Okay, currently 
>> building and testing r41505-gcc2-hybrid.
>> how do I mark a HaikuFS formatted drive to not be cached ...> I assume with 
>> HaikuFS you mean BFS?Yes.
> AFAIK there's no way to disable caching in general.> The block cache cannot 
> be disabled at all.Drats, foiled again.
>> 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.
>> 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 ...> Concurrent writes of the upper I/O layers are 
> relatively likely.> I/O is not serialized until the first point that requires 
> it.
Bingo!  Thanks for the clue (a 2*4 to the head does wonders at times).Added a 
simple monitor and found that I had tons of overlapping readsthat don`t do much 
on their own, but I also found writes overlappingthe reads and that is the path 
to a big mess.
Presently, I am now using semaphores to prevent any concurrent accessesbut 
later on I will probably try to allow concurrent reads but wait forthe all the 
reads to be finished before allowing any write access.
>> 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.
Again thanks, I will be looking into that code very soon.
>> 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.
I should had guessed that the same code underlaid both functions.

>Re: Writing Device Drivers Publishing notes>From: Stephan Aßmus 
>> From: <earl_colby_pottinger@xxxxxxxxx> wrote:
> I am not qualified to answer any of your questionsYou use Haiku, that alone 
> makes you better qualified than everyone but for one person (Hi Larry) that I 
> know.
> In Haiku however, the caching is much betterUnless it has be fixed recently I 
> am still finding repeated uses of Textsearch and Queries run faster on the 
> ramdrive vs my SSD.  Haiku appears not to be caching all the blocks read.  I 
> will test with lastest version to see if I am now wrong about caching.
> both your driver and Haiku's I/O subsystem are fightingYep, I am sure that 
> they are, that is why I ask if I could turn off caching for a storage device.
> namely to span multiple volumesI am still working out how to make that easy 
> for a user to configure.
> restore the RAM disk after a reboot.That works fine already.  I did steal the 
> idea from AGMS however.  And presently my version does not compress the image 
> written to disk.

> concentrate on those features only, and to work with the Haiku I/O cache 
> instead of trying to circumvent it.I wish I could, but if you have looked at 
> *ANYTHING* I have written for BeOS or Haiku you would know my coding style 
> will be unacceptable to the Haiku kernel developers.  I can`t figure out JAM. 
>  And Haiku`s kernel after all these years of development does not need anyone 
> with my poor C skills adding any code to it.  Try looking at my `Rocky Horror 
> Recovery Tools` to get an idea of what I mean, there is a reason I called it 
> that.

To anyone who can answer my next questions:
(1) Under the nightly build 41505-gcc2-hybrid I seem to be limited to static 
arrays that are less than 1 GB in size, while not a real problem will this be 
enforced also in Alpha3?
(2) No matter how I test the driver - I don't see any calls to uninit_driver(), 
am I missing something? 

Other related posts: