Re: Implementing NVMHCI...

[Artem Bityutskiy <dedekind@infradead.org>]

On Tue, 2009-04-14 at 10:52 -0700, Jared Hulbert wrote:
>         It really isn't worth it. It's much better for everybody to
>         just be aware
>         of the incredible level of pure suckage of a general-purpose
>         disk that has
>         hardware sectors >4kB. Just educate people that it's not good.
>         Avoid the
>         whole insane suckage early, rather than be disappointed in
>         hardware that
>         is total and utter CRAP and just causes untold problems.
> 
> I don't disagree that >4KB DISKS are a bad idea. But I don't think
> that's what's going on here.  As I read it, NVMHCI would plug into the
> MTD subsystem, not the block subsystem.
> 
> 
> NVMHCI, as far as I understand the spec, is not trying to be a
> general-purpose disk, it's for exposing more or less the raw NAND.  As
> far as I can tell it's a DMA engine spec for large arrays of NAND.
> BTW, anybody actually seen a NVMHCI device or plan on making one?

I briefly glanced at the doc, and it does not look like this is an
interface to expose raw NAND. E.g., I could not find "erase" operation.
I could not find information about bad eraseblocks.

It looks like it is not about raw NANDs. May be about "managed" NANDs.

Also, the following sentences from the "Outside of Scope" sub-section
suggest I'm right:
"NVMHCI is also specified above any non-volatile memory management, like
wear leveling. Erases and other management tasks for NVM technologies
like NAND are abstracted.".

So it says NVMHCI is _above_ wear levelling, which means FTL would be
_inside_ the NVMHCI device, which is not about raw NAND.

But I may be wrong, I spent less than 10 minutes looking at the doc,
sorry.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)