site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On May 23, 2006, at 8:39 PM, Chinki wrote: Hi Garth, Thanks for your mail. The general consensus is DO NOT DO FILE I/O FROM THE KERNEL. The consequence of this is twofold: Etc.. After reading the documenation, i could get just the rough idea : But I am not sure if the above steps are correct. So... What problem are you trying to solve? -- Terry Thanks in advance, Chinki On 5/23/06, Garth Cummings <gcummings@apple.com> wrote: On May 23, 2006, at 6:53 AM, Chinki wrote:
Hello all,
Greetings!!!
Upon searching the archives, I found out that although this question has been posted but there has been NO Answer for the same till date.
I need to bulk write/read through my IO Driver (kext). Can any one explain how to use IOMemoryDescriptor ? Any sample example that illustrates the very simple communication. It sounds like you might not be aware of the existence of the Apple Developer reference library. I highly recommend you start at <http:// developer.apple.com/referencelibrary> and use the search engine on those pages to find what you're looking for. The reference library includes developer documentation, technical notes, sample code, and technical Q&As. This information is also on your Mac OS X machine at /Developer/ADC Reference Library if you have the development tools installed. You might also want to review the mailing list guidelines at <http:// lists.apple.com>. Note particularly the statement "While Apple employees monitor the lists, Apple doesn't guarantee that questions will be answered. The mailing lists are not a replacement for formal support or bug reporting procedures." If you need help beyond what the documentation and sample code provides, you can also make use of Apple Developer Technical Support. You can read more about this program at the URL in my email signature. Best wishes, --gc
Garth Cummings gcummings@apple.com Sr. Software Engineer Apple Developer Technical Support <http://developer.apple.com/technicalsupport> _______________________________________________ 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/tlambert%40apple.com _______________________________________________ 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... I had already searched the APPLE website and old archives but there is no sample provided. Believe me, but its truth that there are several queries for the same question. But no straight solution. Can ANY BODY FROM YOUR TEAM post a simple straight method how to use IOMemoryDescriptor to write / read data.\ The bulk write/read at USER-LEVEL framework is QUITE EASY. But at kernel level it is mentioned Write / Read take a pointer to IOMemoryDescriptor and its no where described how to exactly fill this structure. What needs to filled in this IOMemoryDescriptor ?What are the steps ? At Write function , Apple documentation tells nothing about the same. There are a number of companies that believe they can interpose block I/O drivers and substitute data on the way in and out of the device driver and/or monitor the contents of data transactions, and they come to this list and ask how they can write different data to a block device behind the kernel's back. They are mistaken, since it's not possible to do safely. Doing this ignores the fact that the kernel does caching, and they have no mechanism for cache invalidation in layers above themselves that they are interposing. Specifically, it ignores data and buffer caching that occurs at upper layers, or even in user space, and the fact that there's no invalidation mechanism to indicate to upper level consumers that their cached contents are stale and must be reloaded. For example, say you had an interposing layer whose intent was to encrypt directory entry names on the way to disk, and decrypt them on the way back out during lookup/readdir operations. The problem with such a layer is that by returning an unencrypted name to the upper layers of code, it will end up having the unencrypted name cached in the directory name cache. (1) If someone can get a handle to a file or directory in the volume, they can use an fcntl() to obtain an unencrypted path to the file. (2) Subsequent forward lookups for the unencrypted name will get hits in the directory name cache on their unencrypted values, and not actually hit the FS - which means they would not actually hit your encruption layer, and therefore the lookup would be successful on the unencrypted path, even if you didn't have the encryption keys (i.e. the name cache happens at a layer higher than your implementation, and the name cache, when you get a hit, does not hit the FS which means it doesn't hit your interposing block driver). In general, it's a *VERY* bad idea to do file I/O from the kernel. Instead, you should pass your information back to a user space daemon, and have it do the work for you, instead. If you need to do file I/O to load firmware (as an example), either put the firmware in a discardable section (vm_deallocate() it after it's loaded in the card), or have a user space daemon communicate the firmware to your driver via a series of ioctl() calls to push the data *temporarily* into the kernel, so it doesn't take up real or virtual memory in your driver. 1. Use prepare() to make sure that physical memory is availabefor i/ o transfer 2. Use writebytes/readbytes 3. Give the direction, kDirectionOut or kDirectionIn 4. Do i/o 5. complete() unwire the memory So i would request again to atleast give the exact path incase you have some simple example at your end. And if its not availalbe, then plz atleast paste a simple steps for the same, Again, in general, the question you are asking will be met with the question "what are you actually trying to do?". Knowing the problem you are trying to solve would enable us to provide you with pointers to alternate approaches to solving it - approaches that don't require the use of file I/O from the kernel. This email sent to tlambert@apple.com This email sent to site_archiver@lists.apple.com