9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Skip Tavakkolian <skip.tavakkolian@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] "gpio device" for Plan 9
Date: Tue, 31 Dec 2013 11:48:38 -0800	[thread overview]
Message-ID: <CAJSxfmLq+_g_5ERwQu75XLp_MxhP7a0BEmCD8DCPmK9tYaL2KQ@mail.gmail.com> (raw)
In-Reply-To: <CANZw+5f=qXfTTd1hsBV+Z-X41VX9RAyMZ90yKDpYNARn5DOGtg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]

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 <edgecomberts@gmail.com>wrote:

> 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
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 3374 bytes --]

  reply	other threads:[~2013-12-31 19:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-29 22:04 Krystian Lewandowski
2013-12-29 22:34 ` erik quanstrom
2013-12-30  7:32 ` Skip Tavakkolian
2013-12-30 22:38   ` Shane Morris
     [not found] ` <35A33F66-EF03-4659-ABA1-F25082DBFE41@gmail.com>
2013-12-31 17:46   ` Krystian Lewandowski
2013-12-31 19:18     ` erik quanstrom
2013-12-31 19:37       ` Shane Morris
2013-12-31 19:48         ` Skip Tavakkolian [this message]
2013-12-31 19:50         ` erik quanstrom
2013-12-31 20:45           ` Shane Morris
2013-12-31 22:03             ` erik quanstrom
2013-12-31 22:17               ` Shane Morris
2013-12-31 22:52                 ` erik quanstrom
2013-12-31 22:57           ` Krystian Lewandowski
2013-12-31 23:16             ` Shane Morris
2013-12-31 23:35               ` Shane Morris
2014-01-01  0:04               ` Krystian Lewandowski
2014-01-01  0:12                 ` Shane Morris
2014-01-01  1:12     ` Matthew Veety
2014-01-01 11:38     ` Richard Miller
2014-01-01 22:16     ` erik quanstrom
2014-02-28 23:30       ` Krystian Lewandowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJSxfmLq+_g_5ERwQu75XLp_MxhP7a0BEmCD8DCPmK9tYaL2KQ@mail.gmail.com \
    --to=skip.tavakkolian@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).