Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
On Tue, Mar 12, 2019 at 04:22:35PM -0600, Alan Somers wrote: > On Tue, Mar 12, 2019 at 4:20 PM Konstantin Belousov wrote: > > > > On Tue, Mar 12, 2019 at 03:58:31PM -0600, Alan Somers wrote: > > > On Tue, May 23, 2017 at 3:29 AM Konstantin Belousov > > > wrote: > > > > > > > > Author: kib > > > > Date: Tue May 23 09:29:05 2017 > > > > New Revision: 318736 > > > > URL: https://svnweb.freebsd.org/changeset/base/318736 > > > > > > > > Log: > > > > Commit the 64-bit inode project. > > > > > > > > Extend the ino_t, dev_t, nlink_t types to 64-bit ints. Modify > > > > struct dirent layout to add d_off, increase the size of d_fileno > > > > to 64-bits, increase the size of d_namlen to 16-bits, and change > > > > the required alignment. Increase struct statfs f_mntfromname[] and > > > > f_mntonname[] array length MNAMELEN to 1024. > > > > > > > > ABI breakage is mitigated by providing compatibility using versioned > > > > symbols, ingenious use of the existing padding in structures, and > > > > by employing other tricks. Unfortunately, not everything can be > > > > fixed, especially outside the base system. For instance, third-party > > > > APIs which pass struct stat around are broken in backward and > > > > forward incompatible ways. > > > > > > > > Kinfo sysctl MIBs ABI is changed in backward-compatible way, but > > > > there is no general mechanism to handle other sysctl MIBS which > > > > return structures where the layout has changed. It was considered > > > > that the breakage is either in the management interfaces, where we > > > > usually allow ABI slip, or is not important. > > > > > > > > Struct xvnode changed layout, no compat shims are provided. > > > > > > > > For struct xtty, dev_t tty device member was reduced to uint32_t. > > > > It was decided that keeping ABI compat in this case is more useful > > > > than reporting 64-bit dev_t, for the sake of pstat. > > > > > > > > Update note: strictly follow the instructions in UPDATING. Build > > > > and install the new kernel with COMPAT_FREEBSD11 option enabled, > > > > then reboot, and only then install new world. > > > > > > > > Credits: The 64-bit inode project, also known as ino64, started life > > > > many years ago as a project by Gleb Kurtsou (gleb). Kirk McKusick > > > > (mckusick) then picked up and updated the patch, and acted as a > > > > flag-waver. Feedback, suggestions, and discussions were carried > > > > by Ed Maste (emaste), John Baldwin (jhb), Jilles Tjoelker (jilles), > > > > and Rick Macklem (rmacklem). Kris Moore (kris) performed an initial > > > > ports investigation followed by an exp-run by Antoine Brodin > > > > (antoine). > > > > Essential and all-embracing testing was done by Peter Holm (pho). > > > > The heavy lifting of coordinating all these efforts and bringing the > > > > project to completion were done by Konstantin Belousov (kib). > > > > > > > > Sponsored by: The FreeBSD Foundation (emaste, kib) > > > > Differential revision:https://reviews.freebsd.org/D10439 > > > > > > What's the purpose of the new dirent.d_off field? I can't find any > > > code that uses it. > > It is supposed to help NFS server. They are supposed to provide directly > > the > > cookies for nfs readdir call. But it is not required, and corresponding > > code was not committed to FreeBSD fs/nfs yet. > > > > > I'm wondering if the fuse(4) module should set it > > > in order to work properly over NFS, or something. > > > > No, it is not strictly required. OTOH, there is userspace implementation > > of NFS server which seems to make use of it when available. This is why > > r340431 was done. > > Would that be unfs3 or nfs-ganesha? I might add it to my list of stuff to > test. ganesha. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
On Tue, Mar 12, 2019 at 4:20 PM Konstantin Belousov wrote: > > On Tue, Mar 12, 2019 at 03:58:31PM -0600, Alan Somers wrote: > > On Tue, May 23, 2017 at 3:29 AM Konstantin Belousov > > wrote: > > > > > > Author: kib > > > Date: Tue May 23 09:29:05 2017 > > > New Revision: 318736 > > > URL: https://svnweb.freebsd.org/changeset/base/318736 > > > > > > Log: > > > Commit the 64-bit inode project. > > > > > > Extend the ino_t, dev_t, nlink_t types to 64-bit ints. Modify > > > struct dirent layout to add d_off, increase the size of d_fileno > > > to 64-bits, increase the size of d_namlen to 16-bits, and change > > > the required alignment. Increase struct statfs f_mntfromname[] and > > > f_mntonname[] array length MNAMELEN to 1024. > > > > > > ABI breakage is mitigated by providing compatibility using versioned > > > symbols, ingenious use of the existing padding in structures, and > > > by employing other tricks. Unfortunately, not everything can be > > > fixed, especially outside the base system. For instance, third-party > > > APIs which pass struct stat around are broken in backward and > > > forward incompatible ways. > > > > > > Kinfo sysctl MIBs ABI is changed in backward-compatible way, but > > > there is no general mechanism to handle other sysctl MIBS which > > > return structures where the layout has changed. It was considered > > > that the breakage is either in the management interfaces, where we > > > usually allow ABI slip, or is not important. > > > > > > Struct xvnode changed layout, no compat shims are provided. > > > > > > For struct xtty, dev_t tty device member was reduced to uint32_t. > > > It was decided that keeping ABI compat in this case is more useful > > > than reporting 64-bit dev_t, for the sake of pstat. > > > > > > Update note: strictly follow the instructions in UPDATING. Build > > > and install the new kernel with COMPAT_FREEBSD11 option enabled, > > > then reboot, and only then install new world. > > > > > > Credits: The 64-bit inode project, also known as ino64, started life > > > many years ago as a project by Gleb Kurtsou (gleb). Kirk McKusick > > > (mckusick) then picked up and updated the patch, and acted as a > > > flag-waver. Feedback, suggestions, and discussions were carried > > > by Ed Maste (emaste), John Baldwin (jhb), Jilles Tjoelker (jilles), > > > and Rick Macklem (rmacklem). Kris Moore (kris) performed an initial > > > ports investigation followed by an exp-run by Antoine Brodin (antoine). > > > Essential and all-embracing testing was done by Peter Holm (pho). > > > The heavy lifting of coordinating all these efforts and bringing the > > > project to completion were done by Konstantin Belousov (kib). > > > > > > Sponsored by: The FreeBSD Foundation (emaste, kib) > > > Differential revision:https://reviews.freebsd.org/D10439 > > > > What's the purpose of the new dirent.d_off field? I can't find any > > code that uses it. > It is supposed to help NFS server. They are supposed to provide directly the > cookies for nfs readdir call. But it is not required, and corresponding > code was not committed to FreeBSD fs/nfs yet. > > > I'm wondering if the fuse(4) module should set it > > in order to work properly over NFS, or something. > > No, it is not strictly required. OTOH, there is userspace implementation > of NFS server which seems to make use of it when available. This is why > r340431 was done. Would that be unfs3 or nfs-ganesha? I might add it to my list of stuff to test. -Alan ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
On Tue, Mar 12, 2019 at 03:58:31PM -0600, Alan Somers wrote: > On Tue, May 23, 2017 at 3:29 AM Konstantin Belousov wrote: > > > > Author: kib > > Date: Tue May 23 09:29:05 2017 > > New Revision: 318736 > > URL: https://svnweb.freebsd.org/changeset/base/318736 > > > > Log: > > Commit the 64-bit inode project. > > > > Extend the ino_t, dev_t, nlink_t types to 64-bit ints. Modify > > struct dirent layout to add d_off, increase the size of d_fileno > > to 64-bits, increase the size of d_namlen to 16-bits, and change > > the required alignment. Increase struct statfs f_mntfromname[] and > > f_mntonname[] array length MNAMELEN to 1024. > > > > ABI breakage is mitigated by providing compatibility using versioned > > symbols, ingenious use of the existing padding in structures, and > > by employing other tricks. Unfortunately, not everything can be > > fixed, especially outside the base system. For instance, third-party > > APIs which pass struct stat around are broken in backward and > > forward incompatible ways. > > > > Kinfo sysctl MIBs ABI is changed in backward-compatible way, but > > there is no general mechanism to handle other sysctl MIBS which > > return structures where the layout has changed. It was considered > > that the breakage is either in the management interfaces, where we > > usually allow ABI slip, or is not important. > > > > Struct xvnode changed layout, no compat shims are provided. > > > > For struct xtty, dev_t tty device member was reduced to uint32_t. > > It was decided that keeping ABI compat in this case is more useful > > than reporting 64-bit dev_t, for the sake of pstat. > > > > Update note: strictly follow the instructions in UPDATING. Build > > and install the new kernel with COMPAT_FREEBSD11 option enabled, > > then reboot, and only then install new world. > > > > Credits: The 64-bit inode project, also known as ino64, started life > > many years ago as a project by Gleb Kurtsou (gleb). Kirk McKusick > > (mckusick) then picked up and updated the patch, and acted as a > > flag-waver. Feedback, suggestions, and discussions were carried > > by Ed Maste (emaste), John Baldwin (jhb), Jilles Tjoelker (jilles), > > and Rick Macklem (rmacklem). Kris Moore (kris) performed an initial > > ports investigation followed by an exp-run by Antoine Brodin (antoine). > > Essential and all-embracing testing was done by Peter Holm (pho). > > The heavy lifting of coordinating all these efforts and bringing the > > project to completion were done by Konstantin Belousov (kib). > > > > Sponsored by: The FreeBSD Foundation (emaste, kib) > > Differential revision:https://reviews.freebsd.org/D10439 > > What's the purpose of the new dirent.d_off field? I can't find any > code that uses it. It is supposed to help NFS server. They are supposed to provide directly the cookies for nfs readdir call. But it is not required, and corresponding code was not committed to FreeBSD fs/nfs yet. > I'm wondering if the fuse(4) module should set it > in order to work properly over NFS, or something. No, it is not strictly required. OTOH, there is userspace implementation of NFS server which seems to make use of it when available. This is why r340431 was done. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
On Tue, May 23, 2017 at 3:29 AM Konstantin Belousov wrote: > > Author: kib > Date: Tue May 23 09:29:05 2017 > New Revision: 318736 > URL: https://svnweb.freebsd.org/changeset/base/318736 > > Log: > Commit the 64-bit inode project. > > Extend the ino_t, dev_t, nlink_t types to 64-bit ints. Modify > struct dirent layout to add d_off, increase the size of d_fileno > to 64-bits, increase the size of d_namlen to 16-bits, and change > the required alignment. Increase struct statfs f_mntfromname[] and > f_mntonname[] array length MNAMELEN to 1024. > > ABI breakage is mitigated by providing compatibility using versioned > symbols, ingenious use of the existing padding in structures, and > by employing other tricks. Unfortunately, not everything can be > fixed, especially outside the base system. For instance, third-party > APIs which pass struct stat around are broken in backward and > forward incompatible ways. > > Kinfo sysctl MIBs ABI is changed in backward-compatible way, but > there is no general mechanism to handle other sysctl MIBS which > return structures where the layout has changed. It was considered > that the breakage is either in the management interfaces, where we > usually allow ABI slip, or is not important. > > Struct xvnode changed layout, no compat shims are provided. > > For struct xtty, dev_t tty device member was reduced to uint32_t. > It was decided that keeping ABI compat in this case is more useful > than reporting 64-bit dev_t, for the sake of pstat. > > Update note: strictly follow the instructions in UPDATING. Build > and install the new kernel with COMPAT_FREEBSD11 option enabled, > then reboot, and only then install new world. > > Credits: The 64-bit inode project, also known as ino64, started life > many years ago as a project by Gleb Kurtsou (gleb). Kirk McKusick > (mckusick) then picked up and updated the patch, and acted as a > flag-waver. Feedback, suggestions, and discussions were carried > by Ed Maste (emaste), John Baldwin (jhb), Jilles Tjoelker (jilles), > and Rick Macklem (rmacklem). Kris Moore (kris) performed an initial > ports investigation followed by an exp-run by Antoine Brodin (antoine). > Essential and all-embracing testing was done by Peter Holm (pho). > The heavy lifting of coordinating all these efforts and bringing the > project to completion were done by Konstantin Belousov (kib). > > Sponsored by: The FreeBSD Foundation (emaste, kib) > Differential revision:https://reviews.freebsd.org/D10439 What's the purpose of the new dirent.d_off field? I can't find any code that uses it. I'm wondering if the fuse(4) module should set it in order to work properly over NFS, or something. -Alan ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
On Tue, May 23, 2017 at 09:29:05AM +, Konstantin Belousov wrote: > Author: kib > Date: Tue May 23 09:29:05 2017 > New Revision: 318736 > URL: https://svnweb.freebsd.org/changeset/base/318736 > > Log: > Commit the 64-bit inode project. > > Extend the ino_t, dev_t, nlink_t types to 64-bit ints. Modify > struct dirent layout to add d_off, increase the size of d_fileno > to 64-bits, increase the size of d_namlen to 16-bits, and change > the required alignment. Increase struct statfs f_mntfromname[] and > f_mntonname[] array length MNAMELEN to 1024. > > ABI breakage is mitigated by providing compatibility using versioned > symbols, ingenious use of the existing padding in structures, and > by employing other tricks. Unfortunately, not everything can be > fixed, especially outside the base system. For instance, third-party > APIs which pass struct stat around are broken in backward and > forward incompatible ways. > > Kinfo sysctl MIBs ABI is changed in backward-compatible way, but > there is no general mechanism to handle other sysctl MIBS which > return structures where the layout has changed. It was considered > that the breakage is either in the management interfaces, where we > usually allow ABI slip, or is not important. > > Struct xvnode changed layout, no compat shims are provided. > > For struct xtty, dev_t tty device member was reduced to uint32_t. > It was decided that keeping ABI compat in this case is more useful > than reporting 64-bit dev_t, for the sake of pstat. > > Update note: strictly follow the instructions in UPDATING. Build > and install the new kernel with COMPAT_FREEBSD11 option enabled, > then reboot, and only then install new world. > > Credits: The 64-bit inode project, also known as ino64, started life > many years ago as a project by Gleb Kurtsou (gleb). Kirk McKusick > (mckusick) then picked up and updated the patch, and acted as a > flag-waver. Feedback, suggestions, and discussions were carried > by Ed Maste (emaste), John Baldwin (jhb), Jilles Tjoelker (jilles), > and Rick Macklem (rmacklem). Kris Moore (kris) performed an initial > ports investigation followed by an exp-run by Antoine Brodin (antoine). > Essential and all-embracing testing was done by Peter Holm (pho). > The heavy lifting of coordinating all these efforts and bringing the > project to completion were done by Konstantin Belousov (kib). > > Sponsored by: The FreeBSD Foundation (emaste, kib) > Differential revision: https://reviews.freebsd.org/D10439 > > Modified: > head/contrib/openbsm/libbsm/bsm_wrappers.c Hey Kostik, Did the OpenBSM changes ever make it upstream to the OpenBSM project? I'm looking through the commits of the OpenBSM project and it looks like they never did. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
> On May 24, 2017, at 09:26, Ed Maste wrote: > > On 24 May 2017 at 10:53, Pedro Giffuni wrote: >> >> There is now a bunch of coverity issues (OVERFLOW_BEFORE_WIDEN mostly) >> tied to ino64_t. At least the following CIDs are related: > > On a quick look the OVERFLOW_BEFORE_WIDEN issues are false positives > in practice: for correct operation the product must fit within 32 > bits, because inodes were previously 32 bits. However, it does seem > unusual to perform a multiplication with types that could overflow 32 > bits, and then store the result in a 64-bit variable. So it seems that > a code change to eliminate the warning is likely reasonable. Wouldn’t the proper fix be: - Check the inode value for overflow? - Cast to the smaller historical value? Or: - Widen the type for the smaller historical value to a larger value? Thanks, -Ngie PS I’d have to see how we fixed this internally at Isilon. We might have a patch kicking around for this. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
On 24 May 2017 at 10:53, Pedro Giffuni wrote: > > There is now a bunch of coverity issues (OVERFLOW_BEFORE_WIDEN mostly) > tied to ino64_t. At least the following CIDs are related: On a quick look the OVERFLOW_BEFORE_WIDEN issues are false positives in practice: for correct operation the product must fit within 32 bits, because inodes were previously 32 bits. However, it does seem unusual to perform a multiplication with types that could overflow 32 bits, and then store the result in a 64-bit variable. So it seems that a code change to eliminate the warning is likely reasonable. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
First of all, HUGE thanks to everyone involved in this project! On 05/23/17 04:29, Konstantin Belousov wrote: Author: kib Date: Tue May 23 09:29:05 2017 New Revision: 318736 URL: https://svnweb.freebsd.org/changeset/base/318736 Log: Commit the 64-bit inode project. Extend the ino_t, dev_t, nlink_t types to 64-bit ints. Modify struct dirent layout to add d_off, increase the size of d_fileno to 64-bits, increase the size of d_namlen to 16-bits, and change the required alignment. Increase struct statfs f_mntfromname[] and f_mntonname[] array length MNAMELEN to 1024. ABI breakage is mitigated by providing compatibility using versioned symbols, ingenious use of the existing padding in structures, and by employing other tricks. Unfortunately, not everything can be fixed, especially outside the base system. For instance, third-party APIs which pass struct stat around are broken in backward and forward incompatible ways. Kinfo sysctl MIBs ABI is changed in backward-compatible way, but there is no general mechanism to handle other sysctl MIBS which return structures where the layout has changed. It was considered that the breakage is either in the management interfaces, where we usually allow ABI slip, or is not important. Struct xvnode changed layout, no compat shims are provided. For struct xtty, dev_t tty device member was reduced to uint32_t. It was decided that keeping ABI compat in this case is more useful than reporting 64-bit dev_t, for the sake of pstat. Update note: strictly follow the instructions in UPDATING. Build and install the new kernel with COMPAT_FREEBSD11 option enabled, then reboot, and only then install new world. Credits: The 64-bit inode project, also known as ino64, started life many years ago as a project by Gleb Kurtsou (gleb). Kirk McKusick (mckusick) then picked up and updated the patch, and acted as a flag-waver. Feedback, suggestions, and discussions were carried by Ed Maste (emaste), John Baldwin (jhb), Jilles Tjoelker (jilles), and Rick Macklem (rmacklem). Kris Moore (kris) performed an initial ports investigation followed by an exp-run by Antoine Brodin (antoine). Essential and all-embracing testing was done by Peter Holm (pho). The heavy lifting of coordinating all these efforts and bringing the project to completion were done by Konstantin Belousov (kib). Sponsored by: The FreeBSD Foundation (emaste, kib) Differential revision: https://reviews.freebsd.org/D10439 There is now a bunch of coverity issues (OVERFLOW_BEFORE_WIDEN mostly) tied to ino64_t. At least the following CIDs are related: 977071, 977072, 977073, 977094, 977095, 977096, 1375572, 1375573, 1375574, 1375575 1375576, 1375577, 1375578, 1375579, 1375580, 1375581, 1375582, 1375584. It may take some time to shake up the issues but the change was very necessary. Thanks again! Pedro. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
On Tuesday, May 23, 2017 09:29:05 AM Konstantin Belousov wrote: > Author: kib > Date: Tue May 23 09:29:05 2017 > New Revision: 318736 > URL: https://svnweb.freebsd.org/changeset/base/318736 > > Log: > Commit the 64-bit inode project. A _big_ thanks to kib@ for driving this to completion and to gleb@ for doing a large share of the work. -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
-Original Message- > From: on behalf of Ed Maste > > Date: 2017-05-23, Tuesday at 07:16 > To: Ravi Pokala > Cc: Konstantin Belousov , "src-committ...@freebsd.org" > , "svn-src-all@freebsd.org" > , "svn-src-h...@freebsd.org" > > Subject: Re: svn commit: r318736 - in head: cddl/lib/libzfs > contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include > lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm > lib/libmi... > > On 23 May 2017 at 10:10, Ravi Pokala wrote: >> >> So then `tools/build/beinstall.sh' won't DTRT for this upgrade? > > This should be fine, because the new kernel and world get installed > into a new boot environment, not over top of the existing system. The > problem only occurs when installing a new userland while the older > kernel is still running. That's right, I'd forgotten how `beinstall.sh' did it's magic. Thanks for clarifying. -Ravi (rpokala@) ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
On Tue, 23 May 2017 16:00:46 +0200, Ed Maste wrote: On 23 May 2017 at 05:29, Konstantin Belousov wrote: Author: kib Date: Tue May 23 09:29:05 2017 New Revision: 318736 URL: https://svnweb.freebsd.org/changeset/base/318736 Update note: strictly follow the instructions in UPDATING. Build and install the new kernel with COMPAT_FREEBSD11 option enabled, then reboot, and only then install new world. There's been some confusion over this point, so let me clarify: this note refers to the regular upgrade procedure documented in UPDATING under the heading "To rebuild everything and install it on the current system". Following the regular, documented procedure is both necessary and sufficient for the ino64 change. It's mentioned explicitly here because folks often take shortcuts with updating (e.g. not rebooting), and such a shortcut will fail with the ino64 change. I read this in the commit log and my first thought was that it would help a lot of people if there was an extra entry in UPDATING mentioning the explicit need of the 'installkernel, reboot, installworld' order of the official procedure. A lot of people do not read the commits, but do follow UPDATING. BTW: The content of the commit is great work and I'm sure it will benefit future of FreeBSD! Cheers, Ronald. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
On 05/23/17 16:16, Ed Maste wrote: > On 23 May 2017 at 10:10, Ravi Pokala wrote: >> >> So then `tools/build/beinstall.sh' won't DTRT for this upgrade? > > This should be fine, because the new kernel and world get installed > into a new boot environment, not over top of the existing system. The > problem only occurs when installing a new userland while the older > kernel is still running. So people using packaged base should avoid doing a simple "pkg upgrade"(which IS a shortcut, I'm aware of that) but should upgrade the kernel package, reboot and then upgrade the rest? -- Guido Falsi ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
On 23 May 2017 at 10:10, Ravi Pokala wrote: > > So then `tools/build/beinstall.sh' won't DTRT for this upgrade? This should be fine, because the new kernel and world get installed into a new boot environment, not over top of the existing system. The problem only occurs when installing a new userland while the older kernel is still running. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
-Original Message- > From: on behalf of Ed Maste > > Date: 2017-05-23, Tuesday at 07:00 > To: Konstantin Belousov > Cc: "src-committ...@freebsd.org" , > "svn-src-all@freebsd.org" , > "svn-src-h...@freebsd.org" > Subject: Re: svn commit: r318736 - in head: cddl/lib/libzfs > contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include > lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm > lib/libmi... > > On 23 May 2017 at 05:29, Konstantin Belousov wrote: >> Author: kib >> Date: Tue May 23 09:29:05 2017 >> New Revision: 318736 >> URL: https://svnweb.freebsd.org/changeset/base/318736 >> >> Update note: strictly follow the instructions in UPDATING. Build >> and install the new kernel with COMPAT_FREEBSD11 option enabled, >> then reboot, and only then install new world. > > There's been some confusion over this point, so let me clarify: this > note refers to the regular upgrade procedure documented in UPDATING > under the heading "To rebuild everything and install it on the current > system". Following the regular, documented procedure is both necessary > and sufficient for the ino64 change. > > It's mentioned explicitly here because folks often take shortcuts with > updating (e.g. not rebooting), and such a shortcut will fail with the >ino64 change. So then `tools/build/beinstall.sh' won't DTRT for this upgrade? -Ravi (rpokala@) ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm
On 23 May 2017 at 05:29, Konstantin Belousov wrote: > Author: kib > Date: Tue May 23 09:29:05 2017 > New Revision: 318736 > URL: https://svnweb.freebsd.org/changeset/base/318736 > > Update note: strictly follow the instructions in UPDATING. Build > and install the new kernel with COMPAT_FREEBSD11 option enabled, > then reboot, and only then install new world. There's been some confusion over this point, so let me clarify: this note refers to the regular upgrade procedure documented in UPDATING under the heading "To rebuild everything and install it on the current system". Following the regular, documented procedure is both necessary and sufficient for the ino64 change. It's mentioned explicitly here because folks often take shortcuts with updating (e.g. not rebooting), and such a shortcut will fail with the ino64 change. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
