You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2002/11/27 19:09:14 UTC
errno values over the net
I have svn_ra_svn mostly working (the remaining big piece is
connection establishment and SASL integration, which is a doozy). One
of the bits of remaining polish is in how to pass src_err values over
the wire when communicating error values. Although the most common
errno values like ENOENT tend to have the same value on all systems,
they aren't portable in general; for instance, ECONNRESET is 104 on
Linux and 131 on Solaris.
The only way I can think of to handle this gracefully is to make a
giant table containing a whole bunch of known errno values, with
initializer entries like:
{ ENOENT, "ENOENT" },
#ifdef EROFS
{ EROFS, "EROFS" },
#endif
(we'd #ifdef all the values not specified by POSIX, probably). Then
we could pass errno values over the wire as strings. Such a table
would conceivably have to be updated for new platforms or platform
versions, and of course begs the question of what to do when you get
EL2NSYNC from some system call on Solaris and want to pass it over the
wire to a Linux system.
Do people have better ideas?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: errno values over the net
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Wed, 2002-11-27 at 14:29, Ben Collins-Sussman wrote:
> > I don't understand the problem. If your server process is linking
> > against libsvn_fs (which it must be), then it has access to the whole
> > APR error system and SVN error system (which is just an extension.)
> > Why not just move apr error codes over the wire?
>
> The goal is to marshal and unmarshal an svn_error_t structure over the
> wire. The apr_err field is portable, but the src_err field is not.
>
> > FWIW, mod_dav_svn marshalls the error code to the client in an xml
> > structure. You can do something similar, no?
>
> It looks like ra_dav punts on the src_err field (always sets it to 0).
> I guess I can do the same.
Yah, I'd do that. It's very rare to even *have* a src_err in an
svn_error_t structure; most errors are originally generated by the svn
libs. When they do get a src_err, they usually just wrap it up with
an apr_err anyway. At a minimum, you can have your server process
dump the src_err to a logfile.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: errno values over the net
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Wed, 2002-11-27 at 14:29, Ben Collins-Sussman wrote:
>
>
>>I don't understand the problem. If your server process is linking
>>against libsvn_fs (which it must be), then it has access to the whole
>>APR error system and SVN error system (which is just an extension.)
>>Why not just move apr error codes over the wire?
>>
>>
>
>The goal is to marshal and unmarshal an svn_error_t structure over the
>wire. The apr_err field is portable, but the src_err field is not.
>
>
I saw a funny thing on my way through apr_errno.h:
/**
* @see APR_STATUS_IS_EAGAIN
* @warning use APR_STATUS_IS_EAGAIN instead of just testing this value
*/
#ifdef EAGAIN
#define APR_EAGAIN EAGAIN
#elif defined(EWOULDBLOCK)
#define APR_EAGAIN EWOULDBLOCK
#else
#define APR_EAGAIN (APR_OS_START_CANONERR + 13)
#endif
And lots of other similar defines. Which means that some APR codes may
well be different on different systems, doesn't it?
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: errno values over the net
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2002-11-27 at 14:29, Ben Collins-Sussman wrote:
> I don't understand the problem. If your server process is linking
> against libsvn_fs (which it must be), then it has access to the whole
> APR error system and SVN error system (which is just an extension.)
> Why not just move apr error codes over the wire?
The goal is to marshal and unmarshal an svn_error_t structure over the
wire. The apr_err field is portable, but the src_err field is not.
> FWIW, mod_dav_svn marshalls the error code to the client in an xml
> structure. You can do something similar, no?
It looks like ra_dav punts on the src_err field (always sets it to 0).
I guess I can do the same.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: errno values over the net
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> One of the bits of remaining polish is in how to pass src_err values
> over the wire when communicating error values. Although the most
> common errno values like ENOENT tend to have the same value on all
> systems, they aren't portable in general; for instance, ECONNRESET
> is 104 on Linux and 131 on Solaris.
I don't understand the problem. If your server process is linking
against libsvn_fs (which it must be), then it has access to the whole
APR error system and SVN error system (which is just an extension.)
Why not just move apr error codes over the wire? Both ends have
svn_error_codes.h and apr_error.h to interpret them. The whole point
of APR is to make error codes portable.
FWIW, mod_dav_svn marshalls the error code to the client in an xml
structure. You can do something similar, no?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org