Re: [PATCH] s390: Hypervisor File System

[Kyle Moffett <mrmacman_g4@mac.com>]

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"?

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.

Cheers,
Kyle Moffett

-
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/