I have tried looking at it. But I understand only about 75% your code, I guess that is because of the private kernel API. What is the view of the Haiku developers about others using private APIs? And how stable are the APIs? -------------------------------------------- On Mon, 7/28/14, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote: Subject: [haiku-3rdparty-dev] Re: What I am trying to do. Crazy idea explained? To: haiku-3rdparty-dev@xxxxxxxxxxxxx Received: Monday, July 28, 2014, 12:08 AM On 28.07.2014 01:32, Earl Pottinger (Redacted sender earl_colby_pottinger@xxxxxxxxx for DMARC) wrote: > I hope I have not bored you with my silly idea. And I made it clearer > what it is I want to do. You might want to have a look at Haiku's RAM disk implementation [1] (not included in the default images). I wrote it mainly because BFS is awfully slow when working with large source trees (extracting and removing them). The driver uses private kernel API to directly access physical memory and to avoid unnecessary copying. Wrt. performance it should do pretty well. Wrt. features there's a lot of room for improvements. There's a small control program [2] to create and delete RAM disks. A disk can be read from a file and flushed back to it, but I never got around to add support for having it work like a journaling-unaware cache (automatic flushing and releasing memory when it gets tight). CU, Ingo [1] http://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/disk/virtual/ram_disk/ram_disk.cpp [2] http://cgit.haiku-os.org/haiku/tree/src/bin/ramdisk.cpp