Re: [systemd-devel] [ANNOUNCE] systemd 214
On Thu, 12.06.14 03:36, Cameron Norman (camerontnor...@gmail.com) wrote: El Wed, 11 de Jun 2014 a las 10:00 AM, Lennart Poettering lenn...@poettering.net escribió: Hi! http://www.freedesktop.org/software/systemd/systemd-214.tar.xz Here it is, version 214. Stuffed with great new features, improvements in all areas, 1 I would think that removing m from the documentation entirely would make it hard for people looking at old tmpfile configurations to understand what m does. Why not keep it in the docs, but clearly mark it as deprecated? Well, it's how we have done things so far. It's a balance between keeping things minimal+simple and trying to cover all the history of our codebase in the docs. I tend to prefer the former (however, making this changes clear in NEWS files), but I can see how others might prefer the latter. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 214
On Wed, Jun 11, 2014 at 8:49 PM, Alexander E. Patrakov patra...@gmail.com wrote: 11.06.2014 23:00, Lennart Poettering wrote: CHANGES WITH 214: * As an experimental feature, udev now tries to lock the disk device node (flock(LOCK_SH|LOCK_NB)) while it executes events for the disk or any of its partitions. Applications like partitioning programs can lock the disk device node (flock(LOCK_EX)) and claim temporary device ownership that way; udev will entirely skip all event handling for this disk and its partitions. If the disk was opened for writing, the close will trigger a partition table rescan in udev's watch facility, and if needed synthesize change events for the disk and all its partitions. This is now unconditionally enabled, if it turns out to cause major problems, we might turn it on only for specific devices, or might need to disable it entirely. Device-mapper devices are excluded from this logic. If we have one exception, I think it is safe to ask another: all block devices starting with zram. The reason is documented at http://lists.freedesktop.org/archives/systemd-devel/2014-June/019838.html : it breaks a (mis-?)documented way to integrate zram swap and systemd. Not so fast, the issue needs to be investigated and explained first. It is known why device-mapper cannot work with devices which are open()ed. By looking at the kernel code, I cannot immediately see why zram's static devices would have an issue with udev opening the device. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 214
11.06.2014 23:00, Lennart Poettering wrote: CHANGES WITH 214: * As an experimental feature, udev now tries to lock the disk device node (flock(LOCK_SH|LOCK_NB)) while it executes events for the disk or any of its partitions. Applications like partitioning programs can lock the disk device node (flock(LOCK_EX)) and claim temporary device ownership that way; udev will entirely skip all event handling for this disk and its partitions. If the disk was opened for writing, the close will trigger a partition table rescan in udev's watch facility, and if needed synthesize change events for the disk and all its partitions. This is now unconditionally enabled, if it turns out to cause major problems, we might turn it on only for specific devices, or might need to disable it entirely. Device-mapper devices are excluded from this logic. If we have one exception, I think it is safe to ask another: all block devices starting with zram. The reason is documented at http://lists.freedesktop.org/archives/systemd-devel/2014-June/019838.html : it breaks a (mis-?)documented way to integrate zram swap and systemd. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 214
El Wed, 11 de Jun 2014 a las 10:00 AM, Lennart Poettering lenn...@poettering.net escribió: Hi! http://www.freedesktop.org/software/systemd/systemd-214.tar.xz Here it is, version 214. Stuffed with great new features, improvements in all areas, 1 I would think that removing m from the documentation entirely would make it hard for people looking at old tmpfile configurations to understand what m does. Why not keep it in the docs, but clearly mark it as deprecated? Awesome release, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
