Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - io write functions.: (7 Items)
   
io write functions.  
Hi all, 

I need to get some data which originates from a file in to a buffer op the resource manager. Reason for this is that the
 data in the buffer has to be checked for its file format and then passed on to an FPGA. (if the file format is wrong 
possible damage to the FPGA can occur)

I read and followed the Resource Manager how to. This works pretty well for text - but when in do a "cp $fpga_bit_file /
dev/anyio" -- only the text gets copied (the first couple of bytes) and the rest is... well just gone?

I can cat /copy a complete text file and  concatenate the messages received (with resmgr_msgread())  to a bigger buffer.
 But when I do 'binary' files (whats the difference??) it does not arrive.

Any pointers?

Jeffry 


Re: io write functions.  
Forget I ever asked ;-) I do have a other question though - bare with me please ;) 


When the device is opened; /dev/anyio - a message is sent to io.open and io_read or write. However multiple messages are
 sent to io.close. I wanted to copy the bit file to mem and then on io.close perform some other functions like parsing. 
However io.open gets executed multiple times (as  much as it takes to read the whole file i assume)

Can I some how set a flag or something that prevents this behavior? 

Kinds regards.

Jeffry 
RE: io write functions.  
 

> -----Original Message-----
> From: Jeffry Molanus [mailto:ing.gila@gmail.com] 
> Sent: November 22, 2007 9:48 PM
> To: ostech-core_os
> Subject: Re: io write functions.
> 
> Forget I ever asked ;-) I do have a other question though - 
> bare with me please ;) 
> 
> 
> When the device is opened; /dev/anyio - a message is sent to 
> io.open and io_read or write. However multiple messages are 
> sent to io.close. I wanted to copy the bit file to mem and 
> then on io.close perform some other functions like parsing. 
> However io.open gets executed multiple times (as  much as it 
> takes to read the whole file i assume)
> 
> Can I some how set a flag or something that prevents this behavior? 

Reading between the lines a bit here ... but I'm taking away from
this that you're open callouts are expensive.

You can tell if a file is opened with intent to perform any additional
IO operation or just for 'stat' type purposes by looking at the mode
values passed in and also the type of open message that it is.

Hope this helps,
 Thomas
Re: RE: io write functions.  
Thomas,


When the copy operation to /dev/anyio is completed; I want to call a
certain function but if and only if the copy is complete. The image
file has to be checked for validness.

So basicly this is what I want to do:

from a bash shell:

cp $configuratio.bit /dev/anyio

when the cp operation is completed I want to call
check_configuration_file()  ( or similar).

From  your reply I take out of that ;-) that I have to filter the
message for stat and such. I'll give it a try.

Kind regards,

Jeffry
RE: RE: io write functions.  
 

> -----Original Message-----
> From: Jeffry Molanus [mailto:ing.gila@gmail.com] 
> Sent: November 23, 2007 6:20 PM
> To: ostech-core_os
> Subject: Re: RE: io write functions.
> 
> Thomas,
> 
> 
> When the copy operation to /dev/anyio is completed; I want to 
> call a certain function but if and only if the copy is 
> complete. The image file has to be checked for validness.
> 
> So basicly this is what I want to do:
> 
> from a bash shell:
> 
> cp $configuratio.bit /dev/anyio
> 
> when the cp operation is completed I want to call
> check_configuration_file()  ( or similar).
> 
> From  your reply I take out of that ;-) that I have to filter 
> the message for stat and such. I'll give it a try.

If you think about what cp does ... it performs a series of operations
in order to do the copy.  Things like checking to see if the file 
exists, what kind of file it is etc, before it does the main 
open()/write()/close() sequence.

So for what you are describing above it should be as straightforward as
not replying to the client (from the write handler) until the data transfer
operation is complete.  When the call returns, you can call your 
check_configuration_file() function.

Don't know if that helps at all,
 Thomas
Re: RE: RE: io write functions.  
The cp utility copies the data in 'parts' does it not? i.e 

 iofuncs_attr.nbytes=4096;

So if a file is 2*4096 large; It would peform the write handler 2 times and I have to reply 2 times, no? I might not 
just understand this fully yet, so here is the code (relevant bits) of the io_write handler.
	

int io_write (resmgr_context_t *ctp, io_write_t *msg, RESMGR_OCB_T *ocb)
 	{
 	    int     status;
	    char    *buf;

buf = (char *) malloc(msg->i.nbytes + 1);
 	    if (buf == NULL)
 	        return(ENOMEM);

resmgr_msgread(ctp, buf, msg->i.nbytes, sizeof(msg->i));
  memcpy(d->prog_file + offset ,buf,msg->i.nbytes);
    offset +=msg->i.nbytes;
    d->prog_size+=msg->i.nbytes; 	

return (_RESMGR_NPARTS (0));

You mean I should not return with _RESMGR_NPARTS(0) right now?
RE: RE: RE: io write functions.  
 

> -----Original Message-----
> From: Jeffry Molanus [mailto:ing.gila@gmail.com] 
> Sent: November 26, 2007 8:45 AM
> To: ostech-core_os
> Subject: Re: RE: RE: io write functions.
> 
> The cp utility copies the data in 'parts' does it not? i.e 

write() --> MsgSend w/ IO_WRITE --> your handler.

However many times the client (cp in this case) calls write() is
how many times you are going to get write messages.  
 
>  iofuncs_attr.nbytes=4096;
> 
> So if a file is 2*4096 large; It would peform the write 
> handler 2 times and I have to reply 2 times, no? I might not 
> just understand this fully yet, so here is the code (relevant 
> bits) of the io_write handler.

You need to reply for every write ... with the number of bytes
that you have written.  

> int io_write (resmgr_context_t *ctp, io_write_t *msg, 
> RESMGR_OCB_T *ocb)
>  	{
>  	    int     status;
> 	    char    *buf;
> 
> buf = (char *) malloc(msg->i.nbytes + 1);
>  	    if (buf == NULL)
>  	        return(ENOMEM);
> 
> resmgr_msgread(ctp, buf, msg->i.nbytes, sizeof(msg->i));
>   memcpy(d->prog_file + offset ,buf,msg->i.nbytes);
>     offset +=msg->i.nbytes;
>     d->prog_size+=msg->i.nbytes; 	
> 
> return (_RESMGR_NPARTS (0));
> 
> You mean I should not return with _RESMGR_NPARTS(0) right now?

I'm assuming that you do something with buf and you have some
options:

Option 1:
- Reply only after you have finished processing the write.  Not knowing
what your end goal is here, I don't know if this is applicable to you
or not. You can save the rcvid information and simply return with 
RESMGR_NOREPLY to indicate that you don't want to framework to reply
to the client, and then after you are finished processing the write
data (ie buf) then you can do a MsgReply() yourself to unblock the
client.

Option 2:
- You keep going the way you are going and then hold off replying to
the client when they perform a close until you have finished processing
all of the data that they have sent to you.  In this case you need to
put some logic into the close_ocb handler.

There are other options, but to keep it simple, those would be the first
two approaches I'd consider.

Hope this helps,
 Thomas