mtd_info->size again (lengthy)

[Jörn Engel]

On Wed, 11 June 2008 00:46:30 -0700, Bruce_Leonard at selinc.com wrote:
> 
> Okay, that makes sense.  I think I'm actually starting to understand some 
> of this :\.  How tied up in the block layer is the I/O scheduler?  With my 
> limited understanding, it seems that is going to be the real sticking 
> point in moving block and mtd io towards each other.  If the I/O scheduler 
> is largely decoupled from bio it may make this easier than I think.

The block io schedulers do two things.  First they implement some kind
of elevator, combining operations and reordering them for better disk
head utilization.  That is fairly useless in flash context.  Some
schedulers also add policy, like giving all process a fair share of io.
That might become useful for flash as well.

> Fortunately, I think I'm well on my way to doing that.  I've taken your 
> code snippets (okay pretty much stolen them wholesale, I hope that's okay) 
> and started makeing changes based on them.  The changes aren't really 
> radical, I don't make use of the struct fio_vec and I'm just making 
> submit_fio() a wrapper around existing NAND functions, simple stuff like 
> that for now.  That will at least get me working and maybe some proof of 
> concept.  I hope to have a patch set in the next day or two for the list 
> to look over.

Cool.  If you solve your problem, don't break anything existing and the
infrastructure allows to handle existing drivers one by one, I am happy.
Bonus points for changing existing drivers, of course.  But I think a
one-by-one migration is better than a flag-day.  If the conversion
introduces bugs to individual drivers, we can simply revert those bits
and redo them at our leasure, instead of dealing with everything at
once.

Jörn

-- 
I don't understand it. Nobody does.
-- Richard P. Feynman