Re: [V9fs-developer] proposed change to error.c from a good idea by Russ

[Ronald G M. <rmi...@la...>]

Eric Van Hensbergen wrote:
> Settle down.  
ah, email coupled with my horrible writing style. Sorry if I am sounding 
unsettled -- I'm not. Just confused :-)

> The problem is, if file servers are going to
> include lots of cruft (like the full path) - its going to suck. 

I just don't know how to avoid it. I think it's going to be really hard 
to get every 9p server out there to do what we want -- so this could get 
ugly. Look at sshnet for an interesting example --

return "directory not found";

for an idea of what this might be like.

>We'll
> still be able to deal with it, but the dynamic error string
> registration stuff will get really bloated if every error as the full
> path string included.

how come the strstr approach won't work? That's the part I'm missing 
here. It seems like a reasonable approach.


> Fair enough, but lets work out a standard form so that we can prune
> "extra" information where desired.

But how can we get everybody out there to agree to this? One of our 
goals is to connect linux client to arbitrary 9p servers, even Plan 9 
ones -- how can we do this if we can't deal with certain classes of errstrs?

That's where I'm stuck.

> Customizations in every
> error string will mean that we'll have to store all error strings
> received and associate a number with them.

if you are using strcmp. Are we sure that the strstr approach won't do 
the job?


> Okay - so alternatives to the current mechanisms:
> 
> a) Come up with a method for marking "extended" info that we can
> ignore for base-level matching.  Of course this means we'll lose the
> extended info, except for perhaps in dmesg.

and cat /mnt/9/errstr, maybe?

> b) Change from a dynamic errorno system to one where user's can query
> the last error on a fid and get the error string from procfs/sysfs. 
> This could suck if there were actually several errors on a fid, but is
> that even possible?

can you strcat the errors together?

> 
> In general - this sucks, and will continue to suck a lot.  There is
> just not a reasonable way to pass the same error information through
> Linux's error mechanisms.

Is it time to bring up an errstr() syscall on Linux? Then there would be 
an errno of ERRSTR, meaning "see errstr for more info". So geterrstr 
looks like:
	char cp[512];
	if (errno == ERRSTR)
		errstr(cp, sizeof(cp));
	else
		memcpy(cp, sys_errlist[errno], sizeof(cp));

or some such. Maybe it's time to push linux on this a bit. I doubt very 
much they'll buy it, but what the heck -- we can ask.


> I don't think pushing for standardized error string formats in Plan 9
> is a bad thing.  Not every "customer" of a file server is going to be
> a human who can easily parse the error strings, being able to write
> code/scripts that deal intelligently with errors seems like a noble
> goal.

And, in some cases, the "customer" is the kernel, which makes this even 
more fun. Actually, that's where the problems usually start -- 9p server 
returns an error that does not map to a kernel errno, and the vfs does 
something that is "not what you wanted". That's exactly what I hit with 
xcpu -- "directory not found" got turned into a very non-intuitive error :-)

ron