handling file size in resource manager

Hello,
I’ve created a resource manager that manages a device connected over a USB connection. A device file is created in the /dev directory whenever the device is attached. The device file supports all the normal operations of open, close, read, and write.

My problem is that I need io operations to be packet based, not byte based. That is, when I do a read, I want to receive one packet, not some number of bytes. fread only allows me to specify how many bytes I’m expecting however. I don’t know how to change this behavior.

So what I currently do, is I specify the max packet size to fread, and then the driver only sends at most one packet. If I specify less to fread, and the driver gives more bytes than specified, those bytes are lost.

What happens though is that fread sees he didn’t get all the bytes specified and so issues another io_read to the device file, which my driver handles by sending the next packet. It does this until max packet size is reached or no more packets are available (and my driver returns ENODATA). Then fread returns to the client program with all these packets tacked together.

This is not desirable behavior. Does anybody know how I can fix this so only one packet is read at a time, even though the packet length is not known beforehand? I tried messing around with keeping attr->nbytes at 0 based on some info in the Helpviewer, but that didn’t do anything. I’d like to know how this is supposed to be done.

Thanks,
-Aaron

Try to use read instead and use NON_BLOCKING mode in open()

Hi Aron

I agree with mario.

In the resource managers io_read handler you have to check how many bytes the client wants to read. If this number of bytes is not sufficient for the whole packet (i.e. the clients read buffer is too small) you can return zero bytes. Otherwise you return only one complete packet regardless if the number of bytes requested by the client is big enough for two or more packets.

It should be considered to respond with an error status in the case where the client tries to read a packet with an insufficient buffer size - otherwise you can’t distinguish from the case where no data is ready to read.

Regards,
Peter