anon... anon.al wrote:
> Driver "Read" standard usage ('protocol')
>
> Concerning "read", I would like to ask if there are specific standard
> guidelines for using it, without bending it in a non-standard way:
>
>
> A driver controls a Hardware-device (HW-device) which makes "16-byte
> messages" available from time to time. If the HW-device has a "16-byte
> message" available, it signals this via interrupt, causing the driver's
> interrupt handler to load the message into the next slot in the driver's
> Ring-Buffer (from where applications can then get the message).
>
> _____________
> |m1 |m2 | | - Ring-Buffer in driver
> -------------
>
> Message m3 will be loaded into the last slot.
> Message m4 will overwrite m1.
> etc.
>
> Each message: 16 bytes
>
> 3)
> If an application calls "read(fd, buffer, len)" with len = 32,
> then the "application's driver instance" will sleep until a "16-byte
> message" is available in the Ring-Buffer. Then the instance will deliver
> those 16 bytes to the application.
>
> If in the mean time, a second "16-byte message" has now become
> available, the instance delivers this 2nd "16-byte message" to the
> application and "ssize_t read()" returns 32.
> If however, no second "16-bytes message" is available, the instance
> notes that it has only provided 16 of 32 bytes (note "QQQ"- marker) and
> "ssize_t read()" returns 16.
>
> The application will then (like cat) call "read(fd, buffer, len)" again,
> with len = 16, to receive the remaining 16 bytes. If a new "16-byte
> message" is available, it is delivered to the application (then the note
> "QQQ" is removed) and "ssize_t read()" returns 16.
> OTHERWISE: If still no new data was available the INSTANCE DOES NOT
> SLEEP (since it has noted "QQQ") and "ssize_t read()" will (remove the
> note "QQQ") and then return 0.
> The application then knows that no new data is available. Nonetheless,
> if the application still wants the next 16 bytes, it will start a new
> round, again calling "read(fd, buffer, len)" with len = 16, which will
> now cause the instance to block (note removed), until these 16 bytes are
> available.
>
Why would the driver not make the caller sleep when 2nd 16 bytes are read?
If you have multiple of 16 bytes data packets, the 2nd call for 16 bytes
is same
as a new read of 16 bytes? Why would you return zero? Moreover, I don't
think
input devices will have EOF? For example, Audio Device probably won't
have EOF
It will send you data as long as it is sampling. Is there any other
behaviour? I think
the 2nd 16-bit (for initial 32-bit) read should block.
> 4)
> If an application calls "read(fd, buffer, len)" with len = 17,
> then the instance will block until 16 bytes become are available - then
> the instance will deliver the data to the application and "ssize_t
> read()" (will note "QQQ" and) will returns 16.
> The application (like cat) will now call "read(fd, buffer, len)" with
> len = 1.
> In the instance, "ssize_t read()" will (remove the note) and return
> -EINVAL, since a message must have a multiple of 16 bytes.
>
> Is this a standard, correct behavior?
> I would especially like to know about 3), where the driver notes "QQQ",
> so that it knows that the application definitely has at least 16 bytes,
> and that further read calls should NOT BLOCK.
>
I agree.
> Thanks,
> Albert
--Himanshu
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
