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

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 16 May 2011 10:14:45 +0200


On 16.05.2011 00:48, Earl Pottinger wrote:
Thanks for the help so far, I would like to clear up some points because
I am a little confused about how I should contine my development.

First, what I am trying to write is a driver for a Compressing Ram Drive
that also writes out it's contents to one or more storage units so that
it can recover itself after a reboot. Since the drive's data can also
compress in memory the data written to it. The ram drive's parameters
can be set to a larger value than the true available memory. This
write-back function allows two more features to be added to the ramdrive.

(1) Using a simple virtual memory model it allows me to set the size of
the drive larger than the memory in the computer would normally allow.
In this sense it looks like a hard drive with a large cache. But what it
does does better than said hard drive is when you reboot what is quickly
loaded in ram is the data tracks that you had been using. This helps the
ram drive continue to have better performance than a hard drive on the
same machine.

(2) Raid-??? A poor man's raid, not for data protection but for
combining the storage across a number of storage units. For example: I
have a number of 80 GB drives, I can easily setup the driver to combine
40GB off my boot drive and three other 80GB drives to look like a single
280GB drive even without compression enabled.

I am not qualified to answer any of your questions, but the first thing that comes into my mind when reading what you are trying to do, is that your RAM disk driver has a couple of features & advantages, which seem to be motivated by short-commings in the original BeOS I/O cache implementation. The caching in BeOS was horrible, so your driver solves a problem there. In Haiku however, the caching is much better, and it seems to me that both your driver and Haiku's I/O subsystem are fighting to provide the same features (in that regard). You driver has a number of other features of course, namely to span multiple volumes and to restore the RAM disk after a reboot. My immediate thinking goes into the direction whether you wouldn't be better off to concentrate on those features only, and to work with the Haiku I/O cache instead of trying to circumvent it. Of course I might be totally off with my understanding of the problem(s), since I know only little about the kernel and drivers.

Best regards,

Other related posts: