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

[Eric V. H. <er...@gm...>]

On 8/28/05, Ronald G Minnich <rmi...@la...> wrote:
>=20
> > The problem is, if file servers are going to
> > include lots of cruft (like the full path) - its going to suck.
>=20
> 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 --
>=20
> return "directory not found";
>=20
> for an idea of what this might be like.
>

Well, to a certain extent that could mitigated by the solution the
lucho is working on (which would dynamically assign errno's to unknown
error strings).  Of course if there is dynamic info in each of those
strings (like path, or other debug info) then its going to get unruly.

I think its reasonable to have a standard error.h file with "standard"
error strings that everyone is expected to use for core errors.  The
fact that every application has its own Estring definitions seems
out-of-control.   Now, if you need something beyond the core error
strings, that's all well and good - but keep it static so that we can
easily dynamically map it.
=20
> >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.
>=20
> how come the strstr approach won't work? That's the part I'm missing
> here. It seems like a reasonable approach.
>=20

It breaks down when we want to report error strings which don't match
the core to the users.  We can store the error if it doesn't match the
strstr, but then no one will be able to strstr against it because
it'll have the path or some other crap in it.

>=20
> > Fair enough, but lets work out a standard form so that we can prune
> > "extra" information where desired.
>=20
> 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 errst=
rs?
>=20

The Plan 9 community isn't that big, I think we can come up with some
sort of consensus on this stuff.

>=20
> > 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.
>=20
> and cat /mnt/9/errstr, maybe?
>

ugh.  This sounds too much like Uriel's extended attributes stuff.=20
We'd need an errstr for every file and then have to match it to the
session.
=20
> > 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?
>=20
> can you strcat the errors together?
>=20

That's possible I suppose.  But could suck if we have a read-once
policy.  Just not a good solution here.

> >
> > 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.
>=20
> 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 =3D=3D ERRSTR)
>                 errstr(cp, sizeof(cp));
>         else
>                 memcpy(cp, sys_errlist[errno], sizeof(cp));
>=20
> 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.
>=20

Well, it may be woth raising the question - but no way in hell I'm
going there.  I'm not convinced we have the high ground here.

>=20
> > 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.
>=20
> 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 =
:-)
>=20

yeah, its unfortunate -- there will not be an easy way to handle this,
even with the error mapping stuff lucho is working on.  Essentially,
you'll get back some big negative error number and then you are going
to have to be smart enough to go to procfs or sysfs to get the string
mapping.

         -eric