path: root/sbin/mdconfig/mdconfig.8
diff options
authorEdward Tomasz Napierala <trasz@FreeBSD.org>2015-10-10 09:29:47 +0000
committerEdward Tomasz Napierala <trasz@FreeBSD.org>2015-10-10 09:29:47 +0000
commit92001b9497ae99ff4a5b7d4530da5440a00c4a6a (patch)
tree71f15ec0326af81711d733a2fc4503f4baed3c8c /sbin/mdconfig/mdconfig.8
parentb9a5c7b5954aac92d0b0508bc21b4ccc9a8ebd92 (diff)
Change the default setting of kern.ipc.shm_allow_removed from 0 to 1.
This removes the need for manually changing this flag for Google Chrome users. It also improves compatibility with Linux applications running under Linuxulator compatibility layer, and possibly also helps in porting software from Linux. Generally speaking, the flag allows applications to create the shared memory segment, attach it, remove it, and then continue to use it and to reattach it later. This means that the kernel will automatically "clean up" after the application exits. It could be argued that it's against POSIX. However, SUSv3 says this about IPC_RMID: "Remove the shared memory identifier specified by shmid from the system and destroy the shared memory segment and shmid_ds data structure associated with it." From my reading, we break it in any case by deferring removal of the segment until it's detached; we won't break it any more by also deferring removal of the identifier. This is the behaviour exhibited by Linux since... probably always, and also by OpenBSD since the following commit: revision 1.54 date: 2011/10/27 07:56:28; author: robert; state: Exp; lines: +3 -8; Allow segments to be used even after they were marked for deletion with the IPC_RMID flag. This is permitted as an extension beyond the standards and this is similar to what other operating systems like linux do. MFC after: 1 month Relnotes: yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D3603
Notes: svn path=/head/; revision=289112
Diffstat (limited to 'sbin/mdconfig/mdconfig.8')
0 files changed, 0 insertions, 0 deletions