Re: [PATCH v6 2/3] ubi-utils: Add ubiblkvol tool

[Ezequiel Garcia <ezequiel.garcia@free-electrons.com>]

On Tue, Feb 18, 2014 at 09:54:40AM +0200, Artem Bityutskiy wrote:
> On Sun, 2014-02-16 at 17:04 -0300, Ezequiel Garcia wrote:
> > With the addition of block device access to UBI volumes, we now
> > add a simple userspace tool to access the new ioctls.
> 
> I noticed you call this driver "block device access to UBI volumes" or
> even "block device interface of UBI volumes". I am not sure we picked
> the best terminology.

Yes, given we've shaped this more like a new UBI feature, than a standalone
driver, I tried to move away from the "ubiblock driver" wording.

> Could we please discuss this a bit. Here are my
> thoughts.
> 

Sure.

> Essentially, what you have implemented is a R/O block driver. This
> driver works on top of UBI volumes. It uses simple "1-to-1" mapping,
> which is basically its media format.
> 

So far, so good.

> Someone, in theory, may implement a more sophisticated block driver
> which would be an R/W driver with good random I/O performance. This
> driver would not use 1-to-1 mapping. It would have internal block
> mapping tables, and garbage-collector.
> 

Indeed. I've been playing with that idea, but (as we already discussed)
this simpler implementation is already interesting enough.

> There may be multiple drivers like this implemented.
> 

Well, I thought the above as future improvements of the current proposal.
But I guess we can't know in advance, how are they going to be like.

> These multiple drivers would have the same user interface - the block
> API. But very different implementation, and different incompatible media
> format.
> 
> What would be our terminology then, I wonder. What do yo think:
> 
> * If your driver is ubiblock, how would those be called, any idea?
> * How would we distinguish between them when doing 'modprobe' ?o

I'm not sure about any of these.

Are you thinking in having multiple block emulation implementations living
together using this same design; i.e. all being part of the UBI driver?

I'm not sure that would be sane. I'm more inclined towards improvements of
the current code. Is this idea too narrow-minded?

> * How would we specify which one to use when using "ubiblkvol" ?
>

Supposing we have several options, I guess a parameter will do.

> BTW, I am not sure "ubiblkvol" is a good name, may be you have other
> ideas? Absent better ideas, may be calling it 'ubiblock' would be
> better, just like the name of the driver? This would at least use less
> of the "namespace".
> 

Yes, could be. "ubiblock" looks a bit cleaner.
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com