[9fans] /sys/include/ape/errno.h

[9fans] /sys/include/ape/errno.h

[Lucio De Re]

I note that the choice of error numbers, specially those under the
heading
	/* bsd networking software */

is not consistent with BSD.  I also miss EWOULDBLOCK and ECONNRESET,
although I confess I did not search very far for them, so if they are
to be found elsewhere, please point them out to me.

What I want to know is whether the choice of errnos has a deeper
meaning, or whether I could just replace the values with those from a
recent (NetBSD 1.6.1, in my case) *BSD distribution.

I imagine I'd have to recompile all the libraries for consistency, at
least libap.a?

++L

Re: [9fans] /sys/include/ape/errno.h

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

the error numbers can never be relied upon;
that's why they've got symbolic names
(except in NFS where a subset is assigned specific numbers
corresponding to the Sun errno assignment of the time,
that often differ from those on the communicating systems,
requiring errno swizzling)

[-- Attachment #2: Type: message/rfc822, Size: 2921 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans mailing list <9fans@cse.psu.edu>
Subject: [9fans] /sys/include/ape/errno.h
Date: Tue, 6 Jan 2004 12:24:11 +0200
Message-ID: <20040106122410.J28128@cackle.proxima.alt.za>

I note that the choice of error numbers, specially those under the
heading
	/* bsd networking software */

is not consistent with BSD.  I also miss EWOULDBLOCK and ECONNRESET,
although I confess I did not search very far for them, so if they are
to be found elsewhere, please point them out to me.

What I want to know is whether the choice of errnos has a deeper
meaning, or whether I could just replace the values with those from a
recent (NetBSD 1.6.1, in my case) *BSD distribution.

I imagine I'd have to recompile all the libraries for consistency, at
least libap.a?

++L

Re: [9fans] /sys/include/ape/errno.h

[Lucio De Re]

On Tue, Jan 06, 2004 at 10:29:18AM +0000, Charles Forsyth wrote:
>
> the error numbers can never be relied upon;
> that's why they've got symbolic names
> (except in NFS where a subset is assigned specific numbers
> corresponding to the Sun errno assignment of the time,
> that often differ from those on the communicating systems,
> requiring errno swizzling)

Thanks, Charles.

Hm, in other words, I may as well start working on porting the
socket code I am working on to Plan 9, rather than make adjustments
for the missing error codes (EWOULDBLOCK and ECONNRESET).

That may make the next question redundant: many socket functions
are prototyped in APE with "int *len" as their last argument.
These days, in NetBSD these use soclen_t which is normally a uint,
but I think provision has been made for an int in some special
instances (I think it's a platform issue).

Does anyone know if the POSIX spec has changed to use "uint *len"
instead of "int *len" in the recent past (since the APE modules
were written)?  Or "socklen *len" or "size_t *len" as I have seen
all of these on occasion?

++L

Re: [9fans] /sys/include/ape/errno.h

[Charles Forsyth]

>>Hm, in other words, I may as well start working on porting the
>>socket code I am working on to Plan 9, rather than make adjustments
>>for the missing error codes (EWOULDBLOCK and ECONNRESET).

i didn't comment on the missing codes because i don't know
enough about them.  (for instance, i thought EWOULDBLOCK had been replaced
by EAGAIN in a standard.) i interact with socket code as little as i can!

Re: [9fans] /sys/include/ape/errno.h

[Lucio De Re]

On Tue, Jan 06, 2004 at 10:56:07AM +0000, Charles Forsyth wrote:
>
> >>Hm, in other words, I may as well start working on porting the
> >>socket code I am working on to Plan 9, rather than make adjustments
> >>for the missing error codes (EWOULDBLOCK and ECONNRESET).
>
> i didn't comment on the missing codes because i don't know
> enough about them.  (for instance, i thought EWOULDBLOCK had been replaced
> by EAGAIN in a standard.) i interact with socket code as little as i can!

Hm, making me think about it, if Plan 9 APE does not include such
conditions in its socket code, the code that deals with them can just
be removed.  I suppose the consequences may be dire, but at least I
have something to start from.

++L

Re: [9fans] /sys/include/ape/errno.h

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

I wrote the apesocket stuff to match 4.1c.  There wasn't any posix
spec at the time, didn't realize there was one now.  If you want
to replace them, go right ahead.  The current stuff is pretty
thin.

[-- Attachment #2: Type: message/rfc822, Size: 3528 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] /sys/include/ape/errno.h
Date: Tue, 6 Jan 2004 12:47:11 +0200
Message-ID: <20040106124711.K28128@cackle.proxima.alt.za>

On Tue, Jan 06, 2004 at 10:29:18AM +0000, Charles Forsyth wrote:
>
> the error numbers can never be relied upon;
> that's why they've got symbolic names
> (except in NFS where a subset is assigned specific numbers
> corresponding to the Sun errno assignment of the time,
> that often differ from those on the communicating systems,
> requiring errno swizzling)

Thanks, Charles.

Hm, in other words, I may as well start working on porting the
socket code I am working on to Plan 9, rather than make adjustments
for the missing error codes (EWOULDBLOCK and ECONNRESET).

That may make the next question redundant: many socket functions
are prototyped in APE with "int *len" as their last argument.
These days, in NetBSD these use soclen_t which is normally a uint,
but I think provision has been made for an int in some special
instances (I think it's a platform issue).

Does anyone know if the POSIX spec has changed to use "uint *len"
instead of "int *len" in the recent past (since the APE modules
were written)?  Or "socklen *len" or "size_t *len" as I have seen
all of these on occasion?

++L

Re: [9fans] /sys/include/ape/errno.h

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

EWOULDBLOCK would be moderately hard to do since you need that
info from the kernel and it doesn't give it to you.  The best you
could do is chedk q lengths with a stat and maybe approximate it.

ECONNRESET you probably could do by looking at the err file in
the connection directory.

[-- Attachment #2: Type: message/rfc822, Size: 2748 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans mailing list <9fans@cse.psu.edu>
Subject: [9fans] /sys/include/ape/errno.h
Date: Tue, 6 Jan 2004 12:24:11 +0200
Message-ID: <20040106122410.J28128@cackle.proxima.alt.za>

I note that the choice of error numbers, specially those under the
heading
	/* bsd networking software */

is not consistent with BSD.  I also miss EWOULDBLOCK and ECONNRESET,
although I confess I did not search very far for them, so if they are
to be found elsewhere, please point them out to me.

What I want to know is whether the choice of errnos has a deeper
meaning, or whether I could just replace the values with those from a
recent (NetBSD 1.6.1, in my case) *BSD distribution.

I imagine I'd have to recompile all the libraries for consistency, at
least libap.a?

++L

[9fans] Newbie Question: Plan 9 for a windows file server?

[Chris Lamrock]

Hi  - I'm a Plan 9 newbie - just got it installed on a box at home - it even
boots - took 3 video cards to get the "grapahics" working however! hehe

My plan is to set up Plan 9 to serve files to a small home network and do
some file backups. I'm not too concerned if I need to "work at it" to get
this to work as I like learning new things but I would like to know if this
is a feasible use for plan 9?

Any guidance would be greatly appreciated!

-Chris

Re: [9fans] /sys/include/ape/errno.h

[Lucio De Re]

On Tue, Jan 06, 2004 at 07:42:35AM -0500, David Presotto wrote:
>
> EWOULDBLOCK would be moderately hard to do since you need that
> info from the kernel and it doesn't give it to you.  The best you
> could do is chedk q lengths with a stat and maybe approximate it.
>
Yes, I think I'm going to bypass that one.  I'll see where it is
relevant, and eliminate all instances of it.  Without embarrassing
myself, I can point out that it is used in a module providing I/O
via Unix sockets, which is really not a Plan 9 favourite :-)

> ECONNRESET you probably could do by looking at the err file in
> the connection directory.

The entire I/O module will probably be streamlined to use exclusively
Plan 9 facilities.  I think a whole lot of problems will go away
as a result.  I was hoping to avoid this, but I'm not sure why one
should, Plan 9 is just superior, why battle with old fashioned
operations if one does not have to?

++L

Re: [9fans] /sys/include/ape/errno.h

[Lucio De Re]

On Tue, Jan 06, 2004 at 07:30:58AM -0500, David Presotto wrote:
>
> I wrote the apesocket stuff to match 4.1c.  There wasn't any posix
> spec at the time, didn't realize there was one now.  If you want
> to replace them, go right ahead.  The current stuff is pretty
> thin.

What would be safe here?  Renumber all the error codes to match
NetBSD (I'm sure all *BSDs are identical, but I guess I ought to
check) and submit the changed header file to Bell Labs so that a
new copy of libap.a can be generated to match?

Is this enough/everything needed?

++L

Re: [9fans] /sys/include/ape/errno.h

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 230 bytes --]

Renumbering could blow people away that actually have
compiled code lying around unless you get them to
recompile.

If you actually use error values rather than the symbols,
you're living a precarious life, vis a vis porting.

[-- Attachment #2: Type: message/rfc822, Size: 3012 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] /sys/include/ape/errno.h
Date: Tue, 6 Jan 2004 15:03:47 +0200
Message-ID: <20040106150347.P28128@cackle.proxima.alt.za>

On Tue, Jan 06, 2004 at 07:30:58AM -0500, David Presotto wrote:
>
> I wrote the apesocket stuff to match 4.1c.  There wasn't any posix
> spec at the time, didn't realize there was one now.  If you want
> to replace them, go right ahead.  The current stuff is pretty
> thin.

What would be safe here?  Renumber all the error codes to match
NetBSD (I'm sure all *BSDs are identical, but I guess I ought to
check) and submit the changed header file to Bell Labs so that a
new copy of libap.a can be generated to match?

Is this enough/everything needed?

++L

Re: [9fans] /sys/include/ape/errno.h

[Russ Cox]

> What would be safe here?  Renumber all the error codes to match
> NetBSD (I'm sure all *BSDs are identical, but I guess I ought to
> check) and submit the changed header file to Bell Labs so that a
> new copy of libap.a can be generated to match?

down that path lies madness.  use the names, that's what they're for.
the numbers aren't supposed to matter!

russ

Re: [9fans] /sys/include/ape/errno.h

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

they certainly differ between Unix system variants
they differ between xBSD and Linux.

finding them on Linux is fun:
	errno.h -> bits/errno.h + ifdefs + defs -> linux/errno.h -> asm/errno.h [whew!]

which i note in passing has
	#define EWOULDBLOCK EAGAIN

amongst other values, i find for example on FreeBSD:

#define	ENETDOWN	50		/* Network is down */
#define	ENETUNREACH	51		/* Network is unreachable */
#define	ENETRESET	52		/* Network dropped connection on reset */

but on Linux:

#define	ENETDOWN	100	/* Network is down */
#define	ENETUNREACH	101	/* Network is unreachable */
#define	ENETRESET	102	/* Network dropped connection because of reset */

and on Irix5.3 and Solaris

#define ENETDOWN        127             /* Network is down */
#define ENETUNREACH     128             /* Network is unreachable */
#define ENETRESET       129             /* Network dropped connection because

so all in all it seems a relative waste of time
and effort to make Plan 9's match
one rather than the other.

[-- Attachment #2: Type: message/rfc822, Size: 2519 bytes --]

From: "Russ Cox" <rsc@swtch.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] /sys/include/ape/errno.h
Date: Tue, 06 Jan 2004 08:25:42 -0500
Message-ID: <E1AdrDL-000JNk-Ng@t40.swtch.com>

> What would be safe here?  Renumber all the error codes to match
> NetBSD (I'm sure all *BSDs are identical, but I guess I ought to
> check) and submit the changed header file to Bell Labs so that a
> new copy of libap.a can be generated to match?

down that path lies madness.  use the names, that's what they're for.
the numbers aren't supposed to matter!

russ

Re: [9fans] /sys/include/ape/errno.h

[ron minnich]

On Tue, 6 Jan 2004, Lucio De Re wrote:
> is not consistent with BSD.  I also miss EWOULDBLOCK and ECONNRESET,
> although I confess I did not search very far for them, so if they are
> to be found elsewhere, please point them out to me.

well, keeping them different may keep SCO out of our hair. I thought at
one time I would say this in jest, but I was wrong.

ron

RE: [9fans] /sys/include/ape/errno.h

[Nigel Roles]

9fans-admin@cse.psu.edu wrote:
> On Tue, 6 Jan 2004, Lucio De Re wrote:
>> is not consistent with BSD.  I also miss EWOULDBLOCK and ECONNRESET,
>> although I confess I did not search very far for them, so if they are
>> to be found elsewhere, please point them out to me.
>
> well, keeping them different may keep SCO out of our hair. I thought
> at one time I would say this in jest, but I was wrong.
>
> ron

Oh no; a trivial change from the original source confirms guilt surely?

Re: [9fans] /sys/include/ape/errno.h

[Lucio De Re]

On Tue, Jan 06, 2004 at 08:25:42AM -0500, Russ Cox wrote:
>
> down that path lies madness.  use the names, that's what they're for.
> the numbers aren't supposed to matter!
>
I was looking for a standard definition, so that I could address:

	#define EPROTONOSUPPORT	37
	#define EPROTOTYPE 37

as found in /sys/include/ape/errno.h, which broke a module construct.
I wasn't suggesting that I wanted to use the numeric values instead.
I'm not sure how I want to solve the original problem, given that
Charles pointed out a similar duplication in Linux, was it?

	#define	EWOULDBLOCK	EAGAIN

or some such, from memory.

++L