Hi,
I thought in older linux driver books and docs on the internet it said
that you should not rely on a atomic_t being a certain size, because in
some archs it may be different.
However, in reading Documentation/atomic_ops.txt and articles like
http://lwn.net/Articles/71732/, it sounds like in current 2.6 kernels
the atomic_t is at least 32 bits. Is this correct, and can you safely
write code which assumes this?
Some background:
I am removing locking and breaking up locks in drivers/scsi/*iscsi*.
Currently, a recv context (network layer softirq) can write to
session->max_cmdsn, and a xmit context (iscsi single threaded workqueue
thread) will read it. In the current code this is done under the
session->lock along with a lot of other operations.
I have some patches that can almost remove the session lock from the
recv path, but I have this one last issue with how to handle the
session->max_cndsn number check, before I can completely remove it. I
thought that the session->lock for just this one use is overkill and
thought a atomic_t would be better, so that is why I am asking.
Thanks.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
