svn commit: r350816 - head/sys/netipsec
Author: ae
Date: Fri Aug 9 08:58:09 2019
New Revision: 350816
URL: https://svnweb.freebsd.org/changeset/base/350816
Log:
Add missing new line in several log messages.
PR: 239694
MFC after:1 week
Modified:
head/sys/netipsec/key.c
Modified: head/sys/netipsec/key.c
==
--- head/sys/netipsec/key.c Fri Aug 9 05:18:59 2019(r350815)
+++ head/sys/netipsec/key.c Fri Aug 9 08:58:09 2019(r350816)
@@ -284,7 +284,7 @@ key_addrprotohash(const union sockaddr_union *src,
#endif
default:
hval = 0;
- ipseclog((LOG_DEBUG, "%s: unknown address family %d",
+ ipseclog((LOG_DEBUG, "%s: unknown address family %d\n",
__func__, dst->sa.sa_family));
}
return (hval);
@@ -2039,8 +2039,8 @@ key_spdadd(struct socket *so, struct mbuf *m, const st
key_freesp(&newsp);
} else {
key_freesp(&newsp);
- ipseclog((LOG_DEBUG, "%s: a SP entry exists already.",
- __func__));
+ ipseclog((LOG_DEBUG,
+ "%s: a SP entry exists already.\n", __func__));
return (key_senderror(so, m, EEXIST));
}
}
@@ -5409,7 +5409,7 @@ key_update(struct socket *so, struct mbuf *m, const st
}
/* saidx should match with SA. */
if (key_cmpsaidx(&sav->sah->saidx, &saidx, CMP_MODE_REQID) == 0) {
- ipseclog((LOG_DEBUG, "%s: saidx mismatched for SPI %u",
+ ipseclog((LOG_DEBUG, "%s: saidx mismatched for SPI %u\n",
__func__, ntohl(sav->spi)));
key_freesav(&sav);
return key_senderror(so, m, ESRCH);
@@ -6885,14 +6885,14 @@ key_acqdone(const struct secasindex *saidx, uint32_t s
if (acq != NULL) {
if (key_cmpsaidx(&acq->saidx, saidx, CMP_EXACTLY) == 0) {
ipseclog((LOG_DEBUG,
- "%s: Mismatched saidx for ACQ %u", __func__, seq));
+ "%s: Mismatched saidx for ACQ %u\n", __func__,
seq));
acq = NULL;
} else {
acq->created = 0;
}
} else {
ipseclog((LOG_DEBUG,
- "%s: ACQ %u is not found.", __func__, seq));
+ "%s: ACQ %u is not found.\n", __func__, seq));
}
ACQ_UNLOCK();
if (acq == NULL)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350764 - head/sys/arm64/arm64
On Fri, Aug 9, 2019 at 12:57 AM Konstantin Belousov wrote: > On Thu, Aug 08, 2019 at 07:38:28PM -0600, Warner Losh wrote: > > On Thu, Aug 8, 2019, 4:59 PM Gleb Smirnoff wrote: > > > > > Hi, > > > > > > why do we need COMPAT_43 for arm64 at all? I can't imagine an > > > application that would require this compatibility. > > > > > > A more general question is how far in the future are we going > > > to carry COMPAT_43 for i386/amd64? > > > > > > > COMPAT_43 is a weird option. It's a combo of both sys calls and kernel > > behavior modifications. Before we thinned the ABIs we supported, it was > > necessary for them as well. The biggest behavior change is around > signals. > > It is weird to sort out and nobody has done the deep analysis to see what > > is truly unused and what is there for compat with Linux and other SysV > > systems... > I am not aware of any changes that COMPAT_43 provides for the signal > handling semantic, except a minor adjustment for interpretation of > zero-sized stack for sigaltstack(2). > The onstack stuff was what I was thinking about, but we also have code in sys_getpid() that returns the ppid in the second retval register, and similar things for getuid and getgid, It also allows ioctl numbers that have IOC_IN set, but size == 0 (these would otherwise return ENOTTY). It also turns on the COMPAT_OLDSOCK code which generally only kicks in when compat bits are set, but in one place it allows a shorter unix domain socket path length to be compatible unconditionally. The compatibility TTY stuff, at least is under COMPAT_43TTY, but that's purely ioctl translation code. The COMPAT_43 option indeed enables lcall 7,0 syscall entry emulation, > on both i386 and amd64. We are able to run FreeBSD 1.1.8 (i386) on amd64 > kernel in chroot this way. Since sometimes I get bug reports about this > stuff, there are some users of it. I believe it is important to be able > to run any FreeBSD binary for PR purposes, to wave the flag of excellent > binary compatibility we offer. > > COMPAT_43 is there to stay as far as there are people willing to maintain > it. There are more than one. > I think it's safe to retain on i386. amd64 is less clear to me, but I'd lean yes. All the other platforms I'd agree with gleb: why do we need it in the kernels by default (and maybe why do we need to support it at all)? Warner ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r350825 - head/stand/libsa/zfs
Author: tsoome
Date: Fri Aug 9 19:09:05 2019
New Revision: 350825
URL: https://svnweb.freebsd.org/changeset/base/350825
Log:
loader: add error check for vdev_indirect calls
We can error out due to memory allocation errors, we can not recover from
those and need to get out.
Modified:
head/stand/libsa/zfs/zfsimpl.c
Modified: head/stand/libsa/zfs/zfsimpl.c
==
--- head/stand/libsa/zfs/zfsimpl.c Fri Aug 9 12:15:23 2019
(r350824)
+++ head/stand/libsa/zfs/zfsimpl.c Fri Aug 9 19:09:05 2019
(r350825)
@@ -839,6 +839,7 @@ vdev_indirect_remap(vdev_t *vd, uint64_t offset, uint6
{
list_t stack;
spa_t *spa = vd->spa;
+ zio_t *zio = arg;
list_create(&stack, sizeof (remap_segment_t),
offsetof(remap_segment_t, rs_node));
@@ -872,6 +873,13 @@ vdev_indirect_remap(vdev_t *vd, uint64_t offset, uint6
dst_offset + inner_offset,
inner_size, arg);
+ /*
+* vdev_indirect_gather_splits can have memory
+* allocation error, we can not recover from it.
+*/
+ if (zio->io_error != 0)
+ break;
+
rs->rs_offset += inner_size;
rs->rs_asize -= inner_size;
rs->rs_split_offset += inner_size;
@@ -879,6 +887,8 @@ vdev_indirect_remap(vdev_t *vd, uint64_t offset, uint6
free(mapping);
free(rs);
+ if (zio->io_error != 0)
+ break;
}
list_destroy(&stack);
@@ -935,6 +945,8 @@ vdev_indirect_read(vdev_t *vdev, const blkptr_t *bp, v
}
vdev_indirect_remap(vdev, offset, bytes, &zio);
+ if (zio.io_error != 0)
+ return (zio.io_error);
first = list_head(&iv->iv_splits);
if (first->is_size == zio.io_size) {
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r350826 - in head/lib/libthr/arch/powerpc: . include powerpc
Author: bdragon Date: Fri Aug 9 20:16:38 2019 New Revision: 350826 URL: https://svnweb.freebsd.org/changeset/base/350826 Log: Implement _umtx_op_err.S on powerpc / powerpc64. As per r177853, we need to avoid using errno inside user mutex code, since signal handlers can interfere with it and mess up libthr internal state. So, implement _umtx_op_err() instead, which makes a raw syscall and returns the error value directly instead of using errno. Approved by: jhibbits (mentor) Differential Revision: https://reviews.freebsd.org/D20946 Added: head/lib/libthr/arch/powerpc/Makefile.inc (contents, props changed) head/lib/libthr/arch/powerpc/powerpc/ head/lib/libthr/arch/powerpc/powerpc/_umtx_op_err.S (contents, props changed) Modified: head/lib/libthr/arch/powerpc/include/pthread_md.h Added: head/lib/libthr/arch/powerpc/Makefile.inc == --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/lib/libthr/arch/powerpc/Makefile.inc Fri Aug 9 20:16:38 2019 (r350826) @@ -0,0 +1,3 @@ +# $FreeBSD$ + +SRCS+= _umtx_op_err.S Modified: head/lib/libthr/arch/powerpc/include/pthread_md.h == --- head/lib/libthr/arch/powerpc/include/pthread_md.h Fri Aug 9 19:09:05 2019(r350825) +++ head/lib/libthr/arch/powerpc/include/pthread_md.h Fri Aug 9 20:16:38 2019(r350826) @@ -91,4 +91,6 @@ _get_curthread(void) return (NULL); } +#defineHAS__UMTX_OP_ERR1 + #endif /* _PTHREAD_MD_H_ */ Added: head/lib/libthr/arch/powerpc/powerpc/_umtx_op_err.S == --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/lib/libthr/arch/powerpc/powerpc/_umtx_op_err.S Fri Aug 9 20:16:38 2019(r350826) @@ -0,0 +1,41 @@ +/*- + * SPDX-License-Identifier: BSD-2-Clause-FreeBSD + * + * Copyright (c) 2019 Brandon Bergren + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +#include + + .text + .align 2 +ENTRY(_umtx_op_err) + li %r0, SYS__umtx_op + sc + blr +END(_umtx_op_err) + + .section .note.GNU-stack,"",%progbits ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350764 - head/sys/arm64/arm64
On Fri, Aug 09, 2019 at 10:01:31AM -0600, Warner Losh wrote: > On Fri, Aug 9, 2019 at 12:57 AM Konstantin Belousov > wrote: > > > On Thu, Aug 08, 2019 at 07:38:28PM -0600, Warner Losh wrote: > > > On Thu, Aug 8, 2019, 4:59 PM Gleb Smirnoff wrote: > > > > > > > Hi, > > > > > > > > why do we need COMPAT_43 for arm64 at all? I can't imagine an > > > > application that would require this compatibility. > > > > > > > > A more general question is how far in the future are we going > > > > to carry COMPAT_43 for i386/amd64? > > > > > > > > > > COMPAT_43 is a weird option. It's a combo of both sys calls and kernel > > > behavior modifications. Before we thinned the ABIs we supported, it was > > > necessary for them as well. The biggest behavior change is around > > signals. > > > It is weird to sort out and nobody has done the deep analysis to see what > > > is truly unused and what is there for compat with Linux and other SysV > > > systems... > > I am not aware of any changes that COMPAT_43 provides for the signal > > handling semantic, except a minor adjustment for interpretation of > > zero-sized stack for sigaltstack(2). > > > > The onstack stuff was what I was thinking about, but we also have code in > sys_getpid() that returns the ppid in the second retval register, and > similar things for getuid and getgid, It also allows ioctl numbers that > have IOC_IN set, but size == 0 (these would otherwise return ENOTTY). It > also turns on the COMPAT_OLDSOCK code which generally only kicks in when > compat bits are set, but in one place it allows a shorter unix domain > socket path length to be compatible unconditionally. The compatibility TTY > stuff, at least is under COMPAT_43TTY, but that's purely ioctl translation > code. I only reacted to the note about changing the signals syscalls behavior. But the point is valid, we should not change the syscalls ABI for new binaries when COMPAT_43 is enabled. I propose the following https://reviews.freebsd.org/D21200 WRT ioctl code for no IOC_OUT and size == 0, I believe that this is in fact cannot be changed. It is enabled also under COMPAT_FREEBSD4 and 5, and we always enable these for GENERIC. So effectively this ioctl permissive mode is always there. > > The COMPAT_43 option indeed enables lcall 7,0 syscall entry emulation, > > on both i386 and amd64. We are able to run FreeBSD 1.1.8 (i386) on amd64 > > kernel in chroot this way. Since sometimes I get bug reports about this > > stuff, there are some users of it. I believe it is important to be able > > to run any FreeBSD binary for PR purposes, to wave the flag of excellent > > binary compatibility we offer. > > > > COMPAT_43 is there to stay as far as there are people willing to maintain > > it. There are more than one. > > > > I think it's safe to retain on i386. amd64 is less clear to me, but I'd > lean yes. I believe amd64 is required since you have less and less chances to usefully run i386 kernel on modern hardware. > All the other platforms I'd agree with gleb: why do we need it in > the kernels by default (and maybe why do we need to support it at all)? > > Warner ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350764 - head/sys/arm64/arm64
> On Fri, Aug 09, 2019 at 10:01:31AM -0600, Warner Losh wrote: > > On Fri, Aug 9, 2019 at 12:57 AM Konstantin Belousov > > wrote: > > > > > On Thu, Aug 08, 2019 at 07:38:28PM -0600, Warner Losh wrote: > > > > On Thu, Aug 8, 2019, 4:59 PM Gleb Smirnoff wrote: > > > > > > > > > Hi, > > > > > > > > > > why do we need COMPAT_43 for arm64 at all? I can't imagine an > > > > > application that would require this compatibility. > > > > > > > > > > A more general question is how far in the future are we going > > > > > to carry COMPAT_43 for i386/amd64? > > > > > > > > > > > > > COMPAT_43 is a weird option. It's a combo of both sys calls and kernel > > > > behavior modifications. Before we thinned the ABIs we supported, it was > > > > necessary for them as well. The biggest behavior change is around > > > signals. > > > > It is weird to sort out and nobody has done the deep analysis to see > > > > what > > > > is truly unused and what is there for compat with Linux and other SysV > > > > systems... > > > I am not aware of any changes that COMPAT_43 provides for the signal > > > handling semantic, except a minor adjustment for interpretation of > > > zero-sized stack for sigaltstack(2). > > > > > > > The onstack stuff was what I was thinking about, but we also have code in > > sys_getpid() that returns the ppid in the second retval register, and > > similar things for getuid and getgid, It also allows ioctl numbers that > > have IOC_IN set, but size == 0 (these would otherwise return ENOTTY). It > > also turns on the COMPAT_OLDSOCK code which generally only kicks in when > > compat bits are set, but in one place it allows a shorter unix domain > > socket path length to be compatible unconditionally. The compatibility TTY > > stuff, at least is under COMPAT_43TTY, but that's purely ioctl translation > > code. > I only reacted to the note about changing the signals syscalls behavior. > But the point is valid, we should not change the syscalls ABI for new > binaries when COMPAT_43 is enabled. I propose the following > https://reviews.freebsd.org/D21200 > > WRT ioctl code for no IOC_OUT and size == 0, I believe that this is in > fact cannot be changed. It is enabled also under COMPAT_FREEBSD4 and > 5, and we always enable these for GENERIC. So effectively this ioctl > permissive mode is always there. > > > > > The COMPAT_43 option indeed enables lcall 7,0 syscall entry emulation, > > > on both i386 and amd64. We are able to run FreeBSD 1.1.8 (i386) on amd64 > > > kernel in chroot this way. Since sometimes I get bug reports about this > > > stuff, there are some users of it. I believe it is important to be able > > > to run any FreeBSD binary for PR purposes, to wave the flag of excellent > > > binary compatibility we offer. > > > > > > COMPAT_43 is there to stay as far as there are people willing to maintain > > > it. There are more than one. > > > > > > > I think it's safe to retain on i386. amd64 is less clear to me, but I'd > > lean yes. > I believe amd64 is required since you have less and less chances to usefully > run i386 kernel on modern hardware. Would this also be required for running i386 binaries on amd64 using lib32 that expect the COMPAT_43 behavior? > > All the other platforms I'd agree with gleb: why do we need it in > > the kernels by default (and maybe why do we need to support it at all)? > > > > Warner -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350764 - head/sys/arm64/arm64
On Fri, Aug 09, 2019 at 02:29:49PM -0700, Rodney W. Grimes wrote: > > On Fri, Aug 09, 2019 at 10:01:31AM -0600, Warner Losh wrote: > > > On Fri, Aug 9, 2019 at 12:57 AM Konstantin Belousov > > > wrote: > > > > > > > On Thu, Aug 08, 2019 at 07:38:28PM -0600, Warner Losh wrote: > > > > > On Thu, Aug 8, 2019, 4:59 PM Gleb Smirnoff > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > why do we need COMPAT_43 for arm64 at all? I can't imagine an > > > > > > application that would require this compatibility. > > > > > > > > > > > > A more general question is how far in the future are we going > > > > > > to carry COMPAT_43 for i386/amd64? > > > > > > > > > > > > > > > > COMPAT_43 is a weird option. It's a combo of both sys calls and kernel > > > > > behavior modifications. Before we thinned the ABIs we supported, it > > > > > was > > > > > necessary for them as well. The biggest behavior change is around > > > > signals. > > > > > It is weird to sort out and nobody has done the deep analysis to see > > > > > what > > > > > is truly unused and what is there for compat with Linux and other SysV > > > > > systems... > > > > I am not aware of any changes that COMPAT_43 provides for the signal > > > > handling semantic, except a minor adjustment for interpretation of > > > > zero-sized stack for sigaltstack(2). > > > > > > > > > > The onstack stuff was what I was thinking about, but we also have code in > > > sys_getpid() that returns the ppid in the second retval register, and > > > similar things for getuid and getgid, It also allows ioctl numbers that > > > have IOC_IN set, but size == 0 (these would otherwise return ENOTTY). It > > > also turns on the COMPAT_OLDSOCK code which generally only kicks in when > > > compat bits are set, but in one place it allows a shorter unix domain > > > socket path length to be compatible unconditionally. The compatibility TTY > > > stuff, at least is under COMPAT_43TTY, but that's purely ioctl translation > > > code. > > I only reacted to the note about changing the signals syscalls behavior. > > But the point is valid, we should not change the syscalls ABI for new > > binaries when COMPAT_43 is enabled. I propose the following > > https://reviews.freebsd.org/D21200 > > > > WRT ioctl code for no IOC_OUT and size == 0, I believe that this is in > > fact cannot be changed. It is enabled also under COMPAT_FREEBSD4 and > > 5, and we always enable these for GENERIC. So effectively this ioctl > > permissive mode is always there. > > > > > > > > The COMPAT_43 option indeed enables lcall 7,0 syscall entry emulation, > > > > on both i386 and amd64. We are able to run FreeBSD 1.1.8 (i386) on > > > > amd64 > > > > kernel in chroot this way. Since sometimes I get bug reports about this > > > > stuff, there are some users of it. I believe it is important to be able > > > > to run any FreeBSD binary for PR purposes, to wave the flag of excellent > > > > binary compatibility we offer. > > > > > > > > COMPAT_43 is there to stay as far as there are people willing to > > > > maintain > > > > it. There are more than one. > > > > > > > > > > I think it's safe to retain on i386. amd64 is less clear to me, but I'd > > > lean yes. > > I believe amd64 is required since you have less and less chances to usefully > > run i386 kernel on modern hardware. > > Would this also be required for running i386 binaries on amd64 using lib32 > that expect the COMPAT_43 behavior? I do not quite understand the question. My proposed change would mostly limit effect of COMPAT_43 to a.out binaries. /usr/lib32 are ELF. I would not expect any modern (as in, ELF) binaries to require changes to the syscalls behavior from COMPAT_43. > > > > All the other platforms I'd agree with gleb: why do we need it in > > > the kernels by default (and maybe why do we need to support it at all)? > > > > > > Warner > > -- > Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r350827 - head/tests/sys/fs/fusefs
Author: brooks
Date: Fri Aug 9 23:50:57 2019
New Revision: 350827
URL: https://svnweb.freebsd.org/changeset/base/350827
Log:
Don't add -Wno-class-memaccess with older gcc.
This is a gcc 8.0+ warning which needed to be silenced on for the riscv
build. amd64-xtoolchain-gcc still uses gcc 6.4.0 and does not understand
this flag.
Reviewed by: asomers
Feedback from:imp
Differential Revision:https://reviews.freebsd.org/D21195
Modified:
head/tests/sys/fs/fusefs/Makefile
Modified: head/tests/sys/fs/fusefs/Makefile
==
--- head/tests/sys/fs/fusefs/Makefile Fri Aug 9 20:16:38 2019
(r350826)
+++ head/tests/sys/fs/fusefs/Makefile Fri Aug 9 23:50:57 2019
(r350827)
@@ -1,5 +1,7 @@
# $FreeBSD$
+.include
+
PACKAGE= tests
TESTSDIR= ${TESTSBASE}/sys/fs/fusefs
@@ -65,7 +67,10 @@ TEST_METADATA+= timeout=10
FUSEFS=${SRCTOP}/sys/fs/fuse
MOUNT= ${SRCTOP}/sbin/mount
# Suppress warnings that GCC generates for the libc++ and gtest headers.
-CXXWARNFLAGS.gcc+= -Wno-placement-new -Wno-attributes -Wno-class-memaccess
+CXXWARNFLAGS.gcc+= -Wno-placement-new -Wno-attributes
+.if ${COMPILER_TYPE} == "gcc" && ${COMPILER_VERSION} >= 8
+CXXWARNFLAGS+= -Wno-class-memaccess
+.endif
CXXFLAGS+= -I${SRCTOP}/tests
CXXFLAGS+= -I${FUSEFS}
CXXFLAGS+= -I${MOUNT}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350764 - head/sys/arm64/arm64
On Fri, Aug 9, 2019 at 3:05 PM Konstantin Belousov wrote: > On Fri, Aug 09, 2019 at 10:01:31AM -0600, Warner Losh wrote: > > On Fri, Aug 9, 2019 at 12:57 AM Konstantin Belousov > > > wrote: > > > > > On Thu, Aug 08, 2019 at 07:38:28PM -0600, Warner Losh wrote: > > > > On Thu, Aug 8, 2019, 4:59 PM Gleb Smirnoff > wrote: > > > > > > > > > Hi, > > > > > > > > > > why do we need COMPAT_43 for arm64 at all? I can't imagine an > > > > > application that would require this compatibility. > > > > > > > > > > A more general question is how far in the future are we going > > > > > to carry COMPAT_43 for i386/amd64? > > > > > > > > > > > > > COMPAT_43 is a weird option. It's a combo of both sys calls and > kernel > > > > behavior modifications. Before we thinned the ABIs we supported, it > was > > > > necessary for them as well. The biggest behavior change is around > > > signals. > > > > It is weird to sort out and nobody has done the deep analysis to see > what > > > > is truly unused and what is there for compat with Linux and other > SysV > > > > systems... > > > I am not aware of any changes that COMPAT_43 provides for the signal > > > handling semantic, except a minor adjustment for interpretation of > > > zero-sized stack for sigaltstack(2). > > > > > > > The onstack stuff was what I was thinking about, but we also have code in > > sys_getpid() that returns the ppid in the second retval register, and > > similar things for getuid and getgid, It also allows ioctl numbers that > > have IOC_IN set, but size == 0 (these would otherwise return ENOTTY). It > > also turns on the COMPAT_OLDSOCK code which generally only kicks in when > > compat bits are set, but in one place it allows a shorter unix domain > > socket path length to be compatible unconditionally. The compatibility > TTY > > stuff, at least is under COMPAT_43TTY, but that's purely ioctl > translation > > code. > I only reacted to the note about changing the signals syscalls behavior. > But the point is valid, we should not change the syscalls ABI for new > binaries when COMPAT_43 is enabled. I propose the following > https://reviews.freebsd.org/D21200 Glad I did the dumpster-diving grep then. I like your proposal for the same reasons you stated. WRT ioctl code for no IOC_OUT and size == 0, I believe that this is in > fact cannot be changed. It is enabled also under COMPAT_FREEBSD4 and > 5, and we always enable these for GENERIC. So effectively this ioctl > permissive mode is always there. > Yes. I also agree. And I honestly think it's OK. > > > > The COMPAT_43 option indeed enables lcall 7,0 syscall entry emulation, > > > on both i386 and amd64. We are able to run FreeBSD 1.1.8 (i386) on > amd64 > > > kernel in chroot this way. Since sometimes I get bug reports about > this > > > stuff, there are some users of it. I believe it is important to be > able > > > to run any FreeBSD binary for PR purposes, to wave the flag of > excellent > > > binary compatibility we offer. > > > > > > COMPAT_43 is there to stay as far as there are people willing to > maintain > > > it. There are more than one. > > > > > > > I think it's safe to retain on i386. amd64 is less clear to me, but I'd > > lean yes. > I believe amd64 is required since you have less and less chances to > usefully > run i386 kernel on modern hardware. > True. With your changes, enabling the option is much safer, and only drags in a minor amount of extra code. All but the most space starved users won't care at all about the delta in size. Warner > > All the other platforms I'd agree with gleb: why do we need it in > > the kernels by default (and maybe why do we need to support it at all)? > > > > Warner > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r350830 - head/sys/sparc64/conf
Author: imp Date: Sat Aug 10 04:15:36 2019 New Revision: 350830 URL: https://svnweb.freebsd.org/changeset/base/350830 Log: These are no longer a thing, remove them. We don't need to omit ep and ex from LINT since they have been removed from the tree. Modified: head/sys/sparc64/conf/NOTES Modified: head/sys/sparc64/conf/NOTES == --- head/sys/sparc64/conf/NOTES Sat Aug 10 00:02:45 2019(r350829) +++ head/sys/sparc64/conf/NOTES Sat Aug 10 04:15:36 2019(r350830) @@ -119,8 +119,6 @@ nodevicesnd_via8233 nodevice snd_via82c686 nodevice snd_vibes nodevice snd_uaudio -nodevice ep -nodevice ex # ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
