Re: cross-bounday memory communication b/w user app and the Kernel.How?
Re: cross-bounday memory communication b/w user app and the Kernel.How?
- Subject: Re: cross-bounday memory communication b/w user app and the Kernel.How?
- From: "rohit dhamija" <email@hidden>
- Date: Sat, 3 Jun 2006 00:24:59 +0530
Thanks a lot for explaining the concept and guiding me !!!
I shall make the necessary changes and shall revert back in case I
face some issues.
In meantime, i have another doubt that I am formatting in new mail :)
Rohit.
On 6/3/06, Michael Smith <email@hidden> wrote:
On Jun 2, 2006, at 11:39 AM, rohit dhamija wrote:
> I shall try to explain my doubt again:
>
> I need to send various command packets to the device and get the
> corresponding response packet. My command consists of
>
> [a]. command identifier i.e. command_id
> [b] command payload: This command payload differs from command to
> command. The maximum size of command payload is:
>
> "unsigned char Commandpayload[257];"
>
> My output response packet again varies from command to command. The
> maximum size of response packet can be
>
> "unsigned char ResponseData[256];"
>
> So, one way is to make the shared structure (the structure to
> communicate with user kernel space) can be:
>
> typedef struct _mypacket{
> int command_id;
> union {
> unsigned char Commandpayload[257];
> unsigned char ResponseData[256]
> } MY_PACKET, *PMY_PACKET;
>
> But this type of structure will consume the maximum memory.
Unless you are going to have thousands of commands like this all
active at the same time, the amount of memory that they will use is
insignificant.
> So In
> order to avoid it, can we have pointers instead of static memory
> allocation ?
>
> The command packet the structure will be
>
> struct command_packet{
> int command_id
> unsigned char* cmd_payload;
> int size_of_command;
> }
>
> Similary for response_packet. Is this possible ?
This is exactly the situation that you described in an earlier
message, and which I responded to with sample code.
It does not in any fashion suggest that you need to copy anything, so
far.
= Mike
--
Rohit Dhamija(M) 9818446545
_______________________________________________
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