Erik,

Just for the purposes of edification (and curiosity), are you able to
elaborate on "long reads"? Its understandable such a scheme would be
implemented in the network drivers, but how exactly does it work, as
opposed to a polling scheme or an ISR? I will, of course, Google in a sec
as well.

Many thanks!


On Wed, Jan 1, 2014 at 6:18 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> On Tue Dec 31 12:47:30 EST 2013, krystian.lew@gmail.com wrote:
> > Thank you for the feedback, i think "ctl" file and numbering scheme
> > selection could do the job.  And maybe it could help to establish
> > reasonable base for SPI and others.
> >
> > Is it safe to just generate new dev tree - to return either BCM,
> > WiringPi or board pin set - based on pin numbering scheme selection
> > made by user?  What will happen if a process would try o read/write
> > from/to pin when numbering scheme is changed?  I tried to look at
> > devproc.c (what would happen when process dies and something is
> > reading its /proc entries) but i can�♯ see any specific
> > precautions there.
>
> (sorry about the funny formatting.  the header specifies
>         Content-Type: text/plain; charset=iso-2022-jp-2
> which might be the same as iso-2022-jp, but i haven't tracked this down
> yet.)
>
> there is a 1 character argument to attach.  you can avoid the issue
> by letting the attach argument specify which scheme you'd like, e.g.:
>
>         mount -a '#Gx' /dev
>
> > Regarding ISRs - this is not implemented yet.  Polling at the moment
> > is the only option.  But maybe "events” file, with data
> > populated by interrupt routine would be the answer.  Is it correct
> > Plan 9 way of doing things?  QIO looks very suitable for this purpose.
>
> "long" reads are an established way to avoid polling.  plan 9
> was doing this long before i'd heard the term.  the network drivers
> work this way.
>
> - erik
>
>