hi fellas,
Here is an errno.h patch which provides these new errno values.
XFS needs both values. ENOATTR is also required by the ext2
extended attributes project (and any other filesystem intending
to implement extended attributes in the future). Both values
need to be visible in both kernel and user space, so this patch
would be an initial step toward libc support also, hopefully.
In the absence of any cleaner way to do this (?), could we have
this patch applied please? Any/all feedback much appreciated
-- thanks.
cheers.
On Mon, Oct 08, 2001 at 12:22:02PM +1100, Nathan Scott wrote:
> hi there,
>
> On Sat, Oct 06, 2001 at 04:24:40PM +1000, monkeyiq wrote:
> > Hi,
> > Anyone know where these are defined in Linux? I dont seem
> > to be able to find them, even with find/grep in /usr/include.
>
> ENOATTR is not a blessed errno in Linux. In XFS we have simply
> defined it to be the same as ENODATA for the time being. The
> ext2 extended attributes project define it to be EDOM, also as
> a stop-gap solution I imagine.
>
> A similar problem exists with ENOTSUP (defined by POSIX 1003.1b?)
> - this is only supported via linux/asm-parisc/errno.h as a real
> errno, among all the architectures. Both the XFS and ext2 extended
> attributes implementations define this errno to be EOPNOTSUPP as an
> interim solution. Ah, wait - from a quick test, glibc does seem to
> do exactly this also, so this one is not a problem (except perhaps
> on the parisc port? -- hmm, that could actually be a bug on parisc).
>
> On a related topic, but not specific to extended attributes - for
> XFS in general, we needed one other errno - EFSCORRUPTED. This is
> used when XFS goes into forced shutdown mode for a filesystem that
> has been detected as on-disk corrupt, to stop making the situation
> any worse (user must umount/xfs_repair). We couldn't find any pre-
> existing Linux errno vaguely similar to this one, so it was defined
> to "990" until a real solution could be found.
>
> Obviously, these are not the correct long-term solutions ... they
> need to become real Linux errno's, I think, and ENOTSUP could be
> defined to EOPNOTSUPP? - EWOULDBLOCK, EDEADLOCK seem to do this.
> I'm not sure how to reach that point though (CC'ing linux-kernel
> for any advice) - for reference, in IRIX these errnos are defined
> as follows:
>
> ENOATTR = Attribute not found
> EFSCORRUPTED = Filesystem is corrupted
>
> > Also, is there a function to get a string rep of the error
> > that occured in the attr code?
>
> Someday it should become a part of asm-XXXXX/errno.h (errno's are
> architecture specific) and the libc strerror(3) routine should be
> able to provide a meaningful string. But currently that does not
> happen.
>
> cheers.
>
> --
> Nathan
--
Nathan
> XFS needs both values. ENOATTR is also required by the ext2
> extended attributes project (and any other filesystem intending
> to implement extended attributes in the future). Both values
> need to be visible in both kernel and user space, so this patch
> would be an initial step toward libc support also, hopefully.
>
> In the absence of any cleaner way to do this (?), could we have
> this patch applied please? Any/all feedback much appreciated
Such an update needs to be synchronized with glibc to avoid people
getting all sorts of odd "unknown" error messages. In general I dn't
see why its needed.
> > EFSCORRUPTED = Filesystem is corrupted
EIO is normally used for this
As to the string names for errors. They can't sanely go into the kernel
or kernel headers. Remember there are a lot of languages out there
hi Alan,
Thanks for the comments.
On Tue, Oct 09, 2001 at 01:37:55PM +0100, Alan Cox wrote:
> > XFS needs both values. ENOATTR is also required by the ext2
> > extended attributes project (and any other filesystem intending
> > to implement extended attributes in the future). Both values
> > need to be visible in both kernel and user space, so this patch
> > would be an initial step toward libc support also, hopefully.
> >
> > In the absence of any cleaner way to do this (?), could we have
> > this patch applied please? Any/all feedback much appreciated
>
> Such an update needs to be synchronized with glibc to avoid people
> getting all sorts of odd "unknown" error messages.
Yup, understood. I was punting that it would need to appear
in the kernel headers first though, so thought I'd test the
water with you guys and try to understand the process for such
a change.
The "unknown error" messages can't really be avoided in all cases
anyway - even when there is a coordinated libc release there will
always be (the vast majority of?) people running new kernels with
older libc versions for awhile ... thats life though, I guess, if
there's no other solution to the problem.
> In general I dn't see why its needed.
For ENOATTR, an error code is needed which doesn't conflict
with any other used in the filesystem, so that a failure to
get/set/... an extended attribute can be distinguished from
other errors related to looking up the pathname initially,
as an example.
> > > EFSCORRUPTED = Filesystem is corrupted
>
> EIO is normally used for this
Yeah, the semantics here are slightly different, but perhaps we
can get away with this... (Steve? do you know of any cases in
the code where we need to be able to distinguish the EIO value
from EFSCORRUPTED? or any other reason why this wouldn't work?
It is the obvious one - I'd imagine there was a reason for not
using it originally).
> As to the string names for errors. They can't sanely go into the kernel
> or kernel headers.
Yes, that wasn't being suggested.
> Remember there are a lot of languages out there
Yup - understood.
thanks.
--
Nathan