Consider a driver that can perform a write to a driver; which then
sends the data to a HW-device, which processes the data and then
returns (interrupt-triggered) whether the processing was successful or
not: it returns a "transmission-status"!
A non-blocking "write" causes "ssize_t device_write()" to return
-EAGAIN, until finally the driver's output-buffer is available! Now
the instance code in "ssize_t device_write()" copies the data from the
user-application to the output-buffer and then sends this data to the
HW-device.
We now allow an application to chose between 2 modes of NONBLOCKING-write:
(a)
Just write (non-blocking) to the driver's output-buffer and return
(DON'T WAIT FOR HW-device to return "transmission-status").
We don't care if the HW-device processing suceeded or not.
(b)
Write (non-blocking) to the driver's output-buffer and ***NOW BLOCK***
(!) until the HW-device returns the "transmission-status": The
"tranmission-status" is fetched by the interrupt handler, which wakes
up the waiting processes - allowing it to fetch the
"tranmission-status".
In other words:
The non-blocking write is a normal non-blocking write up to the point
where the data is inside the output-buffer.
But then for (b), the "write" will wait (BLOCK) until it receives the
HW-device's status. (...and yes, I've looked at fsync - but a flush of
the output-buffer is not the same as getting feedback
("transmission-status") from the HW-device.)
Is this OK (allowed, or almost allowed, or not allowed)??
Are there other better ways of doing what I want ????? (In particular:
perhaps a (b)'s write should have to flow through a IOCTL instead - if
I wish to keep to Unix/Linux semantics???)
Thank you,
-Albert
/***** Code Example ****/
struct my_data {
u8 wait_for_transmission_status;
u8 data_for_hw_processing;
};
#define WAIT 1
#define NO_WAIT 0
For (a):
the application uses
write(fd, &(struct my_data){NO_WAIT, d}, \
sizeof(struct my_data));
For (b):
the application uses
write(fd, &(struct my_data){WAIT, d}, \
sizeof(struct my_data));
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
