On Mon, 2008-04-28 at 22:48 -0700, Trent Piepho wrote:Sorry if I'm being dense; how do you want this bit to work? As I see it, there are a few options: 1) Have the files named as you suggest and all of them always present, albeit read-only until export. Very easy to use, easy to discover which file is which, a decent bit of memory usage having them all listed. 2) Have the files named as you suggest and you have to explicitly request them or have the kernel explicitly export them. To request them yourself you're going to need the gpio number so having the created file labelled nicely isn't a win over having it labelled with the gpio number. I 'spose there's a win for kernel exported gpios, they're more human readable, but you're still going to have to have the mappings available somewhere for the manually exported gpios anyway. 3) Have the files named as you suggest, explicit export/request but better parsing behind the control file so something like echo "export pca9557-0:5" > control works. Very very nice for the user, big heavy back end. 4) Status quo. Easy, efficient, potentially hard to discover which gpio you actually want. My vote's for 1 or 4. The first one is heavier but easier. The last one will need something like the discussed file mapping ranges to gpios. Do your expectations/ideas fit in cleanly anywhere above? Thanks, --Ben --
| Michal Piotrowski | Re: 2.6.23-rc3-mm1 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Fred Tyler | Slow, persistent memory leak in 2.6.20 |
| Roland Dreier | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Antonio Almeida | HTB accuracy for high speed |
