Message ID | CAPcyv4jA-_Wd4S6gM2jf_VhVsgsdR5rQTeAc3AEPr6SAvhq3eA@mail.gmail.com (mailing list archive) |
---|---|
State | Mainlined |
Commit | eede2b9b3fe01168940bb42ff3ab502ef5f6375c |
Headers | show |
Series | [GIT,PULL] libnvdimm for v5.8-rc2 | expand |
On Fri, Jun 19, 2020 at 3:07 PM Dan Williams <dan.j.williams@intel.com> wrote: > > These patches are tied to specific features that were committed to > customers in upcoming distros releases (RHEL and SLES) whose time-lines > are tied to 5.8 kernel release. Ugh. I'd have much preferred to see this during the merge window, but the code looks straightforward and harmless enough. Linus
The pull request you sent on Fri, 19 Jun 2020 15:07:04 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/libnvdimm-for-5.8-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/eede2b9b3fe01168940bb42ff3ab502ef5f6375c
Thank you!
Dan Williams <dan.j.williams@intel.com> writes: > Hi Linus, please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm > tags/libnvdimm-for-5.8-rc2 > > ...to receive a feature (papr_scm health retrieval) and a fix (sysfs > attribute visibility) for v5.8. > > Vaibhav explains in the merge commit below why missing v5.8 would be > painful and I agreed to try a -rc2 pull because only cosmetics kept > this out of -rc1 and his initial versions were posted in more than > enough time for v5.8 consideration. > > === > These patches are tied to specific features that were committed to > customers in upcoming distros releases (RHEL and SLES) whose time-lines > are tied to 5.8 kernel release. > > Being able to track the health of an nvdimm is critical for our > customers that are running workloads leveraging papr-scm nvdimms. > Missing the 5.8 kernel would mean missing the distro timelines and > shifting forward the availability of this feature in distro kernels by > at least 6 months. > === > > I notice that these do not have an ack from Michael, but I had been > assuming that he was deferring this to a libnvdimm subsystem decision > ever since v7 back at the end of May where he said "I don't have > strong opinions about the user API, it's really up to the nvdimm > folks." [1] Yeah, sorry for not providing an actual ack, I didn't realise you were planning to send it for 5.8. The arch parts of that series are pretty boring plumbing of hypervisor calls, so the important details were all the libnvdimm related issues IMO. So please consider this a belated ack and thanks for getting it merged. cheers