On 19 Dec 2012, at 10:57, Andrey Zonov wrote: >>> I think you should not MFC this one quickly -- let's wait for it to >>> shake out in the -CURRENT userbase for a few months to see what >>> breaks. I wouldn't be surprised if a fair number of applications >>> (both publicly available, and local at various FreeBSD-using shops) >>> are implicitly depending on their not being limits to memorylocked by >>> default. After an upgrade, they might find that their applications >>> simply stop working for potentially hard-to-debug reasons. >>> >>> Or we might find no one notices -- but deferring an MFC will help give >>> us a better sense of which outcome is more likely. >> >> ... or maybe this doesn't matter before your later sysctl commit? > > Yes. This change should not hurt anybody, because I change defaults for > vm.old_mlock and security.bsd.unprivileged_mlock for stable.
Very exciting indeed, then! Lots of gpg/etc users will appreciate this greatly. Robert _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
