Mouse mo...@rodents-montreal.org wrote:
Multiple threads can ioctl and nobody prevents one from having a
single process with multiple threads (pthreads, if you like).
Not only that, but even without threading, there are at least two ways
I can think of offhand that a file descriptor, once
Am 24.08.11 00:00, schrieb Mindaugas Rasiukevicius:
Marc Balmer mbal...@netbsd.org wrote:
Here comes the third iteration of the gpio(4) patch. In addition to
whjat I already described, u_int_XXX types have been replaced by
uint_XXX and gpio(4) is made MPSAFE. Comments?
Furthermore I am
Am 24.08.11 04:50, schrieb Mouse:
Well, you need to open it first, before you can to ioctl, and if
only one process can open it, only one process can ioctl it, right?
Wrong.
Agreed.
Multiple threads can ioctl and nobody prevents one from having a
single process with multiple threads
On Tue, Aug 23, 2011 at 08:24:03AM +0200, Marc Balmer wrote:
Furthermore I am thinking if it would be useful if more than one process
could open a gpio device, as a long as they use different pins, e.g. one
process controlls a stepper motor using some of the pins while another
process drives
Am 24.08.11 00:00, schrieb Mindaugas Rasiukevicius:
Marc Balmer mbal...@netbsd.org wrote:
Here comes the third iteration of the gpio(4) patch. In addition to
whjat I already described, u_int_XXX types have been replaced by
uint_XXX and gpio(4) is made MPSAFE. Comments?
Furthermore I am
Marc Balmer mbal...@netbsd.org wrote:
There is nothing what prevents from multiple threads calling gpioioctl
(), which is obviously not MP-safe. As soon as you will start fixing
this, it will bring you back to the point I have already stated - the
design needs to be MP-safe in general.
Well, you need to open it first, before you can to ioctl, and if
only one process can open it, only one process can ioctl it, right?
Wrong.
Agreed.
Multiple threads can ioctl and nobody prevents one from having a
single process with multiple threads (pthreads, if you like).
Not only that,
The attached diff adds the ability to pulse a pin with a set frequency
and duty cycle. A new gpio(4) ioctl, GPIOPULSE, and a new gpioctl(8)
command line option pulse are added.
Whereas the gpioctl(8) command line utility accepts the freqeuncy in
hertz and the duty cycle in percent, these values
The attached diff adds the ability to pulse a pin with a set frequency
and duty cycle. A new gpio(4) ioctl, GPIOPULSE, and a new gpioctl(8)
command line option pulse are added.
Whereas the gpioctl(8) command line utility accepts the freqeuncy in
hertz and the duty cycle in percent, these
