All of lore.kernel.org
 help / color / mirror / Atom feed
From: m@bjorling.me (Matias Bjørling)
Subject: [PATCH v7 1/5] lightnvm: Support for Open-Channel SSDs
Date: Wed, 02 Sep 2015 12:48:58 +0200	[thread overview]
Message-ID: <55E6D41A.5060100@bjorling.me> (raw)
In-Reply-To: <55E67218.9010701@cn.fujitsu.com>

>> +
>> +    /* register with device with a supported BM */
>> +    list_for_each_entry(bt, &nvm_bms, list) {
>> +        ret = bt->register_bm(dev);
>> +        if (ret < 0)
>> +            goto err; /* initialization failed */
>> +        if (ret > 0) {
>> +            dev->bm = bt;
>> +            break; /* successfully initialized */
>> +        }
>> +    }
>
> Why just search it from head to tail? Can user specific it
> in nvm_create_target()?

Hi Yang,

Currently only the rrpc and a couple of out of tree block managers are 
built. The register_bm only tries to find a block manager that supports 
the device, when it finds it, that  one is initialized. It is an open 
question on how we choose the right block manager, e.g. a proprietary 
and a open-source block manager is in place. Priorities might be a way 
to go? or mark certain block managers as a catch all?

Hopefully we will get away with only a single or two block managers in 
the future, so we won't have one for each type of device.

>> +
>> +    if (!ret) {
>> +        pr_info("nvm: no compatible bm was found.\n");
>> +        return 0;
>> +    }
>
> If we allow nvm_device registered with no bm, we would get
> a NULL pointer reference problem in later using.
>

Yes, definitely. In the care that happens, I envision it should be 
possible to register a block manager after a device is loaded, and then 
any outstanding devices (which does not have a registered block 
manager), will be probed again.

> As mentioned above, why we have to choose bm for nvm in nvm_register?

Without a block manager, we don't know the structure of the device and 
how to interact with it. I want to initialize that as soon as possible. 
So that layers on top can start interacting.

>
> Thanx
> Yang

WARNING: multiple messages have this Message-ID (diff)
From: "Matias Bjørling" <m@bjorling.me>
To: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>,
	hch@infradead.org, axboe@fb.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org
Cc: jg@lightnvm.io, Stephen.Bates@pmcs.com, keith.busch@intel.com,
	"Matias Bjørling" <mb@lightnvm.io>
Subject: Re: [PATCH v7 1/5] lightnvm: Support for Open-Channel SSDs
Date: Wed, 02 Sep 2015 12:48:58 +0200	[thread overview]
Message-ID: <55E6D41A.5060100@bjorling.me> (raw)
In-Reply-To: <55E67218.9010701@cn.fujitsu.com>

>> +
>> +    /* register with device with a supported BM */
>> +    list_for_each_entry(bt, &nvm_bms, list) {
>> +        ret = bt->register_bm(dev);
>> +        if (ret < 0)
>> +            goto err; /* initialization failed */
>> +        if (ret > 0) {
>> +            dev->bm = bt;
>> +            break; /* successfully initialized */
>> +        }
>> +    }
>
> Why just search it from head to tail? Can user specific it
> in nvm_create_target()?

Hi Yang,

Currently only the rrpc and a couple of out of tree block managers are 
built. The register_bm only tries to find a block manager that supports 
the device, when it finds it, that  one is initialized. It is an open 
question on how we choose the right block manager, e.g. a proprietary 
and a open-source block manager is in place. Priorities might be a way 
to go? or mark certain block managers as a catch all?

Hopefully we will get away with only a single or two block managers in 
the future, so we won't have one for each type of device.

>> +
>> +    if (!ret) {
>> +        pr_info("nvm: no compatible bm was found.\n");
>> +        return 0;
>> +    }
>
> If we allow nvm_device registered with no bm, we would get
> a NULL pointer reference problem in later using.
>

Yes, definitely. In the care that happens, I envision it should be 
possible to register a block manager after a device is loaded, and then 
any outstanding devices (which does not have a registered block 
manager), will be probed again.

> As mentioned above, why we have to choose bm for nvm in nvm_register?

Without a block manager, we don't know the structure of the device and 
how to interact with it. I want to initialize that as soon as possible. 
So that layers on top can start interacting.

>
> Thanx
> Yang

  reply	other threads:[~2015-09-02 10:48 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-07 14:29 [PATCH v7 0/5] Support for Open-Channel SSDs Matias Bjørling
2015-08-07 14:29 ` Matias Bjørling
2015-08-07 14:29 ` [PATCH v7 1/5] lightnvm: " Matias Bjørling
2015-08-07 14:29   ` Matias Bjørling
2015-08-07 14:29   ` Matias Bjørling
2015-09-02  3:50   ` Dongsheng Yang
2015-09-02  3:50     ` Dongsheng Yang
2015-09-02  3:50     ` Dongsheng Yang
2015-09-02 10:48     ` Matias Bjørling [this message]
2015-09-02 10:48       ` Matias Bjørling
2015-09-04  7:06       ` Dongsheng Yang
2015-09-04  7:06         ` Dongsheng Yang
2015-09-04  7:06         ` Dongsheng Yang
2015-09-04  8:05         ` Matias Bjørling
2015-09-04  8:05           ` Matias Bjørling
2015-09-04  8:27           ` Dongsheng Yang
2015-09-04  8:27             ` Dongsheng Yang
2015-09-04  8:49             ` Matias Bjørling
2015-09-04  8:49               ` Matias Bjørling
2015-08-07 14:29 ` [PATCH v7 2/5] lightnvm: Hybrid Open-Channel SSD RRPC target Matias Bjørling
2015-08-07 14:29   ` Matias Bjørling
2015-08-07 14:29   ` Matias Bjørling
2015-08-07 14:29 ` [PATCH v7 3/5] lightnvm: Hybrid Open-Channel SSD block manager Matias Bjørling
2015-08-07 14:29   ` Matias Bjørling
2015-08-07 14:29 ` [PATCH v7 4/5] null_nvm: Lightnvm test driver Matias Bjørling
2015-08-07 14:29   ` Matias Bjørling
2015-08-07 14:29 ` [PATCH v7 5/5] nvme: LightNVM support Matias Bjørling
2015-08-07 14:29   ` Matias Bjørling
2015-09-02  3:50 ` [PATCH v7 0/5] Support for Open-Channel SSDs Dongsheng Yang
2015-09-02  3:50   ` Dongsheng Yang
2015-09-02  3:50   ` Dongsheng Yang
2015-09-02 10:59   ` Matias Bjørling
2015-09-02 10:59     ` Matias Bjørling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55E6D41A.5060100@bjorling.me \
    --to=m@bjorling.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.