site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Csr49Jt0xRtzhP1pMtUITfX7COSk84SZd870oAdNmL0=; b=s7gdyxgc46rojV4uuKy4Wb2Pb/u7evd/K2CkLkrZzPmjC+tzbrfX9ZrQgaAxfCAgNR ngFT8pEBNUN9hHeD8iT4MYGr5ZX2gsudX4BOX32q0ted9fJia7guY+OaYpFaNvyK3RHI 7OR43UVpmhEdMf3WmgRhq+/i8h6sIQkk+PNyE= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IxF1qpzM3v+yAC0Va/KXDmh58gk7a8uM+8SlvXNzrdYMjkM8NUJTMHXsgxlzpYUp0r f5riTYRiIoAlznXjDnQtEzT68UGu/AOG9Zhplt32tzpAscH2ulYJV3WRCzrpoYPSspu1 I6KaFxXFcF5gla/LZx08mpyAPPGYomO07sZHs= 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 <drivers@mu.org> 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/drivers%40mu.org
This email sent to drivers@mu.org
-- 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com