Re: Write/Read Bulk communication process in KEXT. How?
Re: Write/Read Bulk communication process in KEXT. How?
- Subject: Re: Write/Read Bulk communication process in KEXT. How?
- From: Terry Lambert <email@hidden>
- Date: Wed, 24 May 2006 11:34:46 -0700
On May 23, 2006, at 8:39 PM, Chinki wrote:
Hi Garth,
Thanks for your mail.
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.
The general consensus is DO NOT DO FILE I/O FROM THE KERNEL.
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.
The consequence of this is twofold:
(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.
Etc..
After reading the documenation, i could get just the rough idea :
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
But I am not sure if the above steps are correct.
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.
So...
What problem are you trying to solve?
-- Terry
Thanks in advance,
Chinki
On 5/23/06, Garth Cummings <email@hidden> 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 email@hidden
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
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:
This email sent to email@hidden