From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 31 Dec 2013 14:18:51 -0500 To: 9fans@9fans.net Message-ID: <821cb256954ce0bf4ad389ffe5eafa50@mikro> In-Reply-To: <4657D0DD-A119-4E19-B50D-EBCE5861F9F8@gmail.com> References: <35A33F66-EF03-4659-ABA1-F25082DBFE41@gmail.com> <4657D0DD-A119-4E19-B50D-EBCE5861F9F8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] "gpio device" for Plan 9 Topicbox-Message-UUID: aa28c5c2-ead8-11e9-9d60-3106f5b1d025 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.FN"t 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$B!I(B 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