> On 4 Feb 2018, at 13.55, Matias Bjørling <m...@lightnvm.io> wrote: > > On 02/04/2018 11:37 AM, Javier Gonzalez wrote: >>> On 31 Jan 2018, at 19.24, Matias Bjørling <m...@lightnvm.io> wrote: >>> >>> On 01/31/2018 10:13 AM, Javier Gonzalez wrote: >>>>> On 31 Jan 2018, at 16.51, Matias Bjørling <m...@lightnvm.io> wrote: >>>>> >>>> I have a patches abstracting this, which I think it makes it cleaner. I >>>> can push it next week for review. I’m traveling this week. (If you want to >>>> get a glimpse I can point you to the code). >>> >>> Yes, please do. Thanks >> This is the release candidate for 2.0 support based on 4.17. I'll rebase >> on top of you 2.0 support. We'll see if all changes make it to 4.17 >> then. >> https://github.com/OpenChannelSSD/linux/tree/for-4.17/spec20 >> Javier > > Great. I look forward to be patches being cleaned up and posted. I do see > some nitpicks here and there, which we properly can take a couple of stabs at.
Sure. This is still in development; just wanted to point to the abstractions I’m thinking of so that we don’t do the same work twice. I’ll wait for posting until you do the 2.0 identify, since the old version is implemented on the first patch of this series. > One think that generally stands out to me is the "if 1.2 support", else, ... > statements. These could be structured better by having dedicated setup > functions for 1.2 and 2.0. We have this construction both in pblk and in core for address translation. Note that we need to have them separated to support multi instance and keep channels decoupled from each instance. I assume 2 if...then is cheaper than doing 2 de-references to function pointers. This is the way it is done on legacy paths in other places (e.g., non mq scsi), but I can look into how pointer functions would look like and measure the performance impact. Javier
