This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Patch to correctly report error codes in jffs2

> From: "Michael Checky" <Michael_Checky at Thermoking dot com>> 
>I've attached a patch to fix the reporting of error codes in the jffs2/eCos
> interface.  The jffs2 core routines return negative error codes, but the
> eCos flash I/O routines used by jffs2 did not.  Also  the IS_ERR macro was
> not correct.
> BTW, I've noticed that the jffs2 CVS sources are newer than the eCos CVS
> sources.  It's probably time to update the eCos source tree.
> Michael Checky

Hi Michael.

I've taken a look at this patch. This comment got me a little worried:

! #define IS_ERR(err) ((long)(err) <= 0)  
! // assumes no pointer will have the MS bit set

I don't think this is a safe assumption. Flash can quite often be high
up in memory. The linux solution is better:

static inline long IS_ERR(const void *ptr)
        return (unsigned long)ptr > (unsigned long)-1000L;
But this is still not %100 perfect. I would prefer this though.

You modification for the return codes for flash operations seems
OK. But while looking at that code i found another problem. The ramfs,
romfs and the fileio layer all use positive error codes. If jffs2 is
returning negative error codes to the fileio layer, this is going to
be a problem. The fileio layer could do the wrong thing when errors
happen and the "user" code gets the wrong values in errno.

I'll open a bugzilla bug for this.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]