[MIR] pmdk
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pmdk (Ubuntu) |
Fix Released
|
Undecided
|
Andreas Hasenack |
Bug Description
Availability: PMDK is rather new (Cosmic) and builds for amd64 (main purpose)
There also is arm code in the lib, but lacking any request as well as arm-nvdimm HW it isn't built there.
Rationale:
- There is a request to enhance qemu nvdimm support (bug 1745900) which is reasonable looking forward to the potential future with nvdimms.
- It would not be useful to a "large" part of the user base as nvdimms will be rare for a while. But huge installations might converge to them for some cases soon.
- The mentioned qemu change would make qemu (main) require libpmem1 (currently universe).
Security:
- there are no CVEs yet to prove how the projects will behave by looking at the past
- The project is rather active in general
=> http://
=> https:/
Quality assurance:
- The package builds helper tools as well as a lib "libpmem1". Both work out-of the box (if you have the HW below for more)
- no debconf questions
- Due to beign so recent we have no good insight on potential long term bugs, obviously thre are none atm.
- Bug trackers are clear, but mostly due to being new
=> https:/
(Well maintained in Ubuntu; not in Debian)
- the nature of this package is to support nvdimms which are still rare HW, so not everybody can easily test these things completely. IMHO to some extend we rely on our partners asking for these features.
- Unit tests exist and run on build
- debian/watch is in place
- no obsolete or demoted packages in the dependencies
UI standards:
- not a UI package
Dependencies:
- The libs don't have a lot of runtime dependencies and for now it seems we only want to pull in libpmem1 (not all the others, but that might change with more adoption of that code)
- The associated pmdk-tools would imply further MIRs on src:libfabric and src:ndctl which we are currently not intending to push
Standards compliance:
- follows FHS rules
- is under rather new standards 4.1.5
Maintenance:
- maintained by the server Team (atm in universe)
- ownign team would be the ubuntu-server Team
Background information:
persistent memory can be hard, this library abstracts special differences in CPUs/Architectu
Applications that want to use pmem/nvdimm should use PMDK instead of re-implementing things everywhere with the same mistakes.
Related branches
- Rafael David Tinoco (community): Approve
- Canonical Server packageset reviewers: Pending requested
- Canonical Server: Pending requested
-
Diff: 5913 lines (+5016/-118)30 files modifieddebian/binfmt-update-in (+4/-6)
debian/changelog (+3485/-0)
debian/control (+94/-25)
debian/control-in (+93/-21)
debian/kvm.arm32 (+2/-0)
debian/kvm.arm64 (+2/-0)
debian/kvm.powerpc (+13/-0)
debian/kvm.s390x (+2/-0)
debian/kvm.x86 (+1/-1)
debian/not-installed (+4/-0)
debian/patches/lp-1859527-virtio-blk-fix-out-of-bounds-access-to-bitmap-in-not.patch (+43/-0)
debian/patches/series (+10/-0)
debian/patches/ubuntu/define-ubuntu-machine-types.patch (+633/-0)
debian/patches/ubuntu/enable-svm-by-default.patch (+34/-0)
debian/patches/ubuntu/expose-vmx_qemu64cpu.patch (+17/-0)
debian/patches/ubuntu/lp-1857033-i386-Add-MSR-feature-bit-for-MDS-NO.patch (+37/-0)
debian/patches/ubuntu/lp-1857033-i386-Add-macro-for-stibp.patch (+40/-0)
debian/patches/ubuntu/lp-1857033-i386-Add-new-CPU-model-Cooperlake.patch (+99/-0)
debian/patches/ubuntu/pre-bionic-256k-ipxe-efi-roms.patch (+62/-0)
debian/qemu-kvm-init (+89/-0)
debian/qemu-system-common.install (+1/-0)
debian/qemu-system-common.maintscript (+4/-0)
debian/qemu-system-common.qemu-kvm.default (+8/-0)
debian/qemu-system-common.qemu-kvm.service (+16/-0)
debian/qemu-system-data.install (+1/-1)
debian/qemu-system-x86.NEWS (+80/-0)
debian/qemu-system-x86.README.Debian (+47/-0)
debian/qemu-utils.install (+2/-0)
debian/rules (+93/-16)
dev/null (+0/-48)
Changed in pmdk (Ubuntu): | |
assignee: | nobody → Ubuntu Security Team (ubuntu-security) |
To add one more reason to do this like "now" (=early 19.04) from my personal POV.
While rare today, looking into the future I'd think the availability of nvdimms will rise.
So looking forward to 20.04 we have multiple options:
- nvdimms are a thing by then, so we better start in 19.04 to get things right until 20.04
- nvdimms are a thing by then but pmdk is crap, we realize that and can take it out of main before 20.04
- nvdimms are a thing by then and get a huge boost of interest, we better start in 19.04 to be one of the few supporting it and due to that get some of that "attention" towards Ubuntu
- nvdimms are identified to be crap, we realize that and can take it out of main before 20.04
...
This goes on, but for all of the thoughts that I had starting this in 19.04 would be the best option for our way to a great 20.04.