mtd->size revisited

[Vernon Sauder]

Bruce_Leonard at selinc.com wrote:
> I know that just changing it isn't all that's involved.  I've alredy gone 
> through some of the pain of changing 32-bit division to 64-bit shifts and 
> masks.  A larger concern of mine is ripple effects.  I know that this 
> field is referenced in a lot of places, most of which are pretty benign, 
> and others that are less so.  A good example is in .../mtd/mtdblock.c 
> where this happens: dev->size = mtd->size >> 9.  I don't know right off 
> the top of my head what struct mtd_blktrans_dev->size is used for, but I 
> can pretty well bet that a 64-bit value shifted right by nine ain't gonna 
> fit.  So then this ripples into making changes to mtd_blktrans_dev.  Wow. 
> This could end up going a long way.  Plus, I know there are a couple of 
> drivers that make use of this field and I expect that if I make this 
> change, I'll be responsible for makeing the changes to the drivers. 
> However, I can't test those changes since I don't have the HW.  How is 
> that going to be received by the community and the maintainers of those 
> drivers?
>
> So, as I said, I'm willing to tackle this, but I need to get a sense of 
> how long it's going to take me.  I need an idea of how long it would take 
> someone with experiance with MTD and I can then translate that (roughly :) 
>  ) into how long it should take me.  I also need guidence on how to deal 
> with things that I can't test.
>
> Thanks for any help and direction.
>
> Bruce
>   

While I agree that it would be great to support larger devices, I'm 
going to ask a dumb question: does this have to grow to a 64-bit number? 
Can it be in KB or something? If device sizes are always divisible by 
1KB, we don't need the bottom 10 bits anyway. That would seem an easier 
change in some ways.

Vern