Re: [PATCH 1/8] lightnvm: exposed generic geometry to targets

2018-02-15 Thread Javier Gonzalez
> On 15 Feb 2018, at 02.13, Matias Bjørling wrote: > >> On 02/13/2018 03:06 PM, Javier González wrote: >> With the inclusion of 2.0 support, we need a generic geometry that >> describes the OCSSD independently of the specification that it >> implements. Otherwise, geometry

Re: [PATCH 1/8] lightnvm: exposed generic geometry to targets

2018-02-15 Thread Javier Gonzalez
> On 15 Feb 2018, at 02.13, Matias Bjørling wrote: > >> On 02/13/2018 03:06 PM, Javier González wrote: >> With the inclusion of 2.0 support, we need a generic geometry that >> describes the OCSSD independently of the specification that it >> implements. Otherwise, geometry specific code is

Re: [PATCH 1/8] lightnvm: exposed generic geometry to targets

2018-02-15 Thread Matias Bjørling
On 02/13/2018 03:06 PM, Javier González wrote: With the inclusion of 2.0 support, we need a generic geometry that describes the OCSSD independently of the specification that it implements. Otherwise, geometry specific code is required, which complicates targets and makes maintenance much more

Re: [PATCH 1/8] lightnvm: exposed generic geometry to targets

2018-02-15 Thread Matias Bjørling
On 02/13/2018 03:06 PM, Javier González wrote: With the inclusion of 2.0 support, we need a generic geometry that describes the OCSSD independently of the specification that it implements. Otherwise, geometry specific code is required, which complicates targets and makes maintenance much more

[PATCH 1/8] lightnvm: exposed generic geometry to targets

2018-02-13 Thread Javier González
With the inclusion of 2.0 support, we need a generic geometry that describes the OCSSD independently of the specification that it implements. Otherwise, geometry specific code is required, which complicates targets and makes maintenance much more difficult. This patch refactors the identify path

[PATCH 1/8] lightnvm: exposed generic geometry to targets

2018-02-13 Thread Javier González
With the inclusion of 2.0 support, we need a generic geometry that describes the OCSSD independently of the specification that it implements. Otherwise, geometry specific code is required, which complicates targets and makes maintenance much more difficult. This patch refactors the identify path