From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <35A33F66-EF03-4659-ABA1-F25082DBFE41@gmail.com> <4657D0DD-A119-4E19-B50D-EBCE5861F9F8@gmail.com> <821cb256954ce0bf4ad389ffe5eafa50@mikro> Date: Tue, 31 Dec 2013 11:48:38 -0800 Message-ID: From: Skip Tavakkolian To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c30600c1476b04eed9d8f7 Subject: Re: [9fans] "gpio device" for Plan 9 Topicbox-Message-UUID: aa379318-ead8-11e9-9d60-3106f5b1d025 --001a11c30600c1476b04eed9d8f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable i won't answer for Erik, but... there is nothing magic about "long" reads. basically you create multiple proc's (i.e. rfork) and dedicate one to the reader function. ioproc(2) library takes care of the housekeeping nicely; also the man page has an example. On Tue, Dec 31, 2013 at 11:37 AM, Shane Morris wrot= e: > 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 wro= te: > >> 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=EF=BF=BD=E2=99=AF see any specifi= c >> > precautions there. >> >> (sorry about the funny formatting. the header specifies >> Content-Type: text/plain; charset=3Diso-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=E2=80=9D 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 >> >> > --001a11c30600c1476b04eed9d8f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
i won't answer for Erik, but...

the= re is nothing magic about "long" reads. basically you create mult= iple proc's (i.e. rfork) and dedicate one to the reader function. iopro= c(2) library takes care of the housekeeping nicely; also the man page has a= n example.



On Tue, Dec 31, 2013 at 11:37 AM, Shane Morris &l= t;edgecomberts@= gmail.com> wrote:
Erik,

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

Many thanks!


On W= ed, Jan 1, 2014 at 6:18 AM, erik quanstrom <quanstro@quanstro.net&= gt; wrote:
On Tue Dec 31 12:47:30 EST 2013, krystian.lew@gmail.co= m wrote:
> Thank you for the feedback, i think "ctl" file and numbering= scheme
> selection could do the job. =C2=A0And 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? =C2=A0What will happen if a process would try o read/wri= te
> from/to pin when numbering scheme is changed? =C2=A0I tried to look at=
> devproc.c (what would happen when process dies and something is
> reading its /proc entries) but i can=EF=BF=BD=E2=99=AF see any s= pecific
> precautions there.

(sorry about the funny formatting. =C2=A0the header specifies
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Content-Type: text/plain; charset=3Diso-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. =C2=A0you can avoid the issue by letting the attach argument specify which scheme you'd like, e.g.:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mount -a '#Gx' /dev

> Regarding ISRs - this is not implemented yet. =C2=A0Polling at the mom= ent
> is the only option. =C2=A0But maybe "events=E2=80=9D file, = with data
> populated by interrupt routine would be the answer. =C2=A0Is it c= orrect
> Plan 9 way of doing things? =C2=A0QIO looks very suitable for this pur= pose.

"long" reads are an established way to avoid polling. =C2= =A0plan 9
was doing this long before i'd heard the term. =C2=A0the network driver= s
work this way.

- erik



--001a11c30600c1476b04eed9d8f7--