polling file descriptor

This agrees with the very first explanation in this thread, and I understand it, but other posters seems to have disagreed and totally misled and obfuscated me.

--
Mark
Reply to
Mark
Loading thread data ...

So it turnes out that 'select' on a gpio does make sense, unlike what was claimed on this thread before ?

For the purpose of my application, accuracy and quick response isn't necessary, so I ended up with a simple 'while'-style polling and a usleep, so it doesn't consume 99% of the CPU. This is sufficient.

--
Mark
Reply to
Mark

I remember writing about one.

Reply to
Rainer Weikusat

How do you deal with the race condition between reading the gpio pins and calling select()? IOW, how do you deal with this sequence of events:

1) SW reads GPIO pins. 2) One of them changes. 3) SW calls select() to wait for change.
--
Grant
Reply to
Grant Edwards

Like any PLC does edge contacts - keep an i/o image for every open file descriptor. Every call to read() copies current state into the i/o image. GPIO is generally in the order of 32 or 64 bits, nothing huge. select() compares current state with the i/o image, and if different, returns and copies current state into the i/o image. Otherwise it waits for a change, using whatever mechanism (data from network, interrupt, polling if it has to) is available.

-j

Reply to
jack

???

In Linux, select is ultimatively implemented as general 'wait loop' which invokes a 'file specific' poll method. The job of this poll method is to determine if some event of interest has already occurred. If it has, a bit mask representing the 'interesting ready events' is returned, otherwise, the thread which called select/ poll is put onto a waitqueue determined by the poll method. Some other code is then supposed to do a suitable wake_up in future. Afterwards, the poll method is invoked again in order to figure out what happened. So, either it can do that based on some stored information, that it can also do that when being called for the first time before the thread is ever put to sleep or it can't do that and then it also can't do that whenever it is called again to determine if the thread should continue to sleep or exit the kernel to continue execution of userspace code.

Taking this into account, your 1) - 3) seems to boil down to "but what if the poll method is broken" to me, and the answer is "it won't work then". But that's kind-of obvious and discussing hypothetical bugs in hypothetical device drivers seems like a rather weird past time to me. All that I originally intended to communicate is that it is possible to define semantics for a blocking read or write operation on a GPIO[-set] and consequently, also implement a poll method.

Reply to
Rainer Weikusat

That would be tolerable, but a much better way would be to specify what events you're interested in somehow. For example, with a 'set read mask' operation that specifies which bits are too be looked at and what values they must have for the descriptor to be considered readable. Since it is the descriptor that is checked for readability or writability, there should definitely be some per-descriptor structure.

DS

Reply to
David Schwartz

A mask indicating which bits to look at would be nice, for things like masking off fast-changing signals that are of no interest. Anything but a simple mask would complicate things more than (IHMO) is wise to have at the driver level. Sometimes an application is interested in a state change from 0 to 1 but not vice versa, sometimes in 'any state change in bits 3,4 and 5', sometimes in 'state changes in bit 3, but only if bit 0 is on' etc. etc. To cater for all possibilities one would need 2 or 3 different ioctls, and masks for 'interesting bits', 'interesting state', 'any state' for each fd.

I think that type of logic is a lot easier and clearer if implemented in the application itself using a masks than by opening one or more file descriptors and setting up masks on each of them for different conditions. The primary goal is to have the scheduling advantages and power savings from the application being able to block, not to push part of the application logic down to the driver.

-j

Reply to
jack

No, other posters were offering alternatives to the rather simplistic implementation of a GPIO driver you seem to have. If the GPIO hardware (PCI?) can raise INTA, INTB, INTC or INTD when a GPIO pin changes state, then the select/poll implementation for that driver can respond when the pin changes state - then you don't need to periodically test the state of the pin in your application.

scott

Reply to
Scott Lurndal

I think a minimal sane feature set would be a mask for bits of interest. A 'select' for read would indicate a hit if any of the bits not masked off had changed since the last 'read' from that descriptor. More than that is gravy. (And arguably needless complexity.)

DS

Reply to
David Schwartz

That does not seem like a nice device driver design, IMHO a decent driver should react to a state change with select().

-Michael

Reply to
Michael Schnell

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.