On 30/04/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>Hi,
> I was looking for Opensolaris APIs equivalent to atomic_read() and
>atomic_set() found in Linux. The solaris' asm/atomic.h does not define
>such APIs. When I looked in the on-nv source, similar macros are
>defined in
http://cvs.
What is the correct way to pass in the "handle" parameter to xdrrec_create()?
I've seen examples such as:
...
...
XDR *xdrs = (XDR *)malloc(sizeof(XDR));
memset(xdrs, 0, sizeof(XDR));
...
xdrrec_create(&xdrs, 0, 0, (char *)xdrs, readFunc, writeFunc);
...
...
Note that the xdrs variable is being
According to the man pages the MT-Level of xdr_opaque() is "Safe" and not
"MT-Safe". If I have multiple threads that each create their own XDR stream
using xdrrec_create() and the buffer for each stream is tied to a separate
socket is it safe to be calling xdr_opaque() at the same time from eac
[EMAIL PROTECTED] wrote:
If those APIs do what their names suggests, what is the point
in having them?
"Atomic set" can hardly be anything other than a normal store
nor can "Atomic read" be much different from an ordinary read.
I'd find them useful.
For example, Studio 11 with -xarch=sparcv8
>Hi,
> I was looking for Opensolaris APIs equivalent to atomic_read() and
>atomic_set() found in Linux. The solaris' asm/atomic.h does not define
>such APIs. When I looked in the on-nv source, similar macros are
>defined in
>http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/comm
On 4/30/07, Atul Vidwansa <[EMAIL PROTECTED]> wrote:
Hi,
I was looking for Opensolaris APIs equivalent to atomic_read() and
atomic_set() found in Linux. The solaris' asm/atomic.h does not define
such APIs. When I looked in the on-nv source, similar macros are
defined in
http://cvs.opensolaris
Hi,
I was looking for Opensolaris APIs equivalent to atomic_read() and
atomic_set() found in Linux. The solaris' asm/atomic.h does not define
such APIs. When I looked in the on-nv source, similar macros are
defined in
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/d
On Mon, 30 Apr 2007, Paul Durrant wrote:
On 4/30/07, Frank Hofmann <[EMAIL PROTECTED]> wrote:
Hmm - ddi_enter_critical / ddi_exit_critical ?
That certainly sounds like it would do the job. Thanks :-)
You're welcome.
Btw, generically since noone really is able to memorize all that's
docu
On 4/30/07, Frank Hofmann <[EMAIL PROTECTED]> wrote:
Hmm - ddi_enter_critical / ddi_exit_critical ?
That certainly sounds like it would do the job. Thanks :-)
Paul
--
Paul Durrant
http://www.linkedin.com/in/pdurrant
___
opensolaris-code mailing l
On Mon, 30 Apr 2007, Paul Durrant wrote:
This is a hypothetical question for me but one could imagine
encountering such a problem...
If I have, say, an i2c device that has a fairly short clock timeout
period (i.e. it loses interest if it's part way through a transaction
and doesn't see a clock
This is a hypothetical question for me but one could imagine
encountering such a problem...
If I have, say, an i2c device that has a fairly short clock timeout
period (i.e. it loses interest if it's part way through a transaction
and doesn't see a clock edge for a certain period of time) what
mec
11 matches
Mail list logo
