From: Frank Haverkamp <haver@vnet.ibm.com>
To: dedekind@infradead.org
Cc: Arnd Bergmann <arnd@arndb.de>,
Andreas Arnez <arnez@linux.vnet.ibm.com>,
Alexander Schmidt <alexs@linux.vnet.ibm.com>,
linux-mtd@lists.infradead.org,
Thomas Gleixner <tglx@linutronix.de>,
haver@vnet.ibm.com
Subject: Re: [PATCH 4/5] UBI: introduce attach ioctls
Date: Thu, 03 Jan 2008 13:51:39 +0100 [thread overview]
Message-ID: <1199364699.7726.34.camel@august> (raw)
In-Reply-To: <1198075329.18962.70.camel@sauron>
[-- Attachment #1: Type: text/plain, Size: 3090 bytes --]
Hi Arnd and Artem,
On Wed, 2007-12-19 at 16:42 +0200, Artem Bityutskiy wrote:
> On Wed, 2007-12-19 at 15:17 +0100, Arnd Bergmann wrote:
> > > +struct ubi_attach_req {
> > > + int32_t vid_hdr_offset;
> > > + int32_t data_offset;
> > > };
> >
> > Can you explain why you need to pass vid_hdr_offset /and/ data_offset here?
> > What is the difference between the two?
Data in flash:
EC-hdr | VID-hdr | Data
-------> VID-hdr-offs
-----------------> Data-offset
> Can't you autoprobe them if you
> > have the device?
>
> vid_hdr_offset is the offset of the VID header withing an eraseblock.
> data_offs is where the data starts. We want to be able to let users
> select the VID header offset.
> Vs data offset - indeed it is redundant
> and might be dropped because UBI may just assume data starts at the next
> min. I/O unit after the VID header.
Traditionally NAND could only be written only in page-chunks e.g. 2KiB.
Thomas Gleixner introduced that subpages could be written too e.g. 512B.
In our usage example we decided, that we wanted to have the EC-hdr at
offset 0, and the VID-hdr at the end of the last subpage of page 0 in
the NAND-erase block. We wanted the data to start at a page boundary so
that e.g. JFFS2 can use the pagesize as minimum write size and not the
sub-pagesize.
Our layout:
page 0 | page 1 | ...
subpage | ... | subpage | subpage | ... | subpage | ...
EC-hdr | ... | VID-hdr | Data
Default layout (Artem, correct me if I am wrong):
page 0 | page 1 | ...
subpage | ... | subpage ... | subpage | ... | subpage | ...
EC-hdr | VID-hdr | Data
> We can autoprobe the VID header offset, unless the MTD device is empty,
> in which case UBI automatically formats it.
I do not like auto-probing the VID hdr offset. In my eyes the user
should have the flexibility to define where his VID-hdr and data start
e.g. like in our case to have influence on if data is starting on
subpage- or page-boundaries. I also think that the autoprobe feature
would add more complexity to the code.
> > The reason I'm asking is that I'd really like to make this a simple
> > attribute in sysfs, in the mtd object. The question there is what a
> > user would need to store into that attribute. The device is identified
> > implicitly already, but this looks like you still need two distint
> > integers in order to create an UBI device.
I think with our current usage calculating the data offset as next free
min-io-offset would work, although the fact that we want to store our
data at a page-offset would be done implicitly than.
I wonder which layout Thomas Gleixner and Josh Boyer are using? Would it
work to calculate the data offset in your case?
Frank
--
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher, Sitz der Gesellschaft: Böblingen,
Registergericht: Amtsgericht Stuttgart, HRB 243294
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5269 bytes --]
next prev parent reply other threads:[~2008-01-03 12:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-19 15:41 [PATCH 0/5] UBI: make UBI devices dynamic Artem Bityutskiy
2007-12-19 15:41 ` [PATCH 1/5] UBI: add UBI control device Artem Bityutskiy
2007-12-19 14:11 ` Arnd Bergmann
2007-12-19 14:31 ` Artem Bityutskiy
2007-12-19 15:51 ` Arnd Bergmann
2007-12-19 17:21 ` Artem Bityutskiy
2007-12-19 18:12 ` Artem Bityutskiy
2007-12-19 15:41 ` [PATCH 2/5] UBI: add UBI devices reference counting Artem Bityutskiy
2007-12-19 15:41 ` [PATCH 3/5] UBI: prepare attach and detach functions Artem Bityutskiy
2007-12-19 15:41 ` [PATCH 4/5] UBI: introduce attach ioctls Artem Bityutskiy
2007-12-19 14:17 ` Arnd Bergmann
2007-12-19 14:42 ` Artem Bityutskiy
2007-12-19 15:57 ` Arnd Bergmann
2007-12-19 17:41 ` Artem Bityutskiy
2007-12-20 21:34 ` Arnd Bergmann
2007-12-20 22:14 ` Josh Boyer
2007-12-21 8:43 ` Artem Bityutskiy
2008-01-03 12:51 ` Frank Haverkamp [this message]
2008-01-03 15:05 ` Arnd Bergmann
2008-01-03 15:44 ` Frank Haverkamp
2007-12-19 15:42 ` [PATCH 5/5] UBI: handle attach ioctl Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1199364699.7726.34.camel@august \
--to=haver@vnet.ibm.com \
--cc=alexs@linux.vnet.ibm.com \
--cc=arnd@arndb.de \
--cc=arnez@linux.vnet.ibm.com \
--cc=dedekind@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.