Messages in this thread | | | Date | Tue, 2 May 2006 23:49:08 +0200 | From | Kay Sievers <> | Subject | Re: [PATCH] s390: Hypervisor File System |
| |
On Tue, May 02, 2006 at 02:30:43PM -0700, Greg KH wrote: > On Tue, May 02, 2006 at 04:48:42AM -0400, Kyle Moffett wrote: > > On May 2, 2006, at 00:00:53, Greg KH wrote: > > >On Mon, May 01, 2006 at 07:29:23PM -0400, Kyle Moffett wrote: > > >>So my question stands: What is the _recommended_ way to handle > > >>simple data types in low-bandwidth/frequency multiple-valued > > >>transactions to hardware? Examples include reading/modifying > > >>framebuffer settings (currently done through IOCTLS), s390 current > > >>state (up for discussion), etc. In these cases there needs to be > > >>an atomic snapshot or write of multiple values at the same time. > > >>Given the situation it would be _nice_ to use sysfs so the admin > > >>can do it by hand; makes things shell scriptable and reduces the > > >>number of binary compatibility issues. > > > > > >I really don't know of a way to use sysfs for this currently, and > > >hence, am not complaining too much about the different /proc files > > >that have this kind of information in it at the moment. > > > > > >If you or someone else wants to come up with some kind of solution > > >for it, I'm sure that many people would be very happy to see it. > > > > Hmm, ok; I'll see what I can come up with. Would anybody object to > > this kind of API (as in my previous email) that uses an open fd as a > > transaction "handle"? > > No, I think Kay played around with something like using the open fd of > the directory as such a lock (or was he using flock on it, I can't > remember now...)
If you can assume that processes accessing the values are cooperative, it already works without any changes:
$ time flock /sys/class/firmware echo 1 > /sys/class/firmware/timeout real 0m0.005s
$ flock /sys/class/firmware sleep 5& [1] 6468
$ time flock /sys/class/firmware echo 1 > /sys/class/firmware/timeout real 0m3.558s
Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |