Pardon my intrusion in the conversation, but I just couldn't not comment on this:
On Tue, 28 Oct 2008 12:50:03 +1100, David Gibson <[EMAIL PROTECTED]> wrote: >> So now my qualm is back to the beginning of the discussion. How do >> we encode the purpose of those pins reliably and within some >> standard framework, without getting *driver* specific? > > Um.. I fail to see how the purpose of a pin can be not driver > specific. GPIO stands for _General_ Purpose IO. The driver should just expose that info to user space and it should be up to the userspace application to decide what to do with that. The programmer should require absolutely no other intervention to the driver whatsoever. Anyone that has worked on data mining scientific equipment -eg. particle/photon scanners on VME boards with lots of GPIO pins- will tell you that meddling with kernel coding is totally unneeded, in fact it's stupid to require the student to do so. Usually some Windows API is given and the students write the programs on Windows to collect the data and control the device. I guess GPIOLIB and the new framework would have similar application in Linux -ie, requiring the programmer to write only a userspace to access the GPIO pins. From my understanding of the conversation, there are some people who fail to see the necessity of doing extra work to abstract this information away from the driver. A walk to a nearby experimental physicists lab with students working on such devices will convince you of the right way to do it actually. PS. I am of physics background myself, though a theoritical one and not experimental. But I did have many friends experimentalists, in particular I remember two that did exactly what I described. Neither did have any particular kernel/driver knowledge and neither did have to do anything extremely low-level to acquire the data. Both used windows user-level programming, though that was ~8years ago so don't expect me to remember the exact VME boards or APIs used... Konstantinos Margaritis Codex http://www.codex.gr _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev