Re: Adding pulse support to gpio(4), gpioctl(8)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> [E]ven without threading, there are at least two ways I can think of
>> offhand that a file descriptor, once opened, can end up in multiple
>> processes' open file tables: fork() and SCM_RIGHTS.
> What can be done about this?

I suppose you could remove fork() and SCM_RIGHTS.  The system would
probably be at least moderately usable without the latter, but it would
take some work to create a usable system without bringing back fork()
fd sharing in some form.

> Do any drivers protect themselves against the situation where after a
> fork() the parent and the child process can access the file
> descriptor without causing mayhem?

Probably.  The well-written ones certainly do. :)

> What is the best way, or common practive to make driver really
> mpsafe?

Old historical practice is to depend on the machine being uniprocessor
and the kernel non-preemptive, which means that once one process enters
xxxioctl(), no other can unless the driver sleeps.

Newer historical practice I know less about, but at least up until
fairly recently, the kernel was effectively giantlocked, leading to
much the same situation in practice.

Now...I dunno what the right thing is.  Probably just use locking of
some sort, even if just a big lock around the bulk of the driver's
routines.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B