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.
On Thu, Feb 21, 2008 at 10:02 PM, Rob McKeever <email@hidden> wrote:
> 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.
>
> I can provide you with some code that shows how to do this if you need.
>
> -Rob
>
> --
> Rob McKeever, email@hidden
> Mass Storage Group, CPU Software Engineering
> Apple Computer
>
>
>
>
>
>
> On Feb 21, 2008, at 5:47 AM, Valentin Slavov wrote:
>
> > Hello
> >
> > 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.
> >
> > 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.
> >
> > Thanks in advance
> > V.
> > _______________________________________________
> > Do not post admin requests to the list. They will be ignored.
> > Darwin-kernel mailing list (email@hidden)
> > Help/Unsubscribe/Update your Subscription:
> > http://lists.apple.com/mailman/options/darwin-kernel/email@hidden
> >
> > This email sent to email@hidden
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/email@hidden
This email sent to email@hidden
