All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: dedekind@infradead.org
Cc: Frank Haverkamp <haver@vnet.ibm.com>,
	linux-mtd@lists.infradead.org,
	Andreas Arnez <arnez@linux.vnet.ibm.com>
Subject: Re: [PATCH 4/5] UBI: introduce attach ioctls
Date: Wed, 19 Dec 2007 16:57:23 +0100	[thread overview]
Message-ID: <200712191657.24027.arnd@arndb.de> (raw)
In-Reply-To: <1198075329.18962.70.camel@sauron>

On Wednesday 19 December 2007, 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;
> > > +       int32_t mtd_num;
> > > +       uint8_t padding[12];
> > >  };
> > 
> > Can you explain why you need to pass vid_hdr_offset /and/ data_offset here?
> > What is the difference between the two? 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.
> 
> We can autoprobe the VID header offset, unless the MTD device is empty,
> in which case UBI automatically formats it.

ok, thanks for the explanation.

> > 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.
> 
> If the MTD device is already UBI-formatted, the numbers may be read from
> the media. Otherwise, not.

Ok, let me suggest an idea, it probably needs more refinement, but maybe we
can come up with something better based on this:

You can have a simple attribute named 'ubi-probe' in each MTD device in sysfs.
this is only readable, and contains either '0' or '1' in ascii, telling you
whether a UBI device could be found for this device.
This only works for UBI formatted media, and the kernel does not format the
media itself.
IF you want to UBI-format a medium, use a user space tool that writes the
appropriate blocks directly to the /dev/mtd* character device.

	Arnd <><

  reply	other threads:[~2007-12-19 15:59 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 [this message]
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
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=200712191657.24027.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=arnez@linux.vnet.ibm.com \
    --cc=dedekind@infradead.org \
    --cc=haver@vnet.ibm.com \
    --cc=linux-mtd@lists.infradead.org \
    /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.