| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20140325112217.a3d34601d745ace3fbc07c0f@valinux.co.jp> Date: Tue, 25 Mar 2014 11:22:17 +0900 From: Akira Hayakawa <hayakawa@...inux.co.jp> To: device-mapper development <dm-devel@...hat.com> Cc: Matias Bjorling <m@...rling.me>, Christoph Hellwig <hch@...radead.org>, snitzer@...hat.com, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, agk@...hat.com Subject: Re: [dm-devel] [PATCH RFC v1 01/01] dm-lightnvm: An open FTL for open firmware SSDs Hi, Matias, Sorry for jumping in. I am interested in this new feature, too. > > Does it even make sense to expose the underlying devices as block > > devices? It surely would help to send this together with a driver > > that you plan to use it on top of. > > > > Agree, an underlying driver is missing. My first plan is to get a draft > firmware for the OpenSSD to be stable and expose its primitives > (read/write/erase) up through the ATA/SCSI stack. Communicating using > vendor specific codes. Exposing FTL to the host layer has potential to share mapping in cache software (or driver) and the device. The "Unified Address Space" in the slides below addresses the problem of two levels of indirection. http://www1.unine.ch/eurosys2012/posters/saxena.pdf Developing API to share mapping between driver and the device sounds interesting, too. -- Akira -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists