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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
