site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com OK, I hope this doesn't sound too confusing... -Rob -- Rob McKeever, robm@apple.com Mass Storage Group, CPU Software Engineering Apple Computer On Feb 21, 2008, at 12:28 PM, Valentin Slavov wrote: Rob, Thanks, a piece of code would be useful. Can you explain briefly how the stack should look like? If I subclass IOBlockStorageDevice to which nub should I attach the newly created driver? Regards, V. Valentin, If I understand what you're trying to do, I don't think you need to recreate the entire stack. You should be able to subclass IOBlockStorageDevice and give it whatever backing store you want. -Rob -- Rob McKeever, robm@apple.com Mass Storage Group, CPU Software Engineering Apple Computer On Feb 21, 2008, at 5:47 AM, Valentin Slavov wrote: Hello Although the first solution seems more appropriate, I need to implement a whole driver stack for virtual devices (like the apple disk image drivers), but unfortunately I can't find sufficient documentation for this task. I'd like to know if there are more appropriate solutions and other hints that might be useful. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 1) create a driver that subclasses from IOService, either directly or from another subclass. Give it a personality that allows it to attach itself either to IOResources or to your hardware, assuming you have some. Have that driver implement the backing store interface and any other calls you require (see below). 2) Create a second driver that subclasses from IOBlockStorageDevice and implements any required/desired methods. These methods should, in most cases, simply redirect to the first driver (see above) which will be attached as it's provider. 3) During the start routine (or some function called after start() has run) of the first driver, have it instantiate, init, attach and then register for sevice an instance of the second driver. At this stage, you will have a functioning block storage device with your own custom backing store. For an explanation as to why two drivers are required instead of just one, see the notes in the IOBlockStorageDevice and IOBlockStorageDriver header files. On Thu, Feb 21, 2008 at 10:02 PM, Rob McKeever <robm@apple.com> wrote: I can provide you with some code that shows how to do this if you need. I need to develop a virtual block device which will be used for testing filesystem operations with files larger than 16TB or so. Obviously all this space should be virtual (in a sparse image sense), however there should be some kind of backing store to hold the filesystem meta data. Since meta data is written at different places in the volume (hfs+ keeps a backup at the end of the device and so on, a backing store for certain "ranges" should be used. The backing stores should be configurable (I was thinking of providing bsd names and searching the I/O Kit registry for IOMedia objects, and attaching them to my driver). Another solution would be to implement the driver as a filter scheme but this is inflexible since backing store cannot be configured easily. Thanks in advance V. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/robm %40apple.com This email sent to robm@apple.com This email sent to site_archiver@lists.apple.com