> 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?