Re: [PATCH] s390: Hypervisor File System

[Greg KH <greg@kroah.com>]

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...)

> Example script:
> >## Associate this process with an atomic snapshot
> >## of the /sys/hypervisor/s390 filesystem tree.
> >exec 3>/sys/hypervisor/s390/transaction
> >
> >## Read data from /sys/hypervisor/s390 without
> >## worrying about atomicity; as that's guaranteed
> >## by the open FD 3.
> >ls /sys/hypervisor/s390/cpus
> >cat /sys/hypervisor/s390/some_data_file
> >
> >## Create another reference in this process to the
> >## _same_ atomic snapshot
> >exec 4>&3
> >
> >## Does *not* close out the atomic snapshot
> >exec 3>&-
> >
> >## Yet another ref; still the _same_ snapshot
> >exec 6>/sys/hypervisor/s390/transaction
> >exec 4>&-
> >
> >## Regardless of what has changed in the meantime,
> >## our filesystem tree still looks the same
> >ls /sys/hypervisor/s390/cpus
> >
> >## Write out values
> >echo some_state >/sys/hypervisor/s390/statefile
> >
> >## Decide we don't like the changes and abort
> >echo reset >&6
> >
> >## Release the last copy of the snapshot and
> >## commit modified values
> >exec 6>&-
> 
> 
> This would allow usages like the following:
> >exec 3>/sys/hypervisor/s390/transaction
> >/bin/s390_change_hypervisor_state
> >## Look at new state; decide if we like it or not
> >if [ -z "$I_LIKE_THE_STATE" ]; then
> >	echo reset >&3
> >fi
> >exec 3>&-
> 
> 
> For actually implementing this; I'm considering a design which hangs  
> a transaction off of a "struct file" such that fork() and clone()  
> preserve the same transaction.  When a new process obtains an FD with  
> the given transaction it would add that process' current pointer to a  
> hash-table referencing the transaction data structure so that the open 
> () call could look up the transaction for a given task in the hash  
> table and use the data specified in the transaction.  When a  
> transaction is opened it would read the data atomically from the  
> hardware or in-kernel data structures and store an "initial" copy as  
> well as a "current" copy in per-transaction memory.  As a user could  
> theoretically pin NPROC * size_of_transaction_data * 2 of kernel  
> memory, transaction files should have fairly strict file modes or  
> some sort of resource-accounting semantic.  On a "reset" operation  
> the "initial" copy would be used to overwrite the "current" copy  
> again, and a changed bit would be unset.  Changes would result in the  
> changed bit being set.  When the transaction is closed, if the  
> changed bit is set then the data would be committed atomically, then  
> all the memory would be freed and the transaction removed from the  
> hash table.
> 
> Anything that sounds broken/fishy/"No that's impossible because..."  
> in there?  I appreciate your input; if this sounds feasable I'll try  
> to hack up a patch.

Sounds a bit complex.  Try looking at flock and see if you can pass that
info back to the sysfs attribute owners.

thanks,

greg k-h
-
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/