Re: svn commit: r362460 - in head/sys: compat/cloudabi fs/devfs kern sys
On Sun, Jun 21, 2020 at 9:35 PM Piotr P. Stefaniak wrote: > On 2020-06-21 08:51:24, Thomas Munro wrote: > >Author: tmunro > >Date: Sun Jun 21 08:51:24 2020 > >New Revision: 362460 > >URL: https://svnweb.freebsd.org/changeset/base/362460 > > > >Log: > > vfs: track sequential reads and writes separately > > This sounds great to me! Have you considered MFC-ing this? Aside from whether it's a good idea, I wasn't assuming that was going to be possible (for example "Remove ->f_label from struct file" was not marked for MFC). I'm still trying to learn about the ABI stability rules... ___ 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"
svn commit: r362478 - head
Author: kevans
Date: Mon Jun 22 03:44:01 2020
New Revision: 362478
URL: https://svnweb.freebsd.org/changeset/base/362478
Log:
Squash liblzma build race
As of r362452, liblzma depends on libmd but the buildworld build order
hadn't been amended to document the new dependency.
Reported by: jenkins via freqlabs
X-MFC-With: r362452
Modified:
head/Makefile.inc1
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Mon Jun 22 03:14:43 2020(r362477)
+++ head/Makefile.inc1 Mon Jun 22 03:44:01 2020(r362478)
@@ -2774,7 +2774,7 @@ _lib_casper= lib/libcasper
lib/libpjdlog__L: lib/libutil__L
lib/libcasper__L: lib/libnv__L
-lib/liblzma__L: lib/libthr__L
+lib/liblzma__L: lib/libmd__L lib/libthr__L
lib/libzstd__L: lib/libthr__L
_generic_libs= ${_cddl_lib} gnu/lib ${_kerberos5_lib} lib ${_secure_lib}
___
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"
svn commit: r362477 - in head: . libexec/flua tools/build
Author: freqlabs
Date: Mon Jun 22 03:14:43 2020
New Revision: 362477
URL: https://svnweb.freebsd.org/changeset/base/362477
Log:
flua: add ucl library
libucl comes with a Lua library binding. Build it into flua.
This lets us parse/generate config files in the various formats supported by
libucl with flua. For example, the following script will detect the format of
an object written to stdin as one of UCL config, JSON, or YAML and write it to
stdout as pretty-printed JSON:
local ucl = require('ucl')
local parser = ucl.parser()
parser:parse_string(io.read('*a'))
local obj = parser:get_object()
print(ucl.to_format(obj, 'json'))
Reviewed by: kevans, pstef
Approved by: mmacy (mentor)
Relnotes: yes
Differential Revision:https://reviews.freebsd.org/D25009
Modified:
head/Makefile.inc1
head/libexec/flua/Makefile
head/libexec/flua/linit_flua.c
head/tools/build/Makefile
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Mon Jun 22 01:31:08 2020(r362476)
+++ head/Makefile.inc1 Mon Jun 22 03:14:43 2020(r362477)
@@ -2112,8 +2112,8 @@ ${_bt}-lib/libdwarf: ${_bt_m4_depend}
# 13.0-CURRENT cycle, thus needs to be built on -older releases and stable
# branches.
.if ${BOOTSTRAPPING} < 1300059
-${_bt}-libexec/flua: ${_bt}-lib/liblua
-_flua= lib/liblua libexec/flua
+${_bt}-libexec/flua: ${_bt}-lib/liblua ${_bt}-lib/libucl
+_flua= lib/liblua lib/libucl libexec/flua
.endif
# r245440 mtree -N support added
Modified: head/libexec/flua/Makefile
==
--- head/libexec/flua/Makefile Mon Jun 22 01:31:08 2020(r362476)
+++ head/libexec/flua/Makefile Mon Jun 22 03:14:43 2020(r362477)
@@ -32,4 +32,10 @@ CFLAGS+= -I${SRCTOP}/lib/libedit -I${SRCTOP}/contrib/l
LIBADD+= edit
.endif
+UCLSRC?= ${SRCTOP}/contrib/libucl
+.PATH: ${UCLSRC}/lua
+SRCS+= lua_ucl.c
+CFLAGS+= -I${UCLSRC}/include -I${UCLSRC}/src -I${UCLSRC}/uthash
+LIBADD+= ucl
+
.include
Modified: head/libexec/flua/linit_flua.c
==
--- head/libexec/flua/linit_flua.c Mon Jun 22 01:31:08 2020
(r362476)
+++ head/libexec/flua/linit_flua.c Mon Jun 22 03:14:43 2020
(r362477)
@@ -36,6 +36,7 @@
#include "lauxlib.h"
#include "lfs.h"
#include "lposix.h"
+#include "lua_ucl.h"
/*
** these libs are loaded by lua.c and are readily available to any Lua
@@ -59,6 +60,7 @@ static const luaL_Reg loadedlibs[] = {
{"lfs", luaopen_lfs},
{"posix.sys.stat", luaopen_posix_sys_stat},
{"posix.unistd", luaopen_posix_unistd},
+ {"ucl", luaopen_ucl},
{NULL, NULL}
};
Modified: head/tools/build/Makefile
==
--- head/tools/build/Makefile Mon Jun 22 01:31:08 2020(r362476)
+++ head/tools/build/Makefile Mon Jun 22 03:14:43 2020(r362477)
@@ -149,6 +149,7 @@ INSTALLDIR_LIST= \
lib/casper \
lib/geom \
usr/include/casper \
+ usr/include/private/ucl \
usr/include/private/zstd \
usr/lib \
usr/libexec
___
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: r362338 - in head: share/man/man4 sys/conf sys/kern sys/netinet sys/netinet6 sys/netipsec sys/netpfil/pf
On Fri, Jun 19, 2020 at 08:33:35AM -0700, John Baldwin wrote: > On 6/18/20 12:32 PM, Mark Johnston wrote: > > Author: markj > > Date: Thu Jun 18 19:32:34 2020 > > New Revision: 362338 > > URL: https://svnweb.freebsd.org/changeset/base/362338 > > > > Log: > > Add the SCTP_SUPPORT kernel option. > > > > This is in preparation for enabling a loadable SCTP stack. Analogous to > > IPSEC/IPSEC_SUPPORT, the SCTP_SUPPORT kernel option must be configured > > in order to support a loadable SCTP implementation. > > > > Discussed with: tuexen > > MFC after:2 weeks > > Sponsored by: The FreeBSD Foundation > > Do you want to add similar handling to sys/conf/config.mk that we have > for IPsec? Also, do we want to avoid building sctp.ko if it is in the > kernel like we do for ipsec.ko and/or only build it if the kernel contains > SCTP_SUPPORT? (For ipsec.ko we had to do that as it wouldn't compile, not > sure if the same is true for sctp.ko) Sorry for the delay. I think we do indeed want similar handling in config.mk, I will work on it. It is probably also reasonable to avoid compiling sctp.ko when SCTP_SUPPORT is not defined, though I can't see a reason that wouldn't work today since SCTP_SUPPORT is not used in any headers. ___ 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"
svn commit: r362474 - head/lib/libc/net
Author: tuexen
Date: Sun Jun 21 23:47:27 2020
New Revision: 362474
URL: https://svnweb.freebsd.org/changeset/base/362474
Log:
Add include missing from my last commit.
Modified:
head/lib/libc/net/sctp_sys_calls.c
Modified: head/lib/libc/net/sctp_sys_calls.c
==
--- head/lib/libc/net/sctp_sys_calls.c Sun Jun 21 23:12:56 2020
(r362473)
+++ head/lib/libc/net/sctp_sys_calls.c Sun Jun 21 23:47:27 2020
(r362474)
@@ -36,6 +36,7 @@
__FBSDID("$FreeBSD$");
#include
+#include
#include
#include
#include
___
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"
svn commit: r362473 - in head: lib/libc/net sys/netinet
Author: tuexen
Date: Sun Jun 21 23:12:56 2020
New Revision: 362473
URL: https://svnweb.freebsd.org/changeset/base/362473
Log:
Cleanup the defintion of struct sctp_getaddresses. This stucture
is used by the IPPROTO_SCTP level socket options SCTP_GET_PEER_ADDRESSES
and SCTP_GET_LOCAL_ADDRESSES, which are used by libc to implement
sctp_getladdrs() and sctp_getpaddrs().
These changes allow an old libc to work on a newer kernel.
Modified:
head/lib/libc/net/sctp_sys_calls.c
head/sys/netinet/sctp_uio.h
head/sys/netinet/sctp_usrreq.c
Modified: head/lib/libc/net/sctp_sys_calls.c
==
--- head/lib/libc/net/sctp_sys_calls.c Sun Jun 21 22:09:30 2020
(r362472)
+++ head/lib/libc/net/sctp_sys_calls.c Sun Jun 21 23:12:56 2020
(r362473)
@@ -406,7 +406,7 @@ sctp_getpaddrs(int sd, sctp_assoc_t id, struct sockadd
return (-1);
}
/* size required is returned in 'asoc' */
- opt_len = (socklen_t)((size_t)asoc + sizeof(sctp_assoc_t));
+ opt_len = (socklen_t)((size_t)asoc + sizeof(struct sctp_getaddresses));
addrs = calloc(1, (size_t)opt_len);
if (addrs == NULL) {
errno = ENOMEM;
@@ -419,9 +419,9 @@ sctp_getpaddrs(int sd, sctp_assoc_t id, struct sockadd
free(addrs);
return (-1);
}
- *raddrs = (struct sockaddr *)>addr[0];
+ *raddrs = >addr[0].sa;
cnt = 0;
- sa = (struct sockaddr *)>addr[0];
+ sa = >addr[0].sa;
lim = (caddr_t)addrs + opt_len;
while (((caddr_t)sa < lim) && (sa->sa_len > 0)) {
sa = (struct sockaddr *)((caddr_t)sa + sa->sa_len);
@@ -436,7 +436,7 @@ sctp_freepaddrs(struct sockaddr *addrs)
void *fr_addr;
/* Take away the hidden association id */
- fr_addr = (void *)((caddr_t)addrs - sizeof(sctp_assoc_t));
+ fr_addr = (void *)((caddr_t)addrs - offsetof(struct sctp_getaddresses,
addr));
/* Now free it */
free(fr_addr);
}
@@ -466,7 +466,7 @@ sctp_getladdrs(int sd, sctp_assoc_t id, struct sockadd
errno = ENOTCONN;
return (-1);
}
- opt_len = (socklen_t)(size_of_addresses + sizeof(sctp_assoc_t));
+ opt_len = (socklen_t)(size_of_addresses + sizeof(struct
sctp_getaddresses));
addrs = calloc(1, (size_t)opt_len);
if (addrs == NULL) {
errno = ENOMEM;
@@ -480,9 +480,9 @@ sctp_getladdrs(int sd, sctp_assoc_t id, struct sockadd
errno = ENOMEM;
return (-1);
}
- *raddrs = (struct sockaddr *)>addr[0];
+ *raddrs = >addr[0].sa;
cnt = 0;
- sa = (struct sockaddr *)>addr[0];
+ sa = >addr[0].sa;
lim = (caddr_t)addrs + opt_len;
while (((caddr_t)sa < lim) && (sa->sa_len > 0)) {
sa = (struct sockaddr *)((caddr_t)sa + sa->sa_len);
@@ -497,7 +497,7 @@ sctp_freeladdrs(struct sockaddr *addrs)
void *fr_addr;
/* Take away the hidden association id */
- fr_addr = (void *)((caddr_t)addrs - sizeof(sctp_assoc_t));
+ fr_addr = (void *)((caddr_t)addrs - offsetof(struct sctp_getaddresses,
addr));
/* Now free it */
free(fr_addr);
}
Modified: head/sys/netinet/sctp_uio.h
==
--- head/sys/netinet/sctp_uio.h Sun Jun 21 22:09:30 2020(r362472)
+++ head/sys/netinet/sctp_uio.h Sun Jun 21 23:12:56 2020(r362473)
@@ -39,7 +39,7 @@ __FBSDID("$FreeBSD$");
#define _NETINET_SCTP_UIO_H_
-#if ! defined(_KERNEL)
+#if !defined(_KERNEL)
#include
#endif
#include
@@ -633,10 +633,15 @@ struct sctp_setpeerprim {
uint8_t sspp_padding[4];
};
+union sctp_sockstore {
+ struct sockaddr_in sin;
+ struct sockaddr_in6 sin6;
+ struct sockaddr sa;
+};
+
struct sctp_getaddresses {
sctp_assoc_t sget_assoc_id;
- /* addr is filled in for N * sockaddr_storage */
- struct sockaddr addr[1];
+ union sctp_sockstore addr[];
};
struct sctp_status {
@@ -1142,12 +1147,6 @@ struct sctpstat {
#define SCTP_STAT_DECR_COUNTER32(_x) SCTP_STAT_DECR(_x)
#define SCTP_STAT_DECR_COUNTER64(_x) SCTP_STAT_DECR(_x)
#define SCTP_STAT_DECR_GAUGE32(_x) SCTP_STAT_DECR(_x)
-
-union sctp_sockstore {
- struct sockaddr_in sin;
- struct sockaddr_in6 sin6;
- struct sockaddr sa;
-};
/***/
Modified: head/sys/netinet/sctp_usrreq.c
==
--- head/sys/netinet/sctp_usrreq.c Sun Jun 21 22:09:30 2020
(r362472)
+++ head/sys/netinet/sctp_usrreq.c Sun Jun 21 23:12:56 2020
(r362473)
@@ -989,7 +989,7 @@ sctp_shutdown(struct socket *so)
* returns 0 on success, 1 on error
*/
static uint32_t
-sctp_fill_user_address(struct sockaddr_storage *ss, struct sockaddr *sa)
svn commit: r362472 - head/sys/netinet
Author: bz Date: Sun Jun 21 22:09:30 2020 New Revision: 362472 URL: https://svnweb.freebsd.org/changeset/base/362472 Log: Rather than zeroing MAXVIFS times size of pointer [r362289] (still better than sizeof pointer before [r354857]), we need to zero MAXVIFS times the size of the struct. All good things come in threes; I hope this is it on this one. PR: 246629, 206583 Reported by: kib MFC after:ASAP Modified: head/sys/netinet/ip_mroute.c Modified: head/sys/netinet/ip_mroute.c == --- head/sys/netinet/ip_mroute.cSun Jun 21 22:02:49 2020 (r362471) +++ head/sys/netinet/ip_mroute.cSun Jun 21 22:09:30 2020 (r362472) @@ -740,7 +740,7 @@ X_ip_mrouter_done(void) if_allmulti(ifp, 0); } } -bzero((caddr_t)V_viftable, sizeof(V_viftable) * MAXVIFS); +bzero((caddr_t)V_viftable, sizeof(*V_viftable) * MAXVIFS); V_numvifs = 0; V_pim_assert_enabled = 0; ___ 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"
svn commit: r362471 - head/sys/net
Author: mmacy
Date: Sun Jun 21 22:02:49 2020
New Revision: 362471
URL: https://svnweb.freebsd.org/changeset/base/362471
Log:
iflib: fix cloneattach fail and generalize pseudo device handling
- a cloneattach failure will not currently be handled correctly,
jump to the right target
- pseudo devices are all treat as if they're ethernet devices -
this often doesn't make sense
MFC after:1 week
Sponsored by: Netgate, Inc.
Differential Revision:https://reviews.freebsd.org/D25083
Modified:
head/sys/net/iflib.c
head/sys/net/iflib.h
Modified: head/sys/net/iflib.c
==
--- head/sys/net/iflib.cSun Jun 21 20:30:11 2020(r362470)
+++ head/sys/net/iflib.cSun Jun 21 22:02:49 2020(r362471)
@@ -4874,12 +4874,8 @@ iflib_pseudo_register(device_t dev, if_shared_ctx_t sc
if ((err = IFDI_CLONEATTACH(ctx, clctx->cc_ifc, clctx->cc_name,
clctx->cc_params)) != 0) {
device_printf(dev, "IFDI_CLONEATTACH failed %d\n", err);
- goto fail_ctx_free;
+ goto fail_unlock;
}
- ifmedia_add(ctx->ifc_mediap, IFM_ETHER | IFM_1000_T | IFM_FDX, 0, NULL);
- ifmedia_add(ctx->ifc_mediap, IFM_ETHER | IFM_AUTO, 0, NULL);
- ifmedia_set(ctx->ifc_mediap, IFM_ETHER | IFM_AUTO);
-
#ifdef INVARIANTS
if (scctx->isc_capabilities & IFCAP_TXCSUM)
MPASS(scctx->isc_tx_csum_flags);
@@ -4890,7 +4886,14 @@ iflib_pseudo_register(device_t dev, if_shared_ctx_t sc
ifp->if_flags |= IFF_NOGROUP;
if (sctx->isc_flags & IFLIB_PSEUDO) {
- ether_ifattach(ctx->ifc_ifp, ctx->ifc_mac.octet);
+ ifmedia_add(ctx->ifc_mediap, IFM_ETHER | IFM_AUTO, 0, NULL);
+ ifmedia_set(ctx->ifc_mediap, IFM_ETHER | IFM_AUTO);
+ if (sctx->isc_flags & IFLIB_PSEUDO_ETHER) {
+ ether_ifattach(ctx->ifc_ifp, ctx->ifc_mac.octet);
+ } else {
+ if_attach(ctx->ifc_ifp);
+ bpfattach(ctx->ifc_ifp, DLT_NULL, sizeof(u_int32_t));
+ }
if ((err = IFDI_ATTACH_POST(ctx)) != 0) {
device_printf(dev, "IFDI_ATTACH_POST failed %d\n", err);
@@ -4913,6 +4916,10 @@ iflib_pseudo_register(device_t dev, if_shared_ctx_t sc
CTX_UNLOCK(ctx);
return (0);
}
+ ifmedia_add(ctx->ifc_mediap, IFM_ETHER | IFM_1000_T | IFM_FDX, 0, NULL);
+ ifmedia_add(ctx->ifc_mediap, IFM_ETHER | IFM_AUTO, 0, NULL);
+ ifmedia_set(ctx->ifc_mediap, IFM_ETHER | IFM_AUTO);
+
_iflib_pre_assert(scctx);
ctx->ifc_txrx = *scctx->isc_txrx;
@@ -5028,6 +5035,7 @@ int
iflib_pseudo_deregister(if_ctx_t ctx)
{
if_t ifp = ctx->ifc_ifp;
+ if_shared_ctx_t sctx = ctx->ifc_sctx;
iflib_txq_t txq;
iflib_rxq_t rxq;
int i, j;
@@ -5037,7 +5045,13 @@ iflib_pseudo_deregister(if_ctx_t ctx)
/* Unregister VLAN event handlers early */
iflib_unregister_vlan_handlers(ctx);
- ether_ifdetach(ifp);
+ if ((sctx->isc_flags & IFLIB_PSEUDO) &&
+ (sctx->isc_flags & IFLIB_PSEUDO_ETHER) == 0) {
+ bpfdetach(ifp);
+ if_detach(ifp);
+ } else {
+ ether_ifdetach(ifp);
+ }
/* XXX drain any dependent tasks */
tqg = qgroup_if_io_tqg;
for (txq = ctx->ifc_txqs, i = 0; i < NTXQSETS(ctx); i++, txq++) {
@@ -5362,13 +5376,22 @@ iflib_register(if_ctx_t ctx)
driver_t *driver = sctx->isc_driver;
device_t dev = ctx->ifc_dev;
if_t ifp;
+ u_char type;
+ int iflags;
if ((sctx->isc_flags & IFLIB_PSEUDO) == 0)
_iflib_assert(sctx);
CTX_LOCK_INIT(ctx);
STATE_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
- ifp = ctx->ifc_ifp = if_alloc(IFT_ETHER);
+ if (sctx->isc_flags & IFLIB_PSEUDO) {
+ if (sctx->isc_flags & IFLIB_PSEUDO_ETHER)
+ type = IFT_ETHER;
+ else
+ type = IFT_PPP;
+ } else
+ type = IFT_ETHER;
+ ifp = ctx->ifc_ifp = if_alloc(type);
if (ifp == NULL) {
device_printf(dev, "can not allocate ifnet structure\n");
return (ENOMEM);
@@ -5393,9 +5416,14 @@ iflib_register(if_ctx_t ctx)
if_settransmitfn(ifp, iflib_if_transmit);
#endif
if_setqflushfn(ifp, iflib_if_qflush);
- if_setflags(ifp, IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST |
- IFF_KNOWSEPOCH);
+ iflags = IFF_MULTICAST | IFF_KNOWSEPOCH;
+ if ((sctx->isc_flags & IFLIB_PSEUDO) &&
+ (sctx->isc_flags & IFLIB_PSEUDO_ETHER) == 0)
+ iflags |= IFF_POINTOPOINT;
+ else
+ iflags |= IFF_BROADCAST |
Re: svn commit: r362294 - head/sys/dev/sound/pci/hda
On Thu, Jun 18, 2020 at 06:12:06AM +, Andriy Gapon wrote:
> Author: avg
> Date: Thu Jun 18 06:12:06 2020
> New Revision: 362294
> URL: https://svnweb.freebsd.org/changeset/base/362294
>
> Log:
> hdac_intr_handler: keep working until global interrupt status clears
>
> It is plausible that the hardware interrupts a host only when GIS goes
> from zero to one. GIS is formed by OR-ing multiple hardware statuses,
> so it's possible that a previously cleared status gets set again while
> another status has not been cleared yet. Thus, there will be no new
> interrupt as GIS always stayed set. If we don't re-examine GIS then we
> can leave it set and never get another interrupt again.
>
> Without this change I frequently saw a problem where snd_hda would stop
> working. Setting dev.hdac.1.polling=1 would bring it back to life and
> afterwards I could set polling back to zero. Sometimes the problem
> started right after a boot, sometimes it happened after resuming from
> S3, frequently it would occur when sound output and input are active
> concurrently (such as during conferencing). I looked at HDAC_INTSTS
> while the sound was not working and I saw that both HDAC_INTSTS_GIS and
> HDAC_INTSTS_CIS were set, but there were no interrupts.
>
> I have collected some statistics over a period of several days about how
> many loops (calls to hdac_one_intr) the new code did for a single
> interrupt:
> ++--+
> |Loops |Times Happened|
> ++--+
> |0 |301 |
> |1 |12857746 |
> |2 |280 |
> |3 |2 |
> |4+ |0 |
> ++--+
> I believe that previously the sound would get stuck each time we had to loop
> more than once.
>
> The tested hardware is:
> hdac1: mem 0xfe68-0xfe687fff at device
> 0.6 on pci4
> hdacc1: at cad 0 on hdac1
>
> No objections: mav
> MFC after: 5 weeks
> Differential Revision: https://reviews.freebsd.org/D25128
>
> Modified:
> head/sys/dev/sound/pci/hda/hdac.c
>
> Modified: head/sys/dev/sound/pci/hda/hdac.c
> ==
> --- head/sys/dev/sound/pci/hda/hdac.c Wed Jun 17 23:41:04 2020
> (r362293)
> +++ head/sys/dev/sound/pci/hda/hdac.c Thu Jun 18 06:12:06 2020
> (r362294)
> @@ -303,30 +303,13 @@ hdac_config_fetch(struct hdac_softc *sc, uint32_t *on,
> }
> }
>
> -/
> - * void hdac_intr_handler(void *)
> - *
> - * Interrupt handler. Processes interrupts received from the hdac.
> -
> /
> static void
> -hdac_intr_handler(void *context)
> +hdac_one_intr(struct hdac_softc *sc, uint32_t intsts)
> {
> - struct hdac_softc *sc;
> device_t dev;
> - uint32_t intsts;
> uint8_t rirbsts;
> int i;
>
> - sc = (struct hdac_softc *)context;
> - hdac_lock(sc);
> -
> - /* Do we have anything to do? */
> - intsts = HDAC_READ_4(>mem, HDAC_INTSTS);
> - if ((intsts & HDAC_INTSTS_GIS) == 0) {
> - hdac_unlock(sc);
> - return;
> - }
> -
> /* Was this a controller interrupt? */
> if (intsts & HDAC_INTSTS_CIS) {
> rirbsts = HDAC_READ_1(>mem, HDAC_RIRBSTS);
> @@ -346,16 +329,45 @@ hdac_intr_handler(void *context)
> if ((intsts & (1 << i)) == 0)
> continue;
> HDAC_WRITE_1(>mem, (i << 5) + HDAC_SDSTS,
> - HDAC_SDSTS_DESE | HDAC_SDSTS_FIFOE |
> HDAC_SDSTS_BCIS );
> + HDAC_SDSTS_DESE | HDAC_SDSTS_FIFOE |
> HDAC_SDSTS_BCIS);
> if ((dev = sc->streams[i].dev) != NULL) {
> HDAC_STREAM_INTR(dev,
> sc->streams[i].dir, sc->streams[i].stream);
> }
> }
> }
> +}
>
> - HDAC_WRITE_4(>mem, HDAC_INTSTS, intsts);
> - hdac_unlock(sc);
> +/
> + * void hdac_intr_handler(void *)
> + *
> + * Interrupt handler. Processes interrupts received from the hdac.
> +
> /
> +static void
> +hdac_intr_handler(void *context)
> +{
> + struct hdac_softc *sc;
> + uint32_t intsts;
> +
> + sc = (struct hdac_softc *)context;
> +
> + /*
> + * Loop until HDAC_INTSTS_GIS gets clear.
> + * It is plausible that hardware interrupts a host only when GIS goes
> + * from zero to one. GIS is formed by OR-ing multiple hardware
> + * statuses, so it's possible that a previously cleared status gets set
> + * again while another status has not been cleared yet.
svn commit: r362470 - svnadmin/conf
Author: jrm (ports committer) Date: Sun Jun 21 20:30:11 2020 New Revision: 362470 URL: https://svnweb.freebsd.org/changeset/base/362470 Log: Retire Marcel Moolenaar's (marcel's) bit at his request Approved by: core Modified: svnadmin/conf/access Modified: svnadmin/conf/access == --- svnadmin/conf/accessSun Jun 21 20:23:39 2020(r362469) +++ svnadmin/conf/accessSun Jun 21 20:30:11 2020(r362470) @@ -126,7 +126,6 @@ lstewart luporl lwhsu manu -marcel marius markj markm ___ 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"
svn commit: r362469 - stable/12/usr.bin/top
Author: pstef
Date: Sun Jun 21 20:23:39 2020
New Revision: 362469
URL: https://svnweb.freebsd.org/changeset/base/362469
Log:
MFC r349235 (by allanjude):
top(1): Don't show the swap line when there are no swap devices
Modified:
stable/12/usr.bin/top/display.c
stable/12/usr.bin/top/machine.c
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/usr.bin/top/display.c
==
--- stable/12/usr.bin/top/display.c Sun Jun 21 18:40:17 2020
(r362468)
+++ stable/12/usr.bin/top/display.c Sun Jun 21 20:23:39 2020
(r362469)
@@ -675,6 +675,9 @@ i_swap(int *stats)
{
swap_buffer = setup_buffer(swap_buffer, 0);
+if (swap_names == NULL)
+ return;
+
fputs("\nSwap: ", stdout);
lastline++;
@@ -689,6 +692,9 @@ u_swap(int *stats)
static char *new = NULL;
new = setup_buffer(new, 0);
+
+if (swap_names == NULL)
+ return;
/* format the new line */
summary_format(new, stats, swap_names);
Modified: stable/12/usr.bin/top/machine.c
==
--- stable/12/usr.bin/top/machine.c Sun Jun 21 18:40:17 2020
(r362468)
+++ stable/12/usr.bin/top/machine.c Sun Jun 21 20:23:39 2020
(r362469)
@@ -150,6 +150,7 @@ static const char *swapnames[] = {
};
static int swap_stats[nitems(swapnames)];
+static int has_swap;
/* these are for keeping track of the proc array */
@@ -248,12 +249,12 @@ update_layout(void)
y_mem = 3;
y_arc = 4;
y_carc = 5;
- y_swap = 4 + arc_enabled + carc_enabled;
- y_idlecursor = 5 + arc_enabled + carc_enabled;
- y_message = 5 + arc_enabled + carc_enabled;
- y_header = 6 + arc_enabled + carc_enabled;
- y_procs = 7 + arc_enabled + carc_enabled;
- Header_lines = 7 + arc_enabled + carc_enabled;
+ y_swap = 3 + arc_enabled + carc_enabled + has_swap;
+ y_idlecursor = 4 + arc_enabled + carc_enabled + has_swap;
+ y_message = 4 + arc_enabled + carc_enabled + has_swap;
+ y_header = 5 + arc_enabled + carc_enabled + has_swap;
+ y_procs = 6 + arc_enabled + carc_enabled + has_swap;
+ Header_lines = 6 + arc_enabled + carc_enabled + has_swap;
if (pcpu_stats) {
y_mem += ncpus - 1;
@@ -273,7 +274,7 @@ machine_init(struct statics *statics)
{
int i, j, empty, pagesize;
uint64_t arc_size;
- int carc_en;
+ int carc_en, nswapdev;
size_t size;
size = sizeof(smpmode);
@@ -298,6 +299,11 @@ machine_init(struct statics *statics)
if (kd == NULL)
return (-1);
+ size = sizeof(nswapdev);
+ if (sysctlbyname("vm.nswapdev", , , NULL,
+ 0) == 0 && nswapdev != 0)
+ has_swap = 1;
+
GETSYSCTL("kern.ccpu", ccpu);
/* this is used in calculating WCPU -- calculate it ahead of time */
@@ -332,7 +338,10 @@ machine_init(struct statics *statics)
statics->carc_names = carcnames;
else
statics->carc_names = NULL;
- statics->swap_names = swapnames;
+ if (has_swap)
+ statics->swap_names = swapnames;
+ else
+ statics->swap_names = NULL;
statics->order_names = ordernames;
/* Allocate state for per-CPU stats. */
___
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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
> On 21 Jun 2020, at 17:41, Hans Petter Selasky wrote: > If you got a Master's degree in South Africa under Apartheid, to many people > that is still symbolic. First I've heard of it (yes, I'm South African). > https://en.wikipedia.org/wiki/Apartheid#Education > > Apartheid is not very long ago and the people that experienced this are still > alive. And many of those folks have MSc/MEng/MBA etc degrees, and are not agitating to change them. M -- signature.asc Description: Message signed with OpenPGP
svn commit: r362468 - head/sys/net
Author: kaktus Date: Sun Jun 21 18:40:17 2020 New Revision: 362468 URL: https://svnweb.freebsd.org/changeset/base/362468 Log: net.link.generic.ifdata..linkspecific: rework handler This OID was added in r17352 but the write path of IFDATA_LINKSPECIFIC seems unused as there are no in-base writers, and as far as I can tell we had issues with this code before, see PR 219472. Drop the write path to make the handler read-only as described in comments and man-pages. It can be marked as MPSAFE now. Reviewed by: bdragon, kib, melifaro, wollman Approved by: kib (mentor) Sponsored by: Mysterious Code Ltd. Differential Revision:https://reviews.freebsd.org/D25348 Modified: head/sys/net/if_mib.c Modified: head/sys/net/if_mib.c == --- head/sys/net/if_mib.c Sun Jun 21 16:06:01 2020(r362467) +++ head/sys/net/if_mib.c Sun Jun 21 18:40:17 2020(r362468) @@ -122,10 +122,6 @@ sysctl_ifdata(SYSCTL_HANDLER_ARGS) /* XXX bad syntax! error = SYSCTL_OUT(req, ifp->if_linkmib, ifp->if_linkmiblen); if (error || !req->newptr) goto out; - - error = SYSCTL_IN(req, ifp->if_linkmib, ifp->if_linkmiblen); - if (error) - goto out; break; case IFDATA_DRIVERNAME: @@ -152,6 +148,6 @@ out: } static SYSCTL_NODE(_net_link_generic, IFMIB_IFDATA, ifdata, -CTLFLAG_RW | CTLFLAG_NEEDGIANT, sysctl_ifdata, +CTLFLAG_RD | CTLFLAG_MPSAFE, sysctl_ifdata, "Interface table"); ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On Sun, Jun 21, 2020, 18:04 Hans Petter Selasky wrote: > On 2020-06-21 18:54, Alexandr Kovalenko wrote: > > On Sun, Jun 21, 2020 at 5:41 PM Hans Petter Selasky > wrote: > >> On 2020-06-21 18:11, Alexey Dokuchaev wrote: > >>> On Sun, Jun 21, 2020 at 06:01:40PM +0200, Hans Petter Selasky wrote: > On 2020-06-21 17:53, Alexandr Kovalenko wrote: > > I wonder should we also rename Master's Degree? Would you throw > > away yours? > > https://en.wiktionary.org/wiki/master > > I don't see a problem if you have a main computer degree. > >>> > >>> *facepalm* > >> > >> If you got a Master's degree in South Africa under Apartheid, to many > >> people that is still symbolic. > >> > >> https://en.wikipedia.org/wiki/Apartheid#Education > >> > >> Apartheid is not very long ago and the people that experienced this are > >> still alive. > > > > How is this relevant? > > > > Please let me know when you will find "slave boot record". Until then > > - please revert the commit. > > Because the people I am referring to never got a chance to write any > boot loader at school. > And? How this is relevant? How this changes the fact that in "master boot record" word master has no relation to slavery? > > > > Also, I would recommend you educating yourself on the meaning of the > > word "context". > > I didn't steer this commit discussion into the "Master's degree". > To show you that you should consider the context. Master boot record, as well as master's degree, as well as many-many other usecases have no relation with slavery. Otherwise I would suggest you to write a letter to Oxford to completely remove word "master" from English language along with the letter to your MP to introduce a law which would make using word "master" punishable by death. I really feel the pain people feel about slavery and completely support them, but right here right now you are not helping, you are doing quite opposite. > Actually you have a very good point. Didn't think of that yet. I > should be more proud of my Bachelor's than my Masters's apparently. > >>> > >>> Hans, if you wanted to make reductio ad absurdum, that point is seen. > >>> Now, please revert the commit. We are *already losing developers* > >>> because of all this shit and it must be stopped. This is definitely > >>> not the right time to make such changes in such manner, leaving alone > >>> the need for the changes per se. > >> > >> Really? > > > > Trying to be funny does not add you more credibility. > > > > --HPS > ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On 21/06/2020 16:34, Hans Petter Selasky wrote: > Author: hselasky > Date: Sun Jun 21 13:34:08 2020 > New Revision: 362466 > URL: https://svnweb.freebsd.org/changeset/base/362466 > > Log: > Improve wording to be more precise and clear. > No functional change intended. > > s/Master Boot/Main Boot/ (also called MBR) Where does your hate for word 'master', especially in the technical context, come from? https://www.merriam-webster.com/dictionary/master > MFC after: 1 week > Sponsored by: Mellanox Technologies -- Andriy Gapon ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
Hi Alexandr, On 2020-06-21 18:54, Alexandr Kovalenko wrote: On Sun, Jun 21, 2020 at 5:41 PM Hans Petter Selasky wrote: On 2020-06-21 18:11, Alexey Dokuchaev wrote: On Sun, Jun 21, 2020 at 06:01:40PM +0200, Hans Petter Selasky wrote: On 2020-06-21 17:53, Alexandr Kovalenko wrote: I wonder should we also rename Master's Degree? Would you throw away yours? https://en.wiktionary.org/wiki/master I don't see a problem if you have a main computer degree. *facepalm* If you got a Master's degree in South Africa under Apartheid, to many people that is still symbolic. https://en.wikipedia.org/wiki/Apartheid#Education Apartheid is not very long ago and the people that experienced this are still alive. How is this relevant? Please let me know when you will find "slave boot record". Until then - please revert the commit. Because the people I am referring to never got a chance to write any boot loader at school. Also, I would recommend you educating yourself on the meaning of the word "context". I didn't steer this commit discussion into the "Master's degree". Actually you have a very good point. Didn't think of that yet. I should be more proud of my Bachelor's than my Masters's apparently. Hans, if you wanted to make reductio ad absurdum, that point is seen. Now, please revert the commit. We are *already losing developers* because of all this shit and it must be stopped. This is definitely not the right time to make such changes in such manner, leaving alone the need for the changes per se. Really? Trying to be funny does not add you more credibility. --HPS ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On Sun, Jun 21, 2020 at 5:41 PM Hans Petter Selasky wrote: > On 2020-06-21 18:11, Alexey Dokuchaev wrote: > > On Sun, Jun 21, 2020 at 06:01:40PM +0200, Hans Petter Selasky wrote: > >> On 2020-06-21 17:53, Alexandr Kovalenko wrote: > >>> I wonder should we also rename Master's Degree? Would you throw > >>> away yours? > >>> https://en.wiktionary.org/wiki/master > >> > >> I don't see a problem if you have a main computer degree. > > > > *facepalm* > > If you got a Master's degree in South Africa under Apartheid, to many > people that is still symbolic. > > https://en.wikipedia.org/wiki/Apartheid#Education > > Apartheid is not very long ago and the people that experienced this are > still alive. How is this relevant? Please let me know when you will find "slave boot record". Until then - please revert the commit. Also, I would recommend you educating yourself on the meaning of the word "context". > >> Actually you have a very good point. Didn't think of that yet. I > >> should be more proud of my Bachelor's than my Masters's apparently. > > > > Hans, if you wanted to make reductio ad absurdum, that point is seen. > > Now, please revert the commit. We are *already losing developers* > > because of all this shit and it must be stopped. This is definitely > > not the right time to make such changes in such manner, leaving alone > > the need for the changes per se. > > Really? Trying to be funny does not add you more credibility. -- Alexandr Kovalenko http://uafug.org.ua/ ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
Hi Alexey, On 2020-06-21 18:11, Alexey Dokuchaev wrote: On Sun, Jun 21, 2020 at 06:01:40PM +0200, Hans Petter Selasky wrote: On 2020-06-21 17:53, Alexandr Kovalenko wrote: I wonder should we also rename Master's Degree? Would you throw away yours? https://en.wiktionary.org/wiki/master I don't see a problem if you have a main computer degree. *facepalm* If you got a Master's degree in South Africa under Apartheid, to many people that is still symbolic. https://en.wikipedia.org/wiki/Apartheid#Education Apartheid is not very long ago and the people that experienced this are still alive. Actually you have a very good point. Didn't think of that yet. I should be more proud of my Bachelor's than my Masters's apparently. Hans, if you wanted to make reductio ad absurdum, that point is seen. Now, please revert the commit. We are *already losing developers* because of all this shit and it must be stopped. This is definitely not the right time to make such changes in such manner, leaving alone the need for the changes per se. Really? --HPS ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On Sun, Jun 21, 2020 at 06:01:40PM +0200, Hans Petter Selasky wrote: > On 2020-06-21 17:53, Alexandr Kovalenko wrote: > > I wonder should we also rename Master's Degree? Would you throw > > away yours? > > https://en.wiktionary.org/wiki/master > > I don't see a problem if you have a main computer degree. *facepalm* > Actually you have a very good point. Didn't think of that yet. I > should be more proud of my Bachelor's than my Masters's apparently. Hans, if you wanted to make reductio ad absurdum, that point is seen. Now, please revert the commit. We are *already losing developers* because of all this shit and it must be stopped. This is definitely not the right time to make such changes in such manner, leaving alone the need for the changes per se. ./danfe ___ 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"
svn commit: r362467 - stable/12/bin/sh/tests/execution
Author: jilles
Date: Sun Jun 21 16:06:01 2020
New Revision: 362467
URL: https://svnweb.freebsd.org/changeset/base/362467
Log:
MFC r362182: sh/tests: Add tests for SIGINT in non-jobc background commands
If job control is not enabled, background commands shall ignore SIGINT and
SIGQUIT, and it shall be possible to override that ignore in the same shell.
Added:
stable/12/bin/sh/tests/execution/bg11.0
- copied unchanged from r362182, head/bin/sh/tests/execution/bg11.0
stable/12/bin/sh/tests/execution/bg12.0
- copied unchanged from r362182, head/bin/sh/tests/execution/bg12.0
Modified:
stable/12/bin/sh/tests/execution/Makefile
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/bin/sh/tests/execution/Makefile
==
--- stable/12/bin/sh/tests/execution/Makefile Sun Jun 21 13:34:08 2020
(r362466)
+++ stable/12/bin/sh/tests/execution/Makefile Sun Jun 21 16:06:01 2020
(r362467)
@@ -17,6 +17,8 @@ ${PACKAGE}FILES+= bg7.0
${PACKAGE}FILES+= bg8.0
${PACKAGE}FILES+= bg9.0
${PACKAGE}FILES+= bg10.0 bg10.0.stdout
+${PACKAGE}FILES+= bg11.0
+${PACKAGE}FILES+= bg12.0
${PACKAGE}FILES+= fork1.0
${PACKAGE}FILES+= fork2.0
${PACKAGE}FILES+= fork3.0
Copied: stable/12/bin/sh/tests/execution/bg11.0 (from r362182,
head/bin/sh/tests/execution/bg11.0)
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ stable/12/bin/sh/tests/execution/bg11.0 Sun Jun 21 16:06:01 2020
(r362467, copy of r362182, head/bin/sh/tests/execution/bg11.0)
@@ -0,0 +1,16 @@
+# $FreeBSD$
+
+T=`mktemp -d ${TMPDIR:-/tmp}/sh-test.`
+trap 'rm -rf $T' 0
+cd $T || exit 3
+mkfifo fifo1
+# Use a trap, not the default action, since the shell may catch SIGINT and
+# therefore its processing may be delayed.
+{ trap 'exit 5' TERM; read dummy fifo1
+kill -INT "$!"
+kill -TERM "$!"
+exec 3>&-
+wait "$!"
+r=$?
+[ "$r" = 5 ]
Copied: stable/12/bin/sh/tests/execution/bg12.0 (from r362182,
head/bin/sh/tests/execution/bg12.0)
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ stable/12/bin/sh/tests/execution/bg12.0 Sun Jun 21 16:06:01 2020
(r362467, copy of r362182, head/bin/sh/tests/execution/bg12.0)
@@ -0,0 +1,12 @@
+# $FreeBSD$
+
+T=`mktemp -d ${TMPDIR:-/tmp}/sh-test.`
+trap 'rm -rf $T' 0
+cd $T || exit 3
+mkfifo fifo1
+{ trap - INT; : >fifo1; sleep 5; exit 4; } &
+: https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On 2020-06-21 17:53, Alexandr Kovalenko wrote: On Sun, Jun 21, 2020 at 4:38 PM Hans Petter Selasky wrote: On 2020-06-21 17:35, Alexander Motin wrote: Please revert. This is not the area we should make standards at. Besides, you've modified contributed software (file and tcpdump) for no FreeBSD-specifc reason instead of properly upstreaming your change, if you really like so. Noted. I wonder should we also rename Master's Degree? Would you throw away yours? https://en.wiktionary.org/wiki/master I don't see a problem if you have a main computer degree. Actually you have a very good point. Didn't think of that yet. I should be more proud of my Bachelor's than my Masters's apparently. (engineering, computing) A device that is controlling other devices or is an authoritative source.a master wheela master database P.S. Making commit, then creating Wikipedia article based on commit and then using that wiki page to defend your commit - you don't feel that something is fishy here? Isn't this within what is acceptable? Someone committed something, it broke something unforeseen, and we respond and fix it. FreeBSD head is for trying out things. And I did not MFC anything yet! --HPS ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On Sun, Jun 21, 2020 at 4:38 PM Hans Petter Selasky wrote: > > On 2020-06-21 17:35, Alexander Motin wrote: > > Please revert. This is not the area we should make standards at. > > Besides, you've modified contributed software (file and tcpdump) for no > > FreeBSD-specifc reason instead of properly upstreaming your change, if > > you really like so. > > Noted. I wonder should we also rename Master's Degree? Would you throw away yours? https://en.wiktionary.org/wiki/master (engineering, computing) A device that is controlling other devices or is an authoritative source.a master wheela master database P.S. Making commit, then creating Wikipedia article based on commit and then using that wiki page to defend your commit - you don't feel that something is fishy here? -- Alexandr Kovalenko http://uafug.org.ua/ ___ 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: r362261 - head/contrib/file/magic/Magdir
On Wed, 17 Jun 2020 at 12:10, Xin Li wrote: > > Hi, > > On 6/17/20 3:11 AM, Antoine Brodin wrote: > > Author: antoine > > Date: Wed Jun 17 10:11:54 2020 > > New Revision: 362261 > > URL: https://svnweb.freebsd.org/changeset/base/362261 > > > > Log: > > Re-apply r333944 to unbreak ports > > Could you please file a bug against the upstream (Christos cc'ed), as it > may also affect other users? Also PR 246960. I'm still looking into things but I think that file upstream is correct and we just need to revert r362261. ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On 2020-06-21 17:35, Alexander Motin wrote: Please revert. This is not the area we should make standards at. Besides, you've modified contributed software (file and tcpdump) for no FreeBSD-specifc reason instead of properly upstreaming your change, if you really like so. Noted. --HPS ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On 21.06.2020 10:48, Hans Petter Selasky wrote: > On 2020-06-21 16:43, Warner Losh wrote: >> Please revert. Another part if the guidance was that industry standard >> terms should be used until the industry renames them. This makes FreeBSD >> unique for no good reason. > > Have you forgotten that FreeBSD is an industry leader in many areas and > we are the ones making the standards of the future! Please revert. This is not the area we should make standards at. Besides, you've modified contributed software (file and tcpdump) for no FreeBSD-specifc reason instead of properly upstreaming your change, if you really like so. -- Alexander Motin ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
21.06.2020 21:48, Hans Petter Selasky wrote: > On 2020-06-21 16:43, Warner Losh wrote: >> Please revert. Another part if the guidance was that industry standard >> terms should be used until the industry renames them. This makes FreeBSD >> unique for no good reason. > > Hi Warner, > > Have you forgotten that FreeBSD is an industry leader in many areas and we > are the ones making the standards of the future! Even if you are trying make "a precedent" of commit+backout here, it's still wrong. If you are serious... We've already seen really sad example of one of committers, please don't go that way, I really appreciate your past contributions. ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On Sun, Jun 21, 2020, 8:48 AM Hans Petter Selasky wrote: > On 2020-06-21 16:43, Warner Losh wrote: > > Please revert. Another part if the guidance was that industry standard > > terms should be used until the industry renames them. This makes FreeBSD > > unique for no good reason. > > Hi Warner, > > Have you forgotten that FreeBSD is an industry leader in many areas and > we are the ones making the standards of the future! > Please back this out. This is not a standard term and we are too small to innovate and set one here. Warner > ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On 2020-06-21 16:43, Warner Losh wrote: Please revert. Another part if the guidance was that industry standard terms should be used until the industry renames them. This makes FreeBSD unique for no good reason. Hi Warner, Have you forgotten that FreeBSD is an industry leader in many areas and we are the ones making the standards of the future! --HPS ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
Hi Alexey, On 2020-06-21 16:27, Alexey Dokuchaev wrote: There is no chicken and egg problem here Hans. You're inventing bogus and unsound terminology that does no good and only confuses our users, code readers, and makes us as a project look like idiots. There is no unsound terminology: https://www.google.com/search?q=main+boot+record At least Google knows exactly what I mean, even without asking if I want to search for "main boot loader" or "master boot loader"! Several people had asked you to revert the commit. It was not properly reviewed, it solves no existing problem, but creates one instead. Like said, there no real breakage. And if you find more that is broken I will write it down, like the Wikipedia link and fix it. Please give me some time. --HPS ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On Sun, Jun 21, 2020, 8:38 AM Hans Petter Selasky wrote: > On 2020-06-21 15:47, Emmanuel Vadot wrote: > > What's more clear about calling something that is called Master Boot > > Record something else ? > > What's next ? Will you contact the BBC so they redub all Doctor Who > > episode where "The Master" appears ? Contact Disney so the release a > > new version of Tron where the Master Control Program is call the Main > > Control Program ? > > Hi Manu, > > I didn't know BBC made such episodes. > > And no, I won't contact BBC nor Disney about this. > > The point here is that the Master's Boot Record may be very badly > perceived by some people. Do I need to explain that? > Please revert. Another part if the guidance was that industry standard terms should be used until the industry renames them. This makes FreeBSD unique for no good reason. There also is no slave boot record. Master here comes from the same place as master key. Warner > > ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On Sun, Jun 21, 2020, 09:38 Hans Petter Selasky wrote: > On 2020-06-21 15:47, Emmanuel Vadot wrote: > > What's more clear about calling something that is called Master Boot > > Record something else ? > > What's next ? Will you contact the BBC so they redub all Doctor Who > > episode where "The Master" appears ? Contact Disney so the release a > > new version of Tron where the Master Control Program is call the Main > > Control Program ? > > Hi Manu, > > I didn't know BBC made such episodes. > > And no, I won't contact BBC nor Disney about this. > > The point here is that the Master's Boot Record may be very badly > perceived by some people. Do I need to explain that? > > --HPS > No it can't. It's an absurd change. - Justin > ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On 2020-06-21 15:47, Emmanuel Vadot wrote: What's more clear about calling something that is called Master Boot Record something else ? What's next ? Will you contact the BBC so they redub all Doctor Who episode where "The Master" appears ? Contact Disney so the release a new version of Tron where the Master Control Program is call the Main Control Program ? Hi Manu, I didn't know BBC made such episodes. And no, I won't contact BBC nor Disney about this. The point here is that the Master's Boot Record may be very badly perceived by some people. Do I need to explain that? --HPS ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On Sun, Jun 21, 2020 at 04:09:15PM +0200, Hans Petter Selasky wrote: > On 2020-06-21 16:02, Alexey Dokuchaev wrote: > > Last edited by Hselasky (talk | contribs) 0 seconds ago. > > > > Ah, so you first make changes to FreeBSD and then attempt to edit the > > Wikipedia to look like it supports your views? Seriously Hans?! > > This is a chicken an egg problem. It was easier to start with FreeBSD > and the follow up on Wikipedia. There is no chicken and egg problem here Hans. You're inventing bogus and unsound terminology that does no good and only confuses our users, code readers, and makes us as a project look like idiots. Several people had asked you to revert the commit. It was not properly reviewed, it solves no existing problem, but creates one instead. Please don't "fix" what ain't broken. ./danfe ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
Hi Alexey, On 2020-06-21 16:02, Alexey Dokuchaev wrote: Last edited by Hselasky (talk | contribs) 0 seconds ago. Ah, so you first make changes to FreeBSD and then attempt to edit the Wikipedia to look like it supports your views? Seriously Hans?! This is a chicken an egg problem. It was easier to start with FreeBSD and the follow up on Wikipedia. Anyways it is a comment in a text file and if it is not fixed in a few days time, I'll fix the link back to what it was. I'm not running away. --HPS ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On Sun, Jun 21, 2020 at 01:59:12PM +, Alexey Dokuchaev wrote: > On Sun, Jun 21, 2020 at 03:48:33PM +0200, Emmanuel Vadot wrote: > > On Sun, 21 Jun 2020 15:46:56 +0200 > > Hans Petter Selasky wrote: > > > On 2020-06-21 15:45, Alexey Dokuchaev wrote: > > > >> ... > > > >> -#https://en.wikipedia.org/wiki/Master_boot_record#PTE > > > >> +#https://en.wikipedia.org/wiki/Main_boot_record#PTE > > > > Wikipedia does not have an article with this name. > > > > > > Yes, it does: > > > https://en.wikipedia.org/wiki/Main_boot_record > > > > > > No, need to revert. > > > > So because some random person on the net created a redirection MBR is > > now defined at Main Boot Record ? WFT > > There's no redirection; this article simply does not exist (well, did > not exist several minutes ago as apparently someone had added a draft > for it just now). Last edited by Hselasky (talk | contribs) 0 seconds ago. Ah, so you first make changes to FreeBSD and then attempt to edit the Wikipedia to look like it supports your views? Seriously Hans?! ./danfe ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On 2020-06-21 15:46, Hans Petter Selasky wrote: On 2020-06-21 15:45, Alexey Dokuchaev wrote: ... -#https://en.wikipedia.org/wiki/Master_boot_record#PTE +#https://en.wikipedia.org/wiki/Main_boot_record#PTE Wikipedia does not have an article with this name. Yes, it does: https://en.wikipedia.org/wiki/Main_boot_record The Link will be there in a bit: https://en.wikipedia.org/w/index.php?title=Draft:Main_boot_record=edit --HPS https://en.wikipedia.org/wiki/Master_Boot_record ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On Sun, Jun 21, 2020 at 03:48:33PM +0200, Emmanuel Vadot wrote: > On Sun, 21 Jun 2020 15:46:56 +0200 > Hans Petter Selasky wrote: > > On 2020-06-21 15:45, Alexey Dokuchaev wrote: > > >> ... > > >> -#https://en.wikipedia.org/wiki/Master_boot_record#PTE > > >> +#https://en.wikipedia.org/wiki/Main_boot_record#PTE > > > Wikipedia does not have an article with this name. > > > > Yes, it does: > > https://en.wikipedia.org/wiki/Main_boot_record > > > > No, need to revert. > > So because some random person on the net created a redirection MBR is > now defined at Main Boot Record ? WFT There's no redirection; this article simply does not exist (well, did not exist several minutes ago as apparently someone had added a draft for it just now). ./danfe ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
> On 21 Jun 2020, at 14:51, Hans Petter Selasky wrote: > > On 2020-06-21 15:46, Hans Petter Selasky wrote: >> On 2020-06-21 15:45, Alexey Dokuchaev wrote: ... -#https://en.wikipedia.org/wiki/Master_boot_record#PTE +#https://en.wikipedia.org/wiki/Main_boot_record#PTE >>> Wikipedia does not have an article with this name. >> Yes, it does: >> https://en.wikipedia.org/wiki/Main_boot_record > > When you enter "main boot record" in the search field, it automagically > redirects to "master boot record". No, it doesn't. "Wikipedia does not have an article with this exact name." M -- signature.asc Description: Message signed with OpenPGP
Re: svn commit: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On Sun, Jun 21, 2020 at 03:46:56PM +0200, Hans Petter Selasky wrote: > On 2020-06-21 15:45, Alexey Dokuchaev wrote: > >> ... > >> -#https://en.wikipedia.org/wiki/Master_boot_record#PTE > >> +#https://en.wikipedia.org/wiki/Main_boot_record#PTE > > Wikipedia does not have an article with this name. > > Yes, it does: > https://en.wikipedia.org/wiki/Main_boot_record No, it doesn't. The fast that it does not return 404 does not mean it exists, this is how wikis work. Please read the contents. > No, need to revert. Just as we managed to cool down this shitstorm of controversial commits hitting the tree undiscussed, you're pouring more oil to the flames. This has to stop. Again, this commit must be reverted and DR opened with proposed changes if you feel they're warranted, because IMHO they are not: as with "master volume", MBR has its well defined meaning, there's no "slave boot record" and hence this change was totally uncalled for. ./danfe ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
21.06.2020 20:34, Hans Petter Selasky wrote: > Author: hselasky > Date: Sun Jun 21 13:34:08 2020 > New Revision: 362466 > URL: https://svnweb.freebsd.org/changeset/base/362466 > > Log: > Improve wording to be more precise and clear. > No functional change intended. > > s/Master Boot/Main Boot/ (also called MBR) Please revert. No one has rights to rewrite history and create such a mess, and Master Boot Record is historical term. ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On 2020-06-21 15:46, Hans Petter Selasky wrote: On 2020-06-21 15:45, Alexey Dokuchaev wrote: ... -#https://en.wikipedia.org/wiki/Master_boot_record#PTE +#https://en.wikipedia.org/wiki/Main_boot_record#PTE Wikipedia does not have an article with this name. Yes, it does: https://en.wikipedia.org/wiki/Main_boot_record When you enter "main boot record" in the search field, it automagically redirects to "master boot record". --HPS ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On Sun, 21 Jun 2020 15:46:56 +0200 Hans Petter Selasky wrote: > On 2020-06-21 15:45, Alexey Dokuchaev wrote: > >> ... > >> -#https://en.wikipedia.org/wiki/Master_boot_record#PTE > >> +#https://en.wikipedia.org/wiki/Main_boot_record#PTE > > Wikipedia does not have an article with this name. > > Yes, it does: > https://en.wikipedia.org/wiki/Main_boot_record > > No, need to revert. > > --HPS So because some random person on the net created a redirection MBR is now defined at Main Boot Record ? WFT -- Emmanuel Vadot ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On Sun, 21 Jun 2020 13:34:09 + (UTC) Hans Petter Selasky wrote: > Author: hselasky > Date: Sun Jun 21 13:34:08 2020 > New Revision: 362466 > URL: https://svnweb.freebsd.org/changeset/base/362466 > > Log: > Improve wording to be more precise and clear. > No functional change intended. > > s/Master Boot/Main Boot/ (also called MBR) > > MFC after: 1 week > Sponsored by: Mellanox Technologies Hans, please revert this. What's more clear about calling something that is called Master Boot Record something else ? What's next ? Will you contact the BBC so they redub all Doctor Who episode where "The Master" appears ? Contact Disney so the release a new version of Tron where the Master Control Program is call the Main Control Program ? -- Emmanuel Vadot ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On 2020-06-21 15:45, Alexey Dokuchaev wrote: ... -#https://en.wikipedia.org/wiki/Master_boot_record#PTE +#https://en.wikipedia.org/wiki/Main_boot_record#PTE Wikipedia does not have an article with this name. Yes, it does: https://en.wikipedia.org/wiki/Main_boot_record No, need to revert. --HPS ___ 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: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbi
On Sun, Jun 21, 2020 at 01:34:09PM +, Hans Petter Selasky wrote: > New Revision: 362466 > URL: https://svnweb.freebsd.org/changeset/base/362466 > > Log: > Improve wording to be more precise and clear. > No functional change intended. Please revert. > ... > -# https://en.wikipedia.org/wiki/Master_boot_record#PTE > +# https://en.wikipedia.org/wiki/Main_boot_record#PTE Wikipedia does not have an article with this name. ./danfe ___ 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"
svn commit: r362466 - in head: contrib/file/magic/Magdir contrib/tcpdump lib/geom/part stand/efi/include stand/i386/boot0 sys/dev/hptmv sys/geom/part usr.bin/fortune/datfiles usr.bin/mkimg usr.sbin...
Author: hselasky
Date: Sun Jun 21 13:34:08 2020
New Revision: 362466
URL: https://svnweb.freebsd.org/changeset/base/362466
Log:
Improve wording to be more precise and clear.
No functional change intended.
s/Master Boot/Main Boot/ (also called MBR)
MFC after:1 week
Sponsored by: Mellanox Technologies
Modified:
head/contrib/file/magic/Magdir/filesystems
head/contrib/tcpdump/smbutil.c
head/lib/geom/part/gpart.8
head/stand/efi/include/efipart.h
head/stand/i386/boot0/boot0.S
head/sys/dev/hptmv/vdevice.h
head/sys/geom/part/g_part_mbr.c
head/usr.bin/fortune/datfiles/freebsd-tips
head/usr.bin/mkimg/mbr.c
head/usr.sbin/boot0cfg/boot0cfg.8
head/usr.sbin/boot0cfg/boot0cfg.c
Modified: head/contrib/file/magic/Magdir/filesystems
==
--- head/contrib/file/magic/Magdir/filesystems Sun Jun 21 11:48:55 2020
(r362465)
+++ head/contrib/file/magic/Magdir/filesystems Sun Jun 21 13:34:08 2020
(r362466)
@@ -269,8 +269,8 @@
!:strength +65
>2 string OSBSOS/BS MBR
# added by Joerg Jenderek at Feb 2013 according to
https://thestarman.pcministry.com/asm/mbr/
-# and https://en.wikipedia.org/wiki/Master_Boot_Record
-# test for nearly all MS-DOS Master Boot Record initial program loader (IPL)
is now done by
+# and https://en.wikipedia.org/wiki/Main_Boot_Record
+# test for nearly all MS-DOS Main Boot Record initial program loader (IPL) is
now done by
# characteristic assembler instructions: xor ax,ax;mov ss,ax;mov sp,7c00
>0 search/2\x33\xc0\x8e\xd0\xbc\x00\x7cMS-MBR
# Microsoft Windows 95A and early (
https://thestarman.pcministry.com/asm/mbr/STDMBR.htm )
@@ -436,7 +436,7 @@
>>>387 string Copyright\ (c)\ 1984,1998
411string Caldera\ Inc.\0 \b, DR-DOS MBR (IBMBIO.LDR)
#
-# tests for different MS-DOS Master Boot Records (MBR) moved and merged
+# tests for different MS-DOS Main Boot Records (MBR) moved and merged
#
#>0x145string Default:\ F \b, FREE-DOS MBR
#>0x14Bstring Default:\ F \b, FREE-DOS
1.0 MBR
@@ -1087,7 +1087,7 @@
>11ubyte x \b+
>11use DOS-filename
-# https://en.wikipedia.org/wiki/Master_boot_record#PTE
+# https://en.wikipedia.org/wiki/Main_boot_record#PTE
# display standard partition table
0 namepartition-table
#>0ubyte x PARTITION-TABLE
Modified: head/contrib/tcpdump/smbutil.c
==
--- head/contrib/tcpdump/smbutil.c Sun Jun 21 11:48:55 2020
(r362465)
+++ head/contrib/tcpdump/smbutil.c Sun Jun 21 13:34:08 2020
(r362466)
@@ -1339,7 +1339,7 @@ static const nt_err_code_struct nt_errors[] = {
{ 0xC0A6, "STATUS_CANT_OPEN_ANONYMOUS" },
{ 0xC0A7, "STATUS_BAD_VALIDATION_CLASS" },
{ 0xC0A8, "STATUS_BAD_TOKEN_TYPE" },
- { 0xC0A9, "STATUS_BAD_MASTER_BOOT_RECORD" },
+ { 0xC0A9, "STATUS_BAD_MAIN_BOOT_RECORD" },
{ 0xC0AA, "STATUS_INSTRUCTION_MISALIGNMENT" },
{ 0xC0AB, "STATUS_INSTANCE_NOT_AVAILABLE" },
{ 0xC0AC, "STATUS_PIPE_NOT_AVAILABLE" },
Modified: head/lib/geom/part/gpart.8
==
--- head/lib/geom/part/gpart.8 Sun Jun 21 11:48:55 2020(r362465)
+++ head/lib/geom/part/gpart.8 Sun Jun 21 13:34:08 2020(r362466)
@@ -582,7 +582,7 @@ Requires the
.Cm GEOM_PART_GPT
kernel option.
.It Cm MBR
-Master Boot Record is used on PCs and removable media.
+Main Boot Record is used on PCs and removable media.
Requires the
.Cm GEOM_PART_MBR
kernel option.
@@ -852,7 +852,7 @@ for MBR and
.Qq Li "!0657fd6d-a4ab-43c4-84e5-0933c84b4f4f"
for GPT.
.It Cm mbr
-A partition that is sub-partitioned by a Master Boot Record (MBR).
+A partition that is sub-partitioned by a Main Boot Record (MBR).
This type is known as
.Qq Li "!024dee41-33e7-11d3-9d69-0008c781f39f"
by GPT.
@@ -1020,7 +1020,7 @@ option.
The GEOM PART class knows how to safely embed bootstrap code into
specific partitioning scheme metadata without causing any damage.
.Pp
-The Master Boot Record (MBR) uses a 512-byte bootstrap code image, embedded
+The Main Boot Record (MBR) uses a 512-byte bootstrap code image, embedded
into the partition table's metadata area.
There are two variants of this bootstrap code:
.Pa /boot/mbr
@@ -1256,7 +1256,7 @@ present as independent partition.
.Em NOTE :
This may break a mirrored volume and lead to data damage.
.It Va kern.geom.part.mbr.enforce_chs : No 0
-Specify how the Master Boot Record (MBR) module does alignment.
+Specify how the Main Boot Record (MBR) module does alignment.
If this variable is set to a non-zero value, the module will automatically
recalculate
svn commit: r362465 - stable/12/sys/netinet
Author: bz Date: Sun Jun 21 11:48:55 2020 New Revision: 362465 URL: https://svnweb.freebsd.org/changeset/base/362465 Log: MFC r362289: When converting the static arrays to mallocarray() in r356621 I missed one place where we now need to multiply the size of the struct with the number of entries. This lead to problems when restarting user space daemons, as the cleanup was never properly done, resulting in MRT_ADD_VIF EADDRINUSE. Properly zero all array elements to avoid this problem. PR: 246629, 206583 Modified: stable/12/sys/netinet/ip_mroute.c Directory Properties: stable/12/ (props changed) Modified: stable/12/sys/netinet/ip_mroute.c == --- stable/12/sys/netinet/ip_mroute.c Sun Jun 21 11:42:49 2020 (r362464) +++ stable/12/sys/netinet/ip_mroute.c Sun Jun 21 11:48:55 2020 (r362465) @@ -739,7 +739,7 @@ X_ip_mrouter_done(void) if_allmulti(ifp, 0); } } -bzero((caddr_t)V_viftable, sizeof(V_viftable)); +bzero((caddr_t)V_viftable, sizeof(V_viftable) * MAXVIFS); V_numvifs = 0; V_pim_assert_enabled = 0; ___ 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"
svn commit: r362464 - head/usr.bin/w
Author: yuripv
Date: Sun Jun 21 11:42:49 2020
New Revision: 362464
URL: https://svnweb.freebsd.org/changeset/base/362464
Log:
w: use locale-based string format specifiers
Use locale-based string format specifiers when printing
the process names/arguments.
Reviewed by: pstef
Differential Revision:https://reviews.freebsd.org/D25174
Modified:
head/usr.bin/w/w.c
Modified: head/usr.bin/w/w.c
==
--- head/usr.bin/w/w.c Sun Jun 21 10:09:34 2020(r362463)
+++ head/usr.bin/w/w.c Sun Jun 21 11:42:49 2020(r362464)
@@ -438,8 +438,8 @@ main(int argc, char *argv[])
if (ptr == NULL)
ptr = "-";
xo_open_instance("process-entry");
- xo_emit("\t\t{:process-id/%-9d/%d}
{:command/%s}\n",
- dkp->ki_pid, ptr);
+ xo_emit("\t\t{:process-id/%-9d/%d} "
+ "{:command/%hs}\n", dkp->ki_pid, ptr);
xo_close_instance("process-entry");
}
xo_close_list("process-entry");
@@ -460,7 +460,7 @@ main(int argc, char *argv[])
t = ep->utmp.ut_tv.tv_sec;
longattime = pr_attime(, );
longidle = pr_idle(ep->idle);
- xo_emit("{:command/%.*s/%@*@s}\n",
+ xo_emit("{:command/%.*hs/%@*@hs}\n",
argwidth - longidle - longattime,
ep->args);
___
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"
svn commit: r362463 - in head/sys: amd64/linux amd64/linux32 i386/linux
Author: trasz
Date: Sun Jun 21 10:09:34 2020
New Revision: 362463
URL: https://svnweb.freebsd.org/changeset/base/362463
Log:
Adapt linuxulator syscalls.master files to the new layout.
No functional changes.
Reviewed by: brooks
MFC after:2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision:https://reviews.freebsd.org/D25381
Modified:
head/sys/amd64/linux/syscalls.master
head/sys/amd64/linux32/syscalls.master
head/sys/i386/linux/syscalls.master
Modified: head/sys/amd64/linux/syscalls.master
==
--- head/sys/amd64/linux/syscalls.masterSun Jun 21 09:56:09 2020
(r362462)
+++ head/sys/amd64/linux/syscalls.masterSun Jun 21 10:09:34 2020
(r362463)
@@ -38,579 +38,1931 @@
; #ifdef's, etc. may be included, and are copied to the output files.
-0 AUE_NULLNOPROTO { int read(int fd, char *buf, \
- u_int nbyte); }
-1 AUE_NULLNOPROTO { int write(int fd, char *buf, \
- u_int nbyte); }
-2 AUE_OPEN_RWTC STD { int linux_open(char *path, l_int flags, \
- l_int mode); }
-3 AUE_CLOSE NOPROTO { int close(int fd); }
-4 AUE_STATSTD { int linux_newstat(char *path, \
- struct l_newstat *buf); }
-5 AUE_FSTAT STD { int linux_newfstat(l_uint fd, \
- struct l_newstat *buf); }
-6 AUE_LSTAT STD { int linux_newlstat(char *path, \
- struct l_newstat *buf); }
-7 AUE_POLLNOPROTO { int poll(struct pollfd *fds, u_int nfds, \
- int timeout); }
-8 AUE_LSEEK STD { int linux_lseek(l_uint fdes, l_off_t off, \
- l_int whence); }
-9 AUE_MMAPSTD { int linux_mmap2(l_ulong addr, l_ulong len, \
- l_ulong prot, l_ulong flags, l_ulong fd, \
- l_ulong pgoff); }
-10 AUE_MPROTECTSTD { int linux_mprotect(caddr_t addr, l_int len, \
- l_int prot); }
-11 AUE_MUNMAP NOPROTO { int munmap(caddr_t addr, int len); }
-12 AUE_NULLSTD { int linux_brk(l_ulong dsend); }
-13 AUE_NULLSTD { int linux_rt_sigaction(l_int sig, \
- l_sigaction_t *act, l_sigaction_t *oact, \
- l_size_t sigsetsize); }
-14 AUE_NULLSTD { int linux_rt_sigprocmask(l_int how, \
- l_sigset_t *mask, l_sigset_t *omask, \
- l_size_t sigsetsize); }
-15 AUE_NULLSTD { int linux_rt_sigreturn( \
- struct l_ucontext *ucp); }
-16 AUE_IOCTL STD { int linux_ioctl(l_uint fd, l_uint cmd, \
- uintptr_t arg); }
-17 AUE_PREAD STD { int linux_pread(l_uint fd, char *buf, \
- l_size_t nbyte, l_loff_t offset); }
-18 AUE_PWRITE STD { int linux_pwrite(l_uint fd, char *buf, \
- l_size_t nbyte, l_loff_t offset); }
-19 AUE_READV NOPROTO { int readv(int fd, struct iovec *iovp, \
- u_int iovcnt); }
-20 AUE_WRITEV NOPROTO { int writev(int fd, struct iovec *iovp, \
- u_int iovcnt); }
-21 AUE_ACCESS STD { int linux_access(char *path, l_int amode); }
-22 AUE_PIPESTD { int linux_pipe(l_ulong *pipefds); }
-23 AUE_SELECT STD { int linux_select(l_int nfds, \
- l_fd_set *readfds, l_fd_set *writefds, \
- l_fd_set *exceptfds, \
- struct l_timeval *timeout); }
-24 AUE_NULLNOPROTO { int sched_yield(void); }
-25 AUE_NULLSTD { int linux_mremap(l_ulong addr, \
- l_ulong old_len, l_ulong new_len, \
- l_ulong flags, l_ulong new_addr); }
-26 AUE_MSYNC STD { int linux_msync(l_ulong addr, \
- l_size_t len, l_int fl); }
-27 AUE_MINCORE STD { int linux_mincore(l_ulong start, \
- l_size_t len, u_char *vec); }
-28 AUE_MADVISE STD { int linux_madvise(void *addr, size_t len, \
- int behav); }
-29 AUE_NULLSTD { int linux_shmget(l_key_t key, l_size_t size, \
- l_int shmflg); }
-30 AUE_NULLSTD { int linux_shmat(l_int shmid, char *shmaddr, \
- l_int
svn commit: r362462 - head/sys/netinet
Author: tuexen
Date: Sun Jun 21 09:56:09 2020
New Revision: 362462
URL: https://svnweb.freebsd.org/changeset/base/362462
Log:
Fix the build for an INET6 only configuration.
The fix from the last commit is actually needed twice...
MFC after:1 week
Modified:
head/sys/netinet/sctputil.c
Modified: head/sys/netinet/sctputil.c
==
--- head/sys/netinet/sctputil.c Sun Jun 21 09:24:47 2020(r362461)
+++ head/sys/netinet/sctputil.c Sun Jun 21 09:56:09 2020(r362462)
@@ -6853,6 +6853,8 @@ sctp_bindx_delete_address(struct sctp_inpcb *inp,
} else {
addr_to_use = sa;
}
+#else
+ addr_to_use = sa;
#endif
break;
#endif
___
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: r362460 - in head/sys: compat/cloudabi fs/devfs kern sys
On 2020-06-21 08:51:24, Thomas Munro wrote: Author: tmunro Date: Sun Jun 21 08:51:24 2020 New Revision: 362460 URL: https://svnweb.freebsd.org/changeset/base/362460 Log: vfs: track sequential reads and writes separately This sounds great to me! Have you considered MFC-ing this? ___ 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"
svn commit: r362461 - in stable: 11/contrib/llvm-project/llvm/lib/Analysis 11/lib/clang/include/clang/Config 12/contrib/llvm-project/llvm/lib/Analysis 12/lib/clang/include/clang/Config
Author: dim
Date: Sun Jun 21 09:24:47 2020
New Revision: 362461
URL: https://svnweb.freebsd.org/changeset/base/362461
Log:
MFC r362341:
Merge commit 0cecafd647cc from llvm git (by Alina Sbirlea):
[BasicAA] Make BasicAA a cfg pass.
Summary:
Part of the changes in D44564 made BasicAA not CFG only due to it
using PhiAnalysisValues which may have values invalidated. Subsequent
patches (rL340613) appear to have addressed this limitation.
BasicAA should not be invalidated by non-CFG-altering passes. A
concrete example is MemCpyOpt which preserves CFG, but we are testing
it invalidates BasicAA.
llvm-dev RFC:
https://groups.google.com/forum/#!topic/llvm-dev/eSPXuWnNfzM
Reviewers: john.brawn, sebpop, hfinkel, brzycki
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74353
This fixes an issue with clang's -fintegrated-cc1 feature, which could
make it output slightly different assembly code, depending on the way it
was invoked.
In r361755 we attempted to work around it by disabling the integrated
cc1 stage, but it did not solve the root cause for all situations.
Extensive testing and bisecting showed that the above change finally
makes the output deterministic, even if -fintegrated-cc1 is on.
Reported by: Fabian Keil
PR: 246630
Modified:
stable/12/contrib/llvm-project/llvm/lib/Analysis/BasicAliasAnalysis.cpp
stable/12/lib/clang/include/clang/Config/config.h
Directory Properties:
stable/12/ (props changed)
Changes in other areas also in this revision:
Modified:
stable/11/contrib/llvm-project/llvm/lib/Analysis/BasicAliasAnalysis.cpp
stable/11/lib/clang/include/clang/Config/config.h
Directory Properties:
stable/11/ (props changed)
stable/11/contrib/llvm-project/llvm/ (props changed)
Modified:
stable/12/contrib/llvm-project/llvm/lib/Analysis/BasicAliasAnalysis.cpp
==
--- stable/12/contrib/llvm-project/llvm/lib/Analysis/BasicAliasAnalysis.cpp
Sun Jun 21 08:51:24 2020(r362460)
+++ stable/12/contrib/llvm-project/llvm/lib/Analysis/BasicAliasAnalysis.cpp
Sun Jun 21 09:24:47 2020(r362461)
@@ -2059,12 +2059,13 @@ char BasicAAWrapperPass::ID = 0;
void BasicAAWrapperPass::anchor() {}
INITIALIZE_PASS_BEGIN(BasicAAWrapperPass, "basicaa",
- "Basic Alias Analysis (stateless AA impl)", false, true)
+ "Basic Alias Analysis (stateless AA impl)", true, true)
INITIALIZE_PASS_DEPENDENCY(AssumptionCacheTracker)
INITIALIZE_PASS_DEPENDENCY(DominatorTreeWrapperPass)
INITIALIZE_PASS_DEPENDENCY(TargetLibraryInfoWrapperPass)
+INITIALIZE_PASS_DEPENDENCY(PhiValuesWrapperPass)
INITIALIZE_PASS_END(BasicAAWrapperPass, "basicaa",
-"Basic Alias Analysis (stateless AA impl)", false, true)
+"Basic Alias Analysis (stateless AA impl)", true, true)
FunctionPass *llvm::createBasicAAWrapperPass() {
return new BasicAAWrapperPass();
Modified: stable/12/lib/clang/include/clang/Config/config.h
==
--- stable/12/lib/clang/include/clang/Config/config.h Sun Jun 21 08:51:24
2020(r362460)
+++ stable/12/lib/clang/include/clang/Config/config.h Sun Jun 21 09:24:47
2020(r362461)
@@ -82,6 +82,6 @@
/* #undef CLANG_ENABLE_STATIC_ANALYZER */
/* Spawn a new process clang.exe for the CC1 tool invocation, when necessary */
-#define CLANG_SPAWN_CC1 1
+#define CLANG_SPAWN_CC1 0
#endif
___
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"
svn commit: r362461 - in stable: 11/contrib/llvm-project/llvm/lib/Analysis 11/lib/clang/include/clang/Config 12/contrib/llvm-project/llvm/lib/Analysis 12/lib/clang/include/clang/Config
Author: dim
Date: Sun Jun 21 09:24:47 2020
New Revision: 362461
URL: https://svnweb.freebsd.org/changeset/base/362461
Log:
MFC r362341:
Merge commit 0cecafd647cc from llvm git (by Alina Sbirlea):
[BasicAA] Make BasicAA a cfg pass.
Summary:
Part of the changes in D44564 made BasicAA not CFG only due to it
using PhiAnalysisValues which may have values invalidated. Subsequent
patches (rL340613) appear to have addressed this limitation.
BasicAA should not be invalidated by non-CFG-altering passes. A
concrete example is MemCpyOpt which preserves CFG, but we are testing
it invalidates BasicAA.
llvm-dev RFC:
https://groups.google.com/forum/#!topic/llvm-dev/eSPXuWnNfzM
Reviewers: john.brawn, sebpop, hfinkel, brzycki
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74353
This fixes an issue with clang's -fintegrated-cc1 feature, which could
make it output slightly different assembly code, depending on the way it
was invoked.
In r361755 we attempted to work around it by disabling the integrated
cc1 stage, but it did not solve the root cause for all situations.
Extensive testing and bisecting showed that the above change finally
makes the output deterministic, even if -fintegrated-cc1 is on.
Reported by: Fabian Keil
PR: 246630
Modified:
stable/11/contrib/llvm-project/llvm/lib/Analysis/BasicAliasAnalysis.cpp
stable/11/lib/clang/include/clang/Config/config.h
Directory Properties:
stable/11/ (props changed)
stable/11/contrib/llvm-project/llvm/ (props changed)
Changes in other areas also in this revision:
Modified:
stable/12/contrib/llvm-project/llvm/lib/Analysis/BasicAliasAnalysis.cpp
stable/12/lib/clang/include/clang/Config/config.h
Directory Properties:
stable/12/ (props changed)
Modified:
stable/11/contrib/llvm-project/llvm/lib/Analysis/BasicAliasAnalysis.cpp
==
--- stable/11/contrib/llvm-project/llvm/lib/Analysis/BasicAliasAnalysis.cpp
Sun Jun 21 08:51:24 2020(r362460)
+++ stable/11/contrib/llvm-project/llvm/lib/Analysis/BasicAliasAnalysis.cpp
Sun Jun 21 09:24:47 2020(r362461)
@@ -2059,12 +2059,13 @@ char BasicAAWrapperPass::ID = 0;
void BasicAAWrapperPass::anchor() {}
INITIALIZE_PASS_BEGIN(BasicAAWrapperPass, "basicaa",
- "Basic Alias Analysis (stateless AA impl)", false, true)
+ "Basic Alias Analysis (stateless AA impl)", true, true)
INITIALIZE_PASS_DEPENDENCY(AssumptionCacheTracker)
INITIALIZE_PASS_DEPENDENCY(DominatorTreeWrapperPass)
INITIALIZE_PASS_DEPENDENCY(TargetLibraryInfoWrapperPass)
+INITIALIZE_PASS_DEPENDENCY(PhiValuesWrapperPass)
INITIALIZE_PASS_END(BasicAAWrapperPass, "basicaa",
-"Basic Alias Analysis (stateless AA impl)", false, true)
+"Basic Alias Analysis (stateless AA impl)", true, true)
FunctionPass *llvm::createBasicAAWrapperPass() {
return new BasicAAWrapperPass();
Modified: stable/11/lib/clang/include/clang/Config/config.h
==
--- stable/11/lib/clang/include/clang/Config/config.h Sun Jun 21 08:51:24
2020(r362460)
+++ stable/11/lib/clang/include/clang/Config/config.h Sun Jun 21 09:24:47
2020(r362461)
@@ -82,6 +82,6 @@
/* #undef CLANG_ENABLE_STATIC_ANALYZER */
/* Spawn a new process clang.exe for the CC1 tool invocation, when necessary */
-#define CLANG_SPAWN_CC1 1
+#define CLANG_SPAWN_CC1 0
#endif
___
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"
svn commit: r362460 - in head/sys: compat/cloudabi fs/devfs kern sys
Author: tmunro
Date: Sun Jun 21 08:51:24 2020
New Revision: 362460
URL: https://svnweb.freebsd.org/changeset/base/362460
Log:
vfs: track sequential reads and writes separately
For software like PostgreSQL and SQLite that sometimes reads sequentially
while also writing sequentially some distance behind with interleaved
syscalls on the same fd, performance is better on UFS if we do
sequential access heuristics separately for reads and writes.
Patch originally by Andrew Gierth in 2008, updated and proposed by me with
his permission.
Reviewed by: mjg, kib, tmunro
Approved by: mjg (mentor)
Obtained from:Andrew Gierth
Differential Revision:https://reviews.freebsd.org/D25024
Modified:
head/sys/compat/cloudabi/cloudabi_file.c
head/sys/fs/devfs/devfs_vnops.c
head/sys/kern/kern_descrip.c
head/sys/kern/vfs_syscalls.c
head/sys/kern/vfs_vnops.c
head/sys/sys/file.h
Modified: head/sys/compat/cloudabi/cloudabi_file.c
==
--- head/sys/compat/cloudabi/cloudabi_file.cSun Jun 21 04:59:02 2020
(r362459)
+++ head/sys/compat/cloudabi/cloudabi_file.cSun Jun 21 08:51:24 2020
(r362460)
@@ -287,7 +287,8 @@ cloudabi_sys_file_open(struct thread *td,
/* Install vnode operations if no custom operations are provided. */
if (fp->f_ops == ) {
- fp->f_seqcount = 1;
+ fp->f_seqcount[UIO_READ] = 1;
+ fp->f_seqcount[UIO_WRITE] = 1;
finit(fp, (fflags & FMASK) | (fp->f_flag & FHASLOCK),
DTYPE_VNODE, vp, );
}
Modified: head/sys/fs/devfs/devfs_vnops.c
==
--- head/sys/fs/devfs/devfs_vnops.c Sun Jun 21 04:59:02 2020
(r362459)
+++ head/sys/fs/devfs/devfs_vnops.c Sun Jun 21 08:51:24 2020
(r362460)
@@ -1305,7 +1305,7 @@ devfs_read_f(struct file *fp, struct uio *uio, struct
td->td_fpop = fpop;
dev_relthread(dev, ref);
- foffset_unlock_uio(fp, uio, flags | FOF_NOLOCK | FOF_NEXTOFF);
+ foffset_unlock_uio(fp, uio, flags | FOF_NOLOCK | FOF_NEXTOFF_R);
return (error);
}
@@ -1802,7 +1802,7 @@ devfs_write_f(struct file *fp, struct uio *uio, struct
td->td_fpop = fpop;
dev_relthread(dev, ref);
- foffset_unlock_uio(fp, uio, flags | FOF_NOLOCK | FOF_NEXTOFF);
+ foffset_unlock_uio(fp, uio, flags | FOF_NOLOCK | FOF_NEXTOFF_W);
return (error);
}
Modified: head/sys/kern/kern_descrip.c
==
--- head/sys/kern/kern_descrip.cSun Jun 21 04:59:02 2020
(r362459)
+++ head/sys/kern/kern_descrip.cSun Jun 21 08:51:24 2020
(r362460)
@@ -795,7 +795,7 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_
if (arg >= 0) {
bsize = fp->f_vnode->v_mount->mnt_stat.f_iosize;
arg = MIN(arg, INT_MAX - bsize + 1);
- fp->f_seqcount = MIN(IO_SEQMAX,
+ fp->f_seqcount[UIO_READ] = MIN(IO_SEQMAX,
(arg + bsize - 1) / bsize);
atomic_set_int(>f_flag, FRDAHEAD);
} else {
Modified: head/sys/kern/vfs_syscalls.c
==
--- head/sys/kern/vfs_syscalls.cSun Jun 21 04:59:02 2020
(r362459)
+++ head/sys/kern/vfs_syscalls.cSun Jun 21 08:51:24 2020
(r362460)
@@ -1124,7 +1124,8 @@ kern_openat(struct thread *td, int fd, const char *pat
*/
if (fp->f_ops == ) {
KASSERT(vp->v_type != VFIFO, ("Unexpected fifo."));
- fp->f_seqcount = 1;
+ fp->f_seqcount[UIO_READ] = 1;
+ fp->f_seqcount[UIO_WRITE] = 1;
finit(fp, (flags & FMASK) | (fp->f_flag & FHASLOCK),
DTYPE_VNODE, vp, );
}
@@ -4442,7 +4443,8 @@ sys_fhopen(struct thread *td, struct fhopen_args *uap)
td->td_dupfd = 0;
#endif
fp->f_vnode = vp;
- fp->f_seqcount = 1;
+ fp->f_seqcount[UIO_READ] = 1;
+ fp->f_seqcount[UIO_WRITE] = 1;
finit(fp, (fmode & FMASK) | (fp->f_flag & FHASLOCK), DTYPE_VNODE, vp,
);
VOP_UNLOCK(vp);
Modified: head/sys/kern/vfs_vnops.c
==
--- head/sys/kern/vfs_vnops.c Sun Jun 21 04:59:02 2020(r362459)
+++ head/sys/kern/vfs_vnops.c Sun Jun 21 08:51:24 2020(r362460)
@@ -489,10 +489,13 @@ vn_close(struct vnode *vp, int flags, struct ucred *fi
static int
sequential_heuristic(struct uio *uio, struct file *fp)
{
+ enum uio_rw rw;
ASSERT_VOP_LOCKED(fp->f_vnode, __func__);
+
+ rw = uio->uio_rw;
if (fp->f_flag & FRDAHEAD)
-
Re: svn commit: r362420 - head/share/misc
> On 20 Jun 2020, at 07:07, Warner Losh wrote: > > Author: imp > Date: Sat Jun 20 04:07:44 2020 > New Revision: 362420 > URL: https://svnweb.freebsd.org/changeset/base/362420 > > Log: > Correct 1BSD release date. > > The Quarter Century of Unix book said that 1BSD was released March 1979. > However, the 1BSD tape image that's on Kirk's historical unix collection has > an > earlier date. > > It was common practice, at the time, to create a new copy of the tape from > the > master system when a new tape was to go out, so several different versions of > 1BSD, etc were shipped from Berkerely. The date on the 1BSD tape in the > Berkeley > archives on Kirk's DVD is dated in January 16 1979 on the label, and has > dates > as late as Jan 29 (there's an UPDATE file that says this includes updates > through this date). Note this date as well. > > Modified: > head/share/misc/bsd-family-tree > > Modified: head/share/misc/bsd-family-tree > == > --- head/share/misc/bsd-family-tree Sat Jun 20 04:07:23 2020 > (r362419) > +++ head/share/misc/bsd-family-tree Sat Jun 20 04:07:44 2020 > (r362420) > @@ -477,6 +477,7 @@ Ninth Edition 1986-09-xx [QCU] > Tenth Edition 1989-10-xx [QCU] > > 1BSDlate 1977 > + 1978-01-16 [DOC] Ah, this is my birthday (too)! :) ___ 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"
