Re: [PATCH] s390: Hypervisor File System

[Kay Sievers]

On Mon, May 01, 2006 at 09:00:53PM -0700, Greg KH wrote:
> On Mon, May 01, 2006 at 07:29:23PM -0400, Kyle Moffett wrote:
> > On May 1, 2006, at 16:38:15, Greg KH wrote:
> > >On Sun, Apr 30, 2006 at 01:18:46AM -0400, Kyle Moffett wrote:
> > >>On Apr 29, 2006, at 17:55:01, Greg KH wrote:
> > >>>relayfs is for that.  You can now put relayfs files in any ram  
> > >>>based file system (procfs, ramfs, sysfs, debugfs, etc.)
> > >>
> > >>But you can't twiddle relayfs with echo and cat; it's more suited  
> > >>to high-bandwidth transfers than anything else, no?
> > >
> > >Yes.
> > 
> > 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.

If the count of values handled in a transaction is not to high and it
makes sense to group these values logically, why not just create an
attribute group for every transaction, which creates dummy attributes
to fill the values in, and use an "action" file in that group, that
commits all the values at once to whatever target? That should fit into
the ioctl use pattern, right?

Kay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/