Re: Doing file io from kernel IOKit driver context, again.
Re: Doing file io from kernel IOKit driver context, again.
- Subject: Re: Doing file io from kernel IOKit driver context, again.
- From: Inso Reiges <email@hidden>
- Date: Wed, 9 Jun 2010 23:10:33 +0700
Mike,
Wow, that sound like a great idea!
I don't like to go from the lower level (block) to the upper (fs) and
back to lower myself, i suspect there can be a lot of synchronization
issues involved. Again, your idea sounds great, but i wonder how safe
it is? How do i lock the file down so that i can guarantee the block
map won't go stale for as long as a have the image of that file
mounted?
Inso.
On Wed, Jun 9, 2010 at 10:23 PM, Michael Smith <email@hidden> wrote:
>
> Inso,
> You don't want to be doing file I/O, and in fact you don't need to.
> Your userspace helper tool provides everything you need; it can create your
> backing files, obtain the physical block map for each file (F_LOG2PHYS), and
> then pass all of this information into your driver. The driver then just
> looks up the IOMedia that hosts the filesystem and performs block I/O
> against it while the user process holds the file down.
> File I/O has a lot of baggage that you just don't want or need for this.
> Take it from folks that know, eh?
> = Mike
> On Jun 9, 2010, at 2:00 AM, Inso Reiges wrote:
>
> Hello,
>
> After searching darwin mailing lists i got a general impression that
> doing file io from kernel context is discouraged, especially if it is
> an IOKit driver context.) People mostly just say "don't do it", ask
> for bigger picture issues and advise an alternative which works.
>
> Me, i want to write a driver similar to Apple's Disk Images just for
> the sake of writing it. Obviously this loop device has to map block
> device read/writes to file read/writes which means doing file io in
> kernel. After messing around a bit with IOHDIXController i figured
> that hdiutil/diskimages-helper calls createDrive64 through HDIX
> Controller's user client. The data it sends as a parameter seems like
> an xml plist with image file name among other things.
>
> So if the bigger picture issue is actually creating an IOKit loop
> device driver, how do i safely read and write files from such driver?
> How does Apple Disk Images handles that?
>
> I experimented a bit with the following approach:
> 1) Pass an image file name to IOKit driver.
> 2) Lookup and acquire corresponding vnode through VFS layer.
> 3) Call VNOP_READ, VNOP_WRITE on vnode.
>
> It seems to be working fine for me.
> Is there anything to look out for with this approach? Are there any
> other alternatives without using a VFS layer?
>
> P.S. I also looked at bsd vn driver which does basically the same, but
> i want my driver to be an IOService object to have access to
> IORegistryEntry.
>
> Thank you,
> Inso.
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-kernel mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
> --
> Excellence in any department can be attained only by the labor of a
> lifetime; it is not to be purchased at a lesser price -- Samuel Johnson
>
>
>
>
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden