Re: [PATCH] s390: Hypervisor File System

[Kay Sievers <kay.sievers@vrfy.org>]

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/