Messages in this thread | | | Date | Sun, 25 Feb 2007 05:46:59 +0000 | From | Christoph Hellwig <> | Subject | Re: [PATCH 05/44 take 2] [UBI] internal common header |
| |
On Tue, Feb 20, 2007 at 05:21:48PM +0200, Artem Bityutskiy wrote: > > In that case it's not an *implementation* version number, but rather > > an on-disk *format* version number. > > True, will refine the comment. > > > There's a difference. It's also > > often not used much, since another way of dealing with the problem is > > to mark major each on-disk version with a different magic number. > > The advantage of version is that UBI can distinguish between garbage and > incompatible image. If I meet wrong magic - what is it - rubbish, > corrupted header? Should I run recovery procedure? Having version is > just cleaner.
Agreed.
> > Why isn't this being done via #define? It's not like this is any kind > > of an enumerated type, especially since it's being installed into a > > 32bit type, and not even an enum type. > > Will be fixed, thanks.
We currently try to use enums for most constants, then again this really doesn't matter all that much. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |