| Message ID | 1329250006-22944-2-git-send-email-rw@linutronix.de |
|---|---|
| State | RFC |
| Headers | show |
On Tue, 2012-02-14 at 21:06 +0100, Richard Weinberger wrote: > Specify the on-chip checkpoint layout. > The checkpoint consists of two major parts. > A super block (identified via UBI_CP_SB_VOLUME_ID) and > zero or more data blocks (identified via UBI_CP_DATA_VOLUME_ID). > Data blocks are only used if whole checkpoint information does not fit > into the super block. And superblock is also a more or less standard name used by file-system. I easily imagine difficulties and confusion when discussing UBIFS and UBI and mixing UBI and UBIFS supersblocks up. IMHO, anything unique is much better, even if it does not make much sense. E.g., "boss block" or "pomo block" (pomo = boss in Finnish). Would you consider picking a different name as well please?
Am 07.03.2012 17:09, schrieb Artem Bityutskiy: > On Tue, 2012-02-14 at 21:06 +0100, Richard Weinberger wrote: >> Specify the on-chip checkpoint layout. >> The checkpoint consists of two major parts. >> A super block (identified via UBI_CP_SB_VOLUME_ID) and >> zero or more data blocks (identified via UBI_CP_DATA_VOLUME_ID). >> Data blocks are only used if whole checkpoint information does not fit >> into the super block. > > And superblock is also a more or less standard name used by file-system. > I easily imagine difficulties and confusion when discussing UBIFS and > UBI and mixing UBI and UBIFS supersblocks up. IMHO, anything unique is > much better, even if it does not make much sense. E.g., "boss block" or > "pomo block" (pomo = boss in Finnish). > > Would you consider picking a different name as well please? > Will do. Thanks, //richard
On Wed, 7 Mar 2012, Richard Weinberger wrote: > Am 07.03.2012 17:09, schrieb Artem Bityutskiy: > > On Tue, 2012-02-14 at 21:06 +0100, Richard Weinberger wrote: > > > Specify the on-chip checkpoint layout. > > > The checkpoint consists of two major parts. > > > A super block (identified via UBI_CP_SB_VOLUME_ID) and > > > zero or more data blocks (identified via UBI_CP_DATA_VOLUME_ID). > > > Data blocks are only used if whole checkpoint information does not fit > > > into the super block. > > > > And superblock is also a more or less standard name used by file-system. > > I easily imagine difficulties and confusion when discussing UBIFS and > > UBI and mixing UBI and UBIFS supersblocks up. IMHO, anything unique is > > much better, even if it does not make much sense. E.g., "boss block" or > > "pomo block" (pomo = boss in Finnish). > > > > Would you consider picking a different name as well please? > > > > Will do. What about FASTMAP ? That's what the whole story is about. Building the logical/physical mappings (fast). Then call the "super block" FASTMAP_REF and the data stuff FASTMAP_DATA. That's the sanest I could come up with aside of smuggling in my favourite buzzword ROADMAP :) Of course we could stay with latin and name it: UBIUBI. ubiubi is latin for: where the heck is it, but I guess that's stretching it a bit :) Thanks, tglx
On Wed, 7 Mar 2012, Thomas Gleixner wrote: > On Wed, 7 Mar 2012, Richard Weinberger wrote: > Of course we could stay with latin and name it: UBIUBI. ubiubi is latin > for: where the heck is it, but I guess that's stretching it a bit :) Digging more in my fading away latin: ubivis == everywhere UBIVIS == Unsorted Block Images Velocity Index System
diff --git a/drivers/mtd/ubi/ubi-media.h b/drivers/mtd/ubi/ubi-media.h index 6fb8ec2..45f2b7b 100644 --- a/drivers/mtd/ubi/ubi-media.h +++ b/drivers/mtd/ubi/ubi-media.h @@ -375,4 +375,85 @@ struct ubi_vtbl_record { __be32 crc; } __packed; +#ifdef CONFIG_MTD_UBI_CHECKPOINT +#define UBI_CP_SB_VOLUME_ID (UBI_LAYOUT_VOLUME_ID + 1) +#define UBI_CP_DATA_VOLUME_ID (UBI_CP_SB_VOLUME_ID + 1) + +/* Checkoint format version */ +#define UBI_CP_FMT_VERSION 1 + +#define UBI_CP_MAX_START 64 +#define UBI_CP_MAX_BLOCKS 32 +#define UBI_CP_MAX_POOL_SIZE 128 +#define UBI_CP_SB_MAGIC 0x7B11D69F +#define UBI_CP_HDR_MAGIC 0xD4B82EF7 +#define UBI_CP_VHDR_MAGIC 0xFA370ED1 +#define UBI_CP_LPOOL_MAGIC 0x67AF4D08 +#define UBI_CP_SPOOL_MAGIC 0x67AF4D09 +#define UBI_CP_UPOOL_MAGIC 0x67AF4D0A + +struct ubi_cp_sb { + __be32 magic; + __u8 version; + __be32 data_crc; + __be32 nblocks; + __be32 block_loc[UBI_CP_MAX_BLOCKS]; + __be32 block_ec[UBI_CP_MAX_BLOCKS]; + __be64 sqnum; +} __packed; + +/* first entry in the checkpoint (cp) data set */ +struct ubi_cp_hdr { + __be32 magic; + __be32 nfree; + __be32 nused; + __be32 nvol; +} __packed; + +/* struct ubi_cp_hdr is followed by exactly three struct ub_cp_pool_* records + * long, short and unknown pool */ + +struct ubi_cp_long_pool { + __be32 magic; + __be32 size; + __be32 pebs[UBI_CP_MAX_POOL_SIZE]; +} __packed; + +struct ubi_cp_short_pool { + __be32 magic; + __be32 size; + __be32 pebs[UBI_CP_MAX_POOL_SIZE]; +} __packed; + +struct ubi_cp_unk_pool { + __be32 magic; + __be32 size; + __be32 pebs[UBI_CP_MAX_POOL_SIZE]; +} __packed; + +/* struct ub_cp_pool is followed by nfree+nused struct ubi_cp_ec records */ + +/* erase counter per peb */ +struct ubi_cp_ec { + __be32 pnum; + __be32 ec; +} __packed; + +/* identifies the start of a eba table */ +struct ubi_cp_volhdr { + __be32 magic; + __be32 vol_id; + __u8 vol_type; + __be32 data_pad; + __be32 used_ebs; + __be32 last_eb_bytes; +} __packed; + +/* struct ubi_cp_volhdr is followed by nused struct ubi_cp_eba records */ + +struct ubi_cp_eba { + __be32 lnum; + __be32 pnum; +} __packed; +#endif /* CONFIG_MTD_UBI_CHECKPOINT */ #endif /* !__UBI_MEDIA_H__ */
Specify the on-chip checkpoint layout. The checkpoint consists of two major parts. A super block (identified via UBI_CP_SB_VOLUME_ID) and zero or more data blocks (identified via UBI_CP_DATA_VOLUME_ID). Data blocks are only used if whole checkpoint information does not fit into the super block. Currently UBI_CP_MAX_START, UBI_CP_MAX_BLOCKS and UBI_CP_MAX_POOL_SIZE are hard-coded. In future this values may be configurable via Kconfig or sysfs. All three checkpointing pools have the same size for now, this my also change. An automatic calibration would be also nice to have. Signed-off-by: Richard Weinberger <rw@linutronix.de> --- drivers/mtd/ubi/ubi-media.h | 81 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 81 insertions(+), 0 deletions(-)