[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
><superstippi@xxxxxx>
>> 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:
