svn commit: r367037 - head/sys/arm64/arm64
Author: br
Date: Sun Oct 25 10:08:46 2020
New Revision: 367037
URL: https://svnweb.freebsd.org/changeset/base/367037
Log:
Add IOMMU support to GICv3 Interrupt Translation Service (ITS) driver.
Submitted by: andrew
Sponsored by: Innovate DSbD
Differential Revision:https://reviews.freebsd.org/D26878
Modified:
head/sys/arm64/arm64/gicv3_its.c
Modified: head/sys/arm64/arm64/gicv3_its.c
==
--- head/sys/arm64/arm64/gicv3_its.cSun Oct 25 07:48:07 2020
(r367036)
+++ head/sys/arm64/arm64/gicv3_its.cSun Oct 25 10:08:46 2020
(r367037)
@@ -32,6 +32,7 @@
#include "opt_acpi.h"
#include "opt_platform.h"
+#include "opt_iommu.h"
#include
__FBSDID("$FreeBSD$");
@@ -47,6 +48,8 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -56,6 +59,7 @@ __FBSDID("$FreeBSD$");
#include
#include
+#include
#include
#include
@@ -72,6 +76,11 @@ __FBSDID("$FreeBSD$");
#include
#include
+#ifdef IOMMU
+#include
+#include
+#endif
+
#include "pcib_if.h"
#include "pic_if.h"
#include "msi_if.h"
@@ -269,6 +278,7 @@ struct gicv3_its_softc {
#defineITS_FLAGS_ERRATA_CAVIUM_22375 0x0004
u_int sc_its_flags;
booltrace_enable;
+ vm_page_t ma; /* fake msi page */
};
static void *conf_base;
@@ -321,6 +331,10 @@ static msi_release_msi_t gicv3_its_release_msi;
static msi_alloc_msix_t gicv3_its_alloc_msix;
static msi_release_msix_t gicv3_its_release_msix;
static msi_map_msi_t gicv3_its_map_msi;
+#ifdef IOMMU
+static msi_iommu_init_t gicv3_iommu_init;
+static msi_iommu_deinit_t gicv3_iommu_deinit;
+#endif
static void its_cmd_movi(device_t, struct gicv3_its_irqsrc *);
static void its_cmd_mapc(device_t, struct its_col *, uint8_t);
@@ -352,6 +366,10 @@ static device_method_t gicv3_its_methods[] = {
DEVMETHOD(msi_alloc_msix, gicv3_its_alloc_msix),
DEVMETHOD(msi_release_msix, gicv3_its_release_msix),
DEVMETHOD(msi_map_msi, gicv3_its_map_msi),
+#ifdef IOMMU
+ DEVMETHOD(msi_iommu_init, gicv3_iommu_init),
+ DEVMETHOD(msi_iommu_deinit, gicv3_iommu_deinit),
+#endif
/* End */
DEVMETHOD_END
@@ -803,8 +821,9 @@ static int
gicv3_its_attach(device_t dev)
{
struct gicv3_its_softc *sc;
- uint32_t iidr;
int domain, err, i, rid;
+ uint64_t phys;
+ uint32_t iidr;
sc = device_get_softc(dev);
@@ -820,6 +839,11 @@ gicv3_its_attach(device_t dev)
return (ENXIO);
}
+ phys = rounddown2(vtophys(rman_get_virtual(sc->sc_its_res)) +
+ GITS_TRANSLATER, PAGE_SIZE);
+ sc->ma = malloc(sizeof(struct vm_page), M_DEVBUF, M_WAITOK | M_ZERO);
+ vm_page_initfake(sc->ma, phys, VM_MEMATTR_DEFAULT);
+
iidr = gic_its_read_4(sc, GITS_IIDR);
for (i = 0; i < nitems(its_quirks); i++) {
if ((iidr & its_quirks[i].iidr_mask) == its_quirks[i].iidr) {
@@ -1418,6 +1442,33 @@ gicv3_its_map_msi(device_t dev, device_t child, struct
return (0);
}
+
+#ifdef IOMMU
+static int
+gicv3_iommu_init(device_t dev, device_t child, struct iommu_domain **domain)
+{
+ struct gicv3_its_softc *sc;
+ struct iommu_ctx *ctx;
+ int error;
+
+ sc = device_get_softc(dev);
+ ctx = iommu_get_dev_ctx(child);
+ error = iommu_map_msi(ctx, PAGE_SIZE, GITS_TRANSLATER,
+ IOMMU_MAP_ENTRY_WRITE, IOMMU_MF_CANWAIT, &sc->ma);
+ *domain = iommu_get_ctx_domain(ctx);
+
+ return (error);
+}
+
+static void
+gicv3_iommu_deinit(device_t dev, device_t child)
+{
+ struct iommu_ctx *ctx;
+
+ ctx = iommu_get_dev_ctx(child);
+ iommu_unmap_msi(ctx);
+}
+#endif
/*
* Commands handling.
___
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: r366962 - in head: include usr.bin/calendar
Am 25.10.20 um 04:46 schrieb Rodney W. Grimes: On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes wrote: +#define _PATH_LOCALBASE "/usr/local" + Something feels very wrong about this becoming a defined path in base, it is further dependence on /usr/local which in the early days we spent a great deal of time removing. I believe the whole ports system allows this to be something other than /usr/local. Package should also allow it to be some other place. This removes a couple of instances of /usr/local being hardcoded and replaces with a define, so net it's better. No, its net worse as it now creates a define that is highly likely to propogate adding additional dependencies on this value. It could be even better, but this is slightly better than it was before. I disagree, as it is now easier for additional contamination of the base system. There already are places that hard-code /usr/local, and I do agree that this is architecturally bad, if you want to keep the base system and ports as independent from each other as possible. But I do disagree that this was worse than before, and I'd even consider replacing other verbatim occurrences of /usr/local with _PATH_LOCALBASE in our sources (but not introduce new references to LOCALBASE in base). This would simplify a grep for such source files, for example, and also to build base for systems with modified LOCALBASE. The following C header files in base (ignoring contrib) contain the string /usr/local: crypto/openssh/pathnames.h sys/sys/imgact_binmisc.h sys/contrib/openzfs/include/sys/lua/luaconf.h (FreeBSD specific?) usr.bin/fortune/fortune/pathnames.h usr.bin/mail/pathnames.h usr.sbin/cron/cron/pathnames.h usr.sbin/pkg/config.h usr.sbin/pciconf/pathnames.h usr.sbin/pciconf-xo/pathnames.h These are C source files that include that string: crypto/openssh/ssh-agent.c crypto/openssh/regress/unittests/sshkey/test_sshkey.c lib/libfetch/common.c lib/libc/rpc/getnetconfig.c lib/libc/nls/msgcat.c sbin/nvmecontrol/nvmecontrol.c sys/contrib/openzfs/cmd/zpool/zpool_main.c (FreeBSD specific?) tools/tools/ath/athprom/athprom.c tools/tools/net80211/wesside/wesside/wesside.c usr.bin/env/envopts.c usr.sbin/bsnmpd/tools/libbsnmptools/bsnmpimport.c usr.sbin/mailwrapper/mailwrapper.c usr.sbin/cpucontrol/cpucontrol.c I intend to prepare a review top make them use _PATH_LOCALBASE instead. (There might be sources under contrib that have no external up-stream anymore, but I have not made an attempt to identify them, yet.) There are 67 man-pages (excluding contrib) that mention /usr/local and they will not be covered by this C macro definition. There are further references to /usr/local, e.g. in 32 shell scripts (outside contrib). The next step could be to use the LOCALBASE variable that is defined in Makefile.inc1 to provide the value used to define _PATH_LOCALBASE in paths.h. This make variable is currently not used in bsd.prog.mk, but it easily could, allowing to override the value used to build the world in make.conf. But I'd suggest to go step by step, and the first step that I suggest (and am willing to work on) is to remove as many literal uses of /usr/local in C sources in base (excluding contrib) as reasonable. Maybe we should have some documentation about building the world for systems with non-default LOCALBASE ... Regards, STefan ___ 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: r366962 - in head: include usr.bin/calendar
Am 25.10.20 um 06:56 schrieb Alex Kozlov: On Sat, Oct 24, 2020 at 04:37:45PM +0200, Stefan Esser wrote: Am 24.10.20 um 09:48 schrieb Alex Kozlov: [...] You are hardcoding assumption that LOCALBASE = /usr/local. Please make it overridable with LOCALBASE environment variable. This was a trivial change to get us going with calendars provided by a port (which has not been committed, yet - therefore there are no port-provided calendars, neither under /usr/local nor under any other PREFIX, as of now). I understand what you are asking for, but in such a case I'd rather think you want to rebuild FreeBSD with _PATH_LOCALBASE modified in paths.h. The PREFIX != LOCALBASE and both != /usr/local configurations are supported in the ports tree and the base for a long time, please see https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html Yes, and I do not need to look that up in the handbook, having been a ports committer for 2 decades by now. If after this commit you need to rebuild base to use non-default LOCALBASE/PREFIX it is pretty big regression and POLA. How is that any different than before? What I did is make the PATH easier to change when you rebuild base. There are numerous programs in base that contain the literal string /usr/local - and what I did was implement a mechanism that allows to replace this literal reference with a simple change in paths.h. If you do not modify paths.h for a different LOCALBASE, then you'll get a wrong _PATH_DEFPATH compiled into your binaries, for example. And I have made this a single instance that needs to be changed. Before my change there were 2 instances of /usr/local hard-coded in _PATH_DEFPATH - now you have to only change the definition of _PATH_LOCALBASE to adjust all 3 locations that use it. I think you made situation worse, there were two stray hardcoded string and now there is official LOCALBASE define which likely will be used by other people in the future. I'd hope so to get rid of many of the 1713 literal uses of /usr/local in our source tree. If you can show me precedence of a LOCALBASE environment variable being used in the way you suggest, I'd be willing to make calendar use it. Just an analogy from LOCALBASE make variable, perhaps CALENDAR_HOME is a better name. Yes, I already suggested CALENDAR_HOME, but as an environment variable to check, if you want to be able to path an additional directory (or search path) to the calendar program at run-time. But why introduce a CALENDAR_HOME macro in the sources, if the port supplied calendar files are known to be found at LOCALBASE/share/calendar (for some value of LOCALBASE). I want to make more programs that currently hard-code /usr/local use _PATH_LOCALBASE instead. This C macro can then be default to /usr/local but can be overridden by passing LOCALBASE to the compiler (from the build infrastructure) when paths.h is included. Instead of referring to _PATH_LOCALBASE these files could directly use LOCALBASE, but since other paths are defined as _PATH_xxx in paths.h I think it is best to follow this precedent. But then I think a CALENDAR_HOME variable would be even more useful, since it would allow to search an additional user selected directory (and not just share/calendar within what you provide as LOCALBASE). My change did not add any dependency on LOCALBASE to any previously existing functionality. It added support for calendar files provided by a port (a feature that did not exist before) at a location that is correct for the big majority of users (who do not modify LOCALBASE). As I said: I'm going to make it easier to build the base system with a different LOCALBASE, but not by run-time checking an environment variable that specifies LOCALBASE in each affected program. Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
svn commit: r367038 - head/sbin/mount_nullfs
Author: trasz
Date: Sun Oct 25 14:09:00 2020
New Revision: 367038
URL: https://svnweb.freebsd.org/changeset/base/367038
Log:
Remove the check that prevents creating "loops" from mount_nullfs(8).
Reviewed by: kib
MFC after:2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision:https://reviews.freebsd.org/D26921
Modified:
head/sbin/mount_nullfs/mount_nullfs.c
Modified: head/sbin/mount_nullfs/mount_nullfs.c
==
--- head/sbin/mount_nullfs/mount_nullfs.c Sun Oct 25 10:08:46 2020
(r367037)
+++ head/sbin/mount_nullfs/mount_nullfs.c Sun Oct 25 14:09:00 2020
(r367038)
@@ -59,7 +59,6 @@ static const char rcsid[] =
#include "mntopts.h"
-intsubdir(const char *, const char *);
static voidusage(void) __dead2;
int
@@ -104,10 +103,6 @@ main(int argc, char *argv[])
if (checkpath(argv[1], source) != 0)
err(EX_USAGE, "%s", source);
- if (subdir(target, source) || subdir(source, target))
- errx(EX_USAGE, "%s (%s) and %s are not distinct paths",
- argv[0], target, argv[1]);
-
build_iovec(&iov, &iovlen, "fstype", nullfs, (size_t)-1);
build_iovec(&iov, &iovlen, "fspath", source, (size_t)-1);
build_iovec(&iov, &iovlen, "target", target, (size_t)-1);
@@ -119,21 +114,6 @@ main(int argc, char *argv[])
err(1, "%s", source);
}
exit(0);
-}
-
-int
-subdir(const char *p, const char *dir)
-{
- int l;
-
- l = strlen(dir);
- if (l <= 1)
- return (1);
-
- if ((strncmp(p, dir, l) == 0) && (p[l] == '/' || p[l] == '\0'))
- return (1);
-
- return (0);
}
static void
___
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: r367038 - head/sbin/mount_nullfs
On Sunday, October 25, 2020, Edward Tomasz Napierala
wrote:
> Author: trasz
> Date: Sun Oct 25 14:09:00 2020
> New Revision: 367038
> URL: https://svnweb.freebsd.org/changeset/base/367038
>
> Log:
> Remove the check that prevents creating "loops" from mount_nullfs(8).
>
>
The simple question is: why?
> Reviewed by: kib
> MFC after:2 weeks
> Sponsored by: The FreeBSD Foundation
> Differential Revision:https://reviews.freebsd.org/D26921
>
> Modified:
> head/sbin/mount_nullfs/mount_nullfs.c
>
> Modified: head/sbin/mount_nullfs/mount_nullfs.c
>
> ==
> --- head/sbin/mount_nullfs/mount_nullfs.c Sun Oct 25 10:08:46 2020
> (r367037)
> +++ head/sbin/mount_nullfs/mount_nullfs.c Sun Oct 25 14:09:00 2020
> (r367038)
> @@ -59,7 +59,6 @@ static const char rcsid[] =
>
> #include "mntopts.h"
>
> -intsubdir(const char *, const char *);
> static voidusage(void) __dead2;
>
> int
> @@ -104,10 +103,6 @@ main(int argc, char *argv[])
> if (checkpath(argv[1], source) != 0)
> err(EX_USAGE, "%s", source);
>
> - if (subdir(target, source) || subdir(source, target))
> - errx(EX_USAGE, "%s (%s) and %s are not distinct paths",
> - argv[0], target, argv[1]);
> -
> build_iovec(&iov, &iovlen, "fstype", nullfs, (size_t)-1);
> build_iovec(&iov, &iovlen, "fspath", source, (size_t)-1);
> build_iovec(&iov, &iovlen, "target", target, (size_t)-1);
> @@ -119,21 +114,6 @@ main(int argc, char *argv[])
> err(1, "%s", source);
> }
> exit(0);
> -}
> -
> -int
> -subdir(const char *p, const char *dir)
> -{
> - int l;
> -
> - l = strlen(dir);
> - if (l <= 1)
> - return (1);
> -
> - if ((strncmp(p, dir, l) == 0) && (p[l] == '/' || p[l] == '\0'))
> - return (1);
> -
> - return (0);
> }
>
> static void
> ___
> 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-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: r367038 - head/sbin/mount_nullfs
In message , Oliver Pinter writes: > On Sunday, October 25, 2020, Edward Tomasz Napierala > wrote: > > > Author: trasz > > Date: Sun Oct 25 14:09:00 2020 > > New Revision: 367038 > > URL: https://svnweb.freebsd.org/changeset/base/367038 > > > > Log: > > Remove the check that prevents creating "loops" from mount_nullfs(8). > > > > > The simple question is: why? I was about to ask that myself. The why is usually more important than the how. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. ___ 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: r367039 - head/sbin/ifconfig
Author: 0mp (doc,ports committer) Date: Sun Oct 25 15:01:01 2020 New Revision: 367039 URL: https://svnweb.freebsd.org/changeset/base/367039 Log: ifconfig.8: Remove spurious commas Correct misuse of commas/parentheses in an enumeration that makes the number of actual parameters more important than expected. PR: 250526 Submitted by: Samy Mahmoudi MFC after:1 week Modified: head/sbin/ifconfig/ifconfig.8 Modified: head/sbin/ifconfig/ifconfig.8 == --- head/sbin/ifconfig/ifconfig.8 Sun Oct 25 14:09:00 2020 (r367038) +++ head/sbin/ifconfig/ifconfig.8 Sun Oct 25 15:01:01 2020 (r367039) @@ -28,7 +28,7 @@ .\" From: @(#)ifconfig.8 8.3 (Berkeley) 1/5/94 .\" $FreeBSD$ .\" -.Dd October 21, 2020 +.Dd October 25, 2020 .Dt IFCONFIG 8 .Os .Sh NAME @@ -884,10 +884,10 @@ is one of .Cm ahdemo (or .Cm adhoc-demo ) , -.Cm ibss , +.Cm ibss (or .Cm adhoc ) , -.Cm ap , +.Cm ap (or .Cm hostap ) , .Cm wds , ___ 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: r366962 - in head: include usr.bin/calendar
On Sun, Oct 25, 2020 at 5:21 AM Stefan Esser wrote: > > Am 25.10.20 um 04:46 schrieb Rodney W. Grimes: > >> On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes > >> > >> wrote: > +#define _PATH_LOCALBASE "/usr/local" > + > >>> > >>> Something feels very wrong about this becoming a defined path in base, > >>> it is further dependence on /usr/local which in the early days we spent > >>> a great deal of time removing. > >>> > >>> I believe the whole ports system allows this to be something other > >>> than /usr/local. Package should also allow it to be some other place. > >>> > >> > >> This removes a couple of instances of /usr/local being hardcoded and > >> replaces with a define, so net it's better. > > > > No, its net worse as it now creates a define that is highly likely > > to propogate adding additional dependencies on this value. > > > >> > >> It could be even better, but this is slightly better than it was before. > > > > I disagree, as it is now easier for additional contamination of > > the base system. > > There already are places that hard-code /usr/local, and I do agree > that this is architecturally bad, if you want to keep the base system > and ports as independent from each other as possible. > > But I do disagree that this was worse than before, and I'd even consider > replacing other verbatim occurrences of /usr/local with _PATH_LOCALBASE > in our sources (but not introduce new references to LOCALBASE in base). > > This would simplify a grep for such source files, for example, and also > to build base for systems with modified LOCALBASE. > > The following C header files in base (ignoring contrib) contain the > string /usr/local: > > ... > sys/contrib/openzfs/include/sys/lua/luaconf.h (FreeBSD specific?) > ... I see that you've excluded sys/contrib from the initial review, but I would not bother with luaconf.h in particular. These definitions just come from a stock Lua 5.2 and are not used in a ZFS context, they've ripped out loadlib and anything else that could try. Thanks, Kyle Evans ___ 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: r367040 - head/usr.bin/calendar
Author: 0mp (doc,ports committer) Date: Sun Oct 25 16:01:03 2020 New Revision: 367040 URL: https://svnweb.freebsd.org/changeset/base/367040 Log: calendar.1: Fix locale of the month in Dd ;) Modified: head/usr.bin/calendar/calendar.1 Modified: head/usr.bin/calendar/calendar.1 == --- head/usr.bin/calendar/calendar.1Sun Oct 25 15:01:01 2020 (r367039) +++ head/usr.bin/calendar/calendar.1Sun Oct 25 16:01:03 2020 (r367040) @@ -28,7 +28,7 @@ .\" @(#)calendar.1 8.1 (Berkeley) 6/29/93 .\" $FreeBSD$ .\" -.Dd Oktober 23, 2020 +.Dd October 23, 2020 .Dt CALENDAR 1 .Os .Sh NAME ___ 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: r366962 - in head: include usr.bin/calendar
On Sun, Oct 25, 2020, 9:04 AM Kyle Evans wrote: > On Sun, Oct 25, 2020 at 5:21 AM Stefan Esser wrote: > > > > Am 25.10.20 um 04:46 schrieb Rodney W. Grimes: > > >> On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes < > free...@gndrsh.dnsmgr.net> > > >> wrote: > > +#define _PATH_LOCALBASE "/usr/local" > > + > > >>> > > >>> Something feels very wrong about this becoming a defined path in > base, > > >>> it is further dependence on /usr/local which in the early days we > spent > > >>> a great deal of time removing. > > >>> > > >>> I believe the whole ports system allows this to be something other > > >>> than /usr/local. Package should also allow it to be some other > place. > > >>> > > >> > > >> This removes a couple of instances of /usr/local being hardcoded and > > >> replaces with a define, so net it's better. > > > > > > No, its net worse as it now creates a define that is highly likely > > > to propogate adding additional dependencies on this value. > > > > > >> > > >> It could be even better, but this is slightly better than it was > before. > > > > > > I disagree, as it is now easier for additional contamination of > > > the base system. > > > > There already are places that hard-code /usr/local, and I do agree > > that this is architecturally bad, if you want to keep the base system > > and ports as independent from each other as possible. > > > > But I do disagree that this was worse than before, and I'd even consider > > replacing other verbatim occurrences of /usr/local with _PATH_LOCALBASE > > in our sources (but not introduce new references to LOCALBASE in base). > > > > This would simplify a grep for such source files, for example, and also > > to build base for systems with modified LOCALBASE. > > > > The following C header files in base (ignoring contrib) contain the > > string /usr/local: > > > > ... > > sys/contrib/openzfs/include/sys/lua/luaconf.h (FreeBSD specific?) > > ... > > I see that you've excluded sys/contrib from the initial review, but I > would not bother with luaconf.h in particular. These definitions just > come from a stock Lua 5.2 and are not used in a ZFS context, they've > ripped out loadlib and anything else that could try. > As an aside: I looked at using this Lua for the boot loader, but quickly found that it was no good for that purpose due to changes like that. And it was too far hacked from 5.2 to try to update easily... Warner Thanks, > > Kyle Evans > ___ 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: r367041 - head/sys/dev/ocs_fc
Author: mav Date: Sun Oct 25 16:58:48 2020 New Revision: 367041 URL: https://svnweb.freebsd.org/changeset/base/367041 Log: Fix incorrect constants of target tag action. ocs_scsi_recv_cmd() receives the flags after ocs_get_flags_fcp_cmd(), which translates them from FCP_TASK_ATTR_* to OCS_SCSI_CMD_*. As result non-SIMPLE requests turned into HEAD or ORDERED depending on direction. MFC after:2 weeks Modified: head/sys/dev/ocs_fc/ocs_cam.c Modified: head/sys/dev/ocs_fc/ocs_cam.c == --- head/sys/dev/ocs_fc/ocs_cam.c Sun Oct 25 16:01:03 2020 (r367040) +++ head/sys/dev/ocs_fc/ocs_cam.c Sun Oct 25 16:58:48 2020 (r367041) @@ -576,9 +576,9 @@ int32_t ocs_scsi_recv_cmd(ocs_io_t *io, uint64_t lun, if (flags & OCS_SCSI_CMD_SIMPLE) atio->tag_action = MSG_SIMPLE_Q_TAG; - else if (flags & FCP_TASK_ATTR_HEAD_OF_QUEUE) + else if (flags & OCS_SCSI_CMD_HEAD_OF_QUEUE) atio->tag_action = MSG_HEAD_OF_Q_TAG; - else if (flags & FCP_TASK_ATTR_ORDERED) + else if (flags & OCS_SCSI_CMD_ORDERED) atio->tag_action = MSG_ORDERED_Q_TAG; else atio->tag_action = 0; ___ 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: r367042 - head/usr.sbin/mergemaster
Author: emaste
Date: Sun Oct 25 18:06:45 2020
New Revision: 367042
URL: https://svnweb.freebsd.org/changeset/base/367042
Log:
mergemaster: Clarify installed and updated versions
Describe "diff installed new" as "Displaying differences between
installed and new." Previously mergemaster described them in the
opposite order.
PR: 249214
Reported by: Yuri Victorovich
MFC after:2 weeks
Modified:
head/usr.sbin/mergemaster/mergemaster.sh
Modified: head/usr.sbin/mergemaster/mergemaster.sh
==
--- head/usr.sbin/mergemaster/mergemaster.shSun Oct 25 16:58:48 2020
(r367041)
+++ head/usr.sbin/mergemaster/mergemaster.shSun Oct 25 18:06:45 2020
(r367042)
@@ -143,7 +143,7 @@ diff_loop () {
echo '
== '
echo ''
(
- echo " *** Displaying differences between ${COMPFILE} and installed
version:"
+ echo " *** Displaying differences between installed version and
${COMPFILE}:"
echo ''
diff ${DIFF_FLAG} ${DIFF_OPTIONS} "${DESTDIR}${COMPFILE#.}"
"${COMPFILE}"
) | ${PAGER}
___
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: r366993 - head/sys/net
On 10/24/20 8:19 PM, Ed Maste wrote: On Sat, 24 Oct 2020 at 11:27, Warner Losh wrote: Given we already have nice .clang-format, that does most of the job, maybe it's worth considering looking into tweaking it further to fix this part? It would be nice if we could finally offload all formatting issues to the tool and focus on the actual code :-) It would be nice if it produced one of the style(9) acceptable formats without disrupting things already acceptable. That's been the big problem with the tweaks to date... some things are fixed, others break. It's getting a lot closer, though Upstream clang-format comes with a script that can integrate with git, adding a `git clang-format` command. It will apply formatting to modified lines, leaving unchanged ones alone. I doubt any script can match style(9) perfectly. indent(1) with bde's flags came near in some edge cases but generally did a horrible job. Also, out style(9) is not mandatory for userland. Pedro. ___ 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: r367043 - head/libexec/rc/rc.d
Author: emaste
Date: Sun Oct 25 18:27:21 2020
New Revision: 367043
URL: https://svnweb.freebsd.org/changeset/base/367043
Log:
rc.d/syscons: remove spaces before tab
Modified:
head/libexec/rc/rc.d/syscons
Modified: head/libexec/rc/rc.d/syscons
==
--- head/libexec/rc/rc.d/sysconsSun Oct 25 18:06:45 2020
(r367042)
+++ head/libexec/rc/rc.d/sysconsSun Oct 25 18:27:21 2020
(r367043)
@@ -151,7 +151,7 @@ kbdcontrol_load_keymap()
if [ -n "${keymap_vt}" ]; then
errmsg=`kbdcontrol < ${kbddev} -l ${keymap_vt} 2>&1`
if [ -z "${errmsg}" ]; then
- _sc_keymap_msg="New keymap: In /etc/rc.conf
replace 'keymap=${keymap}' by 'keymap=${keymap_vt}'"
+ _sc_keymap_msg="New keymap: In /etc/rc.conf
replace 'keymap=${keymap}' by 'keymap=${keymap_vt}'"
fi
else
_sc_keymap_msg="No replacement found for keymap
'${keymap}'.
___
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: r367044 - in head/sys: cam cam/ctl dev/iscsi dev/isp dev/mpr dev/mps dev/ocs_fc
Author: mav
Date: Sun Oct 25 19:34:02 2020
New Revision: 367044
URL: https://svnweb.freebsd.org/changeset/base/367044
Log:
Introduce support of SCSI Command Priority.
SAM-3 specification introduced concept of Task Priority, that was renamed
to Command Priority in SAM-4, and supported by all modern SCSI transports.
It provides 15 levels of relative priorities: 1 - highest, 15 - lowest and
0 - default. SAT specification for SATA devices translates priorities 1-3
into NCQ high priority.
This change adds new "priority" field into empty spots of struct ccb_scsiio
and struct ccb_accept_tio of CAM and struct ctl_scsiio of CTL. Respective
support is added into iscsi(4), isp(4), mpr(4), mps(4) and ocs_fc(4) drivers
for both initiator and where applicable target roles. Minimal support was
added to CTL to receive the priority value from different frontends, pass it
between HA controllers and report in few places.
This patch does not add consumers of this functionality, so nothing should
really change yet, since the field is still set to 0 (default) on initiator
and not actively used on target. Those are to be implemented separately.
I've confirmed priority working on WD Red SATA disks connected via mpr(4)
and properly transferred to CTL target via iscsi(4), isp(4) and ocs_fc(4).
While there, added missing tag_action support to ocs_fc(4) initiator role.
MFC after:1 month
Relnotes: yes
Sponsored by: iXsystems, Inc.
Modified:
head/sys/cam/cam_ccb.h
head/sys/cam/ctl/ctl.c
head/sys/cam/ctl/ctl_frontend_cam_sim.c
head/sys/cam/ctl/ctl_frontend_iscsi.c
head/sys/cam/ctl/ctl_io.h
head/sys/cam/ctl/ctl_util.c
head/sys/cam/ctl/scsi_ctl.c
head/sys/dev/iscsi/iscsi.c
head/sys/dev/isp/isp.c
head/sys/dev/isp/isp_freebsd.c
head/sys/dev/isp/isp_freebsd.h
head/sys/dev/isp/isp_stds.h
head/sys/dev/isp/ispvar.h
head/sys/dev/mpr/mpr_sas.c
head/sys/dev/mps/mps_sas.c
head/sys/dev/ocs_fc/ocs_cam.c
head/sys/dev/ocs_fc/ocs_scsi.c
head/sys/dev/ocs_fc/ocs_scsi.h
head/sys/dev/ocs_fc/ocs_unsol.c
Modified: head/sys/cam/cam_ccb.h
==
--- head/sys/cam/cam_ccb.h Sun Oct 25 18:27:21 2020(r367043)
+++ head/sys/cam/cam_ccb.h Sun Oct 25 19:34:02 2020(r367044)
@@ -758,6 +758,7 @@ struct ccb_scsiio {
* from scsi_message.h.
*/
#defineCAM_TAG_ACTION_NONE 0x00
+ uint8_tpriority;/* Command priority for SIMPLE tag */
u_int tag_id; /* tag id from initator (target mode) */
u_int init_id; /* initiator id of who selected */
#if defined(BUF_TRACKING) || defined(FULL_BUF_TRACKING)
@@ -805,6 +806,7 @@ struct ccb_accept_tio {
u_int8_t cdb_len; /* Number of bytes for the CDB */
u_int8_t tag_action; /* What to do for tag queueing */
u_int8_t sense_len; /* Number of bytes of Sense Data */
+ uint8_tpriority;/* Command priority for SIMPLE tag */
u_int tag_id; /* tag id from initator (target mode) */
u_int init_id; /* initiator id of who selected */
struct scsi_sense_data sense_data;
@@ -1392,6 +1394,7 @@ cam_fill_csio(struct ccb_scsiio *csio, u_int32_t retri
csio->sense_len = sense_len;
csio->cdb_len = cdb_len;
csio->tag_action = tag_action;
+ csio->priority = 0;
#if defined(BUF_TRACKING) || defined(FULL_BUF_TRACKING)
csio->bio = NULL;
#endif
@@ -1414,6 +1417,7 @@ cam_fill_ctio(struct ccb_scsiio *csio, u_int32_t retri
csio->dxfer_len = dxfer_len;
csio->scsi_status = scsi_status;
csio->tag_action = tag_action;
+ csio->priority = 0;
csio->tag_id = tag_id;
csio->init_id = init_id;
}
Modified: head/sys/cam/ctl/ctl.c
==
--- head/sys/cam/ctl/ctl.c Sun Oct 25 18:27:21 2020(r367043)
+++ head/sys/cam/ctl/ctl.c Sun Oct 25 19:34:02 2020(r367044)
@@ -1457,6 +1457,7 @@ ctl_isc_event_handler(ctl_ha_channel channel, ctl_ha_e
if (softc->ha_mode != CTL_HA_MODE_XFER)
io->io_hdr.flags |= CTL_FLAG_INT_COPY;
io->io_hdr.nexus = msg->hdr.nexus;
+ io->scsiio.priority = msg->scsi.priority;
io->scsiio.tag_num = msg->scsi.tag_num;
io->scsiio.tag_type = msg->scsi.tag_type;
#ifdef CTL_TIME_IO
@@ -11603,8 +11604,9 @@ ctl_scsiio_precheck(struct ctl_softc *softc, struct ct
msg_info.hdr.nexus = ctsio->io_hdr.nexus;
msg_info.scsi.tag_num = ctsio->tag_num;
msg_info.scsi.tag_type = ctsio->tag_type;
- msg_info.scsi.cdb_len = ctsio->cdb_len;
svn commit: r367045 - head/sbin/fsck_ffs
Author: mckusick
Date: Sun Oct 25 21:04:07 2020
New Revision: 367045
URL: https://svnweb.freebsd.org/changeset/base/367045
Log:
Use proper type (ino_t) for inode numbers to avoid improper sign extention
in the Pass 5 checks. The manifestation was fsck_ffs exiting with this error:
** Phase 5 - Check Cyl groups
fsck_ffs: inoinfo: inumber 18446744071562087424 out of range
The error only manifests itself for filesystems bigger than about 100Tb.
Reported by: Nikita Grechikhin
MFC after:2 weeks
Sponsored by: Netflix
Modified:
head/sbin/fsck_ffs/pass5.c
Modified: head/sbin/fsck_ffs/pass5.c
==
--- head/sbin/fsck_ffs/pass5.c Sun Oct 25 19:34:02 2020(r367044)
+++ head/sbin/fsck_ffs/pass5.c Sun Oct 25 21:04:07 2020(r367045)
@@ -63,6 +63,7 @@ pass5(void)
struct fs *fs = &sblock;
ufs2_daddr_t d, dbase, dmax, start;
int rewritecg = 0;
+ ino_t inum;
struct csum *cs;
struct csum_total cstotal;
struct inodesc idesc[3];
@@ -238,9 +239,9 @@ pass5(void)
}
memset(&newcg->cg_frsum[0], 0, sizeof newcg->cg_frsum);
memset(cg_inosused(newcg), 0, (size_t)(mapsize));
- j = fs->fs_ipg * c;
- for (i = 0; i < inostathead[c].il_numalloced; j++, i++) {
- switch (inoinfo(j)->ino_state) {
+ inum = fs->fs_ipg * c;
+ for (i = 0; i < inostathead[c].il_numalloced; inum++, i++) {
+ switch (inoinfo(inum)->ino_state) {
case USTATE:
break;
@@ -260,10 +261,10 @@ pass5(void)
break;
default:
- if (j < (int)UFS_ROOTINO)
+ if (inum < UFS_ROOTINO)
break;
- errx(EEXIT, "BAD STATE %d FOR INODE I=%d",
- inoinfo(j)->ino_state, j);
+ errx(EEXIT, "BAD STATE %d FOR INODE I=%ju",
+ inoinfo(inum)->ino_state, (uintmax_t)inum);
}
}
if (c == 0)
___
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: r367038 - head/sbin/mount_nullfs
On 1025T0717, Cy Schubert wrote: > In message om> > , Oliver Pinter writes: > > On Sunday, October 25, 2020, Edward Tomasz Napierala > > wrote: > > > > > Author: trasz > > > Date: Sun Oct 25 14:09:00 2020 > > > New Revision: 367038 > > > URL: https://svnweb.freebsd.org/changeset/base/367038 > > > > > > Log: > > > Remove the check that prevents creating "loops" from mount_nullfs(8). > > > > > > > > The simple question is: why? > > I was about to ask that myself. > > The why is usually more important than the how. Two reasons. First, from what I can tell this is an artificial limitation which serves no purpose. I thought it was to prevent some kind of deadlock between vnodes, so I asked kib@, and he mentioned removing that very limitation from the kernel code; thus, it looks to me like a historical leftover. Second, I've stumbled upon this when trying to nullfs-mount '/' on '/compat/ubuntu/bsd/', which would be useful for autochroot functionality, when (or if) it becomes a thing. ___ 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: r367038 - head/sbin/mount_nullfs
On Sunday, October 25, 2020, Edward Tomasz Napierala wrote: > On 1025T0717, Cy Schubert wrote: > > In message gmail.c > > om> > > , Oliver Pinter writes: > > > On Sunday, October 25, 2020, Edward Tomasz Napierala < > tr...@freebsd.org> > > > wrote: > > > > > > > Author: trasz > > > > Date: Sun Oct 25 14:09:00 2020 > > > > New Revision: 367038 > > > > URL: https://svnweb.freebsd.org/changeset/base/367038 > > > > > > > > Log: > > > > Remove the check that prevents creating "loops" from > mount_nullfs(8). > > > > > > > > > > > The simple question is: why? > > > > I was about to ask that myself. > > > > The why is usually more important than the how. > > Two reasons. > > First, from what I can tell this is an artificial limitation which serves > no purpose. I thought it was to prevent some kind of deadlock between > vnodes, so I asked kib@, and he mentioned removing that very limitation > from the kernel code; thus, it looks to me like a historical leftover. > > Second, I've stumbled upon this when trying to nullfs-mount '/' on > '/compat/ubuntu/bsd/', which would be useful for autochroot functionality, > when (or if) it becomes a thing. Thank you! ___ 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: r367038 - head/sbin/mount_nullfs
In message <20201025213509.GA1671@brick>, Edward Tomasz Napierala writes: > On 1025T0717, Cy Schubert wrote: > > In message c > > om> > > , Oliver Pinter writes: > > > On Sunday, October 25, 2020, Edward Tomasz Napierala > > > wrote: > > > > > > > Author: trasz > > > > Date: Sun Oct 25 14:09:00 2020 > > > > New Revision: 367038 > > > > URL: https://svnweb.freebsd.org/changeset/base/367038 > > > > > > > > Log: > > > > Remove the check that prevents creating "loops" from mount_nullfs(8). > > > > > > > > > > > The simple question is: why? > > > > I was about to ask that myself. > > > > The why is usually more important than the how. > > Two reasons. > > First, from what I can tell this is an artificial limitation which serves > no purpose. I thought it was to prevent some kind of deadlock between > vnodes, so I asked kib@, and he mentioned removing that very limitation > from the kernel code; thus, it looks to me like a historical leftover. > > Second, I've stumbled upon this when trying to nullfs-mount '/' on > '/compat/ubuntu/bsd/', which would be useful for autochroot functionality, > when (or if) it becomes a thing. Thanks. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. ___ 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: r366962 - in head: include usr.bin/calendar
[ Charset ISO-8859-1 unsupported, converting... ] > On Sat, Oct 24, 2020 at 04:37:45PM +0200, Stefan Esser wrote: > > Am 24.10.20 um 09:48 schrieb Alex Kozlov: > > > On Fri, Oct 23, 2020 at 09:22:23AM +, Stefan E?er wrote: > > > > Author: se > > > > Date: Fri Oct 23 09:22:23 2020 > > > > New Revision: 366962 > > > > URL: https://svnweb.freebsd.org/changeset/base/366962 > > > > > > > > Log: > > > >Add search of LOCALBASE/share/calendar for calendars supplied by a > > > > port. > > > >Calendar files in LOCALBASE override similarily named ones in the > > > > base > > > >system. This could easily be changed if the base system calendars > > > > should > > > >have precedence, but it could lead to a violation of POLA since then > > > > the > > > >port's files were ignored unless those in base have been deleted. > > > >There was no definition of _PATH_LOCALBASE in paths.h, but verbatim > > > > uses > > > >of /usr/local existed for _PATH_DEFPATH. Use _PATH_LOCALBASE here to > > > > ease > > > >a consistent modification of this prefix. > > > You are hardcoding assumption that LOCALBASE = /usr/local. Please make it > > > overridable with LOCALBASE environment variable. > > This was a trivial change to get us going with calendars provided by > > a port (which has not been committed, yet - therefore there are no > > port-provided calendars, neither under /usr/local nor under any other > > PREFIX, as of now). > > > I understand what you are asking for, but in such a case I'd rather > > think you want to rebuild FreeBSD with _PATH_LOCALBASE modified in > > paths.h. > The PREFIX != LOCALBASE and both != /usr/local configurations > are supported in the ports tree and the base for a long time, please see > https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html Seems all that work for all them years is about to be tossed out the window as "an out dated concept". > > If after this commit you need to rebuild base to use non-default > LOCALBASE/PREFIX > it is pretty big regression and POLA. I guess no one is paying attention to any of this... > > And I have made this a single instance that needs to be changed. > > Before my change there were 2 instances of /usr/local hard-coded > > in _PATH_DEFPATH - now you have to only change the definition of > > _PATH_LOCALBASE to adjust all 3 locations that use it. > I think you made situation worse, there were two stray hardcoded > string and now there is official LOCALBASE define which likely will be > used by other people in the future. Yep, and now that propogation is about to occur. > > > If you can show me precedence of a LOCALBASE environment variable > > being used in the way you suggest, I'd be willing to make calendar > > use it. > Just an analogy from LOCALBASE make variable, perhaps CALENDAR_HOME > is a better name. > > > But then I think a CALENDAR_HOME variable would be even more useful, > > since it would allow to search an additional user selected directory > > (and not just share/calendar within what you provide as LOCALBASE). > > > > Regards, STefan > > > > PS: If you are a source committer, you might even commit such a > > change yourself. But I'd think it should be reviewed, and it > > might be a good idea to wait until other changes (e.g. the > > switch-over to port-supplied calendar files) have been worked > > out. > > > -- > Alex > -- 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: r367048 - head/lib/libc/sys
Author: jmg Date: Mon Oct 26 00:37:31 2020 New Revision: 367048 URL: https://svnweb.freebsd.org/changeset/base/367048 Log: update write(2)'s iovec limit w/ info about the iosize_max_clamp sysctl... Modified: head/lib/libc/sys/write.2 Modified: head/lib/libc/sys/write.2 == --- head/lib/libc/sys/write.2 Sun Oct 25 23:26:07 2020(r367047) +++ head/lib/libc/sys/write.2 Mon Oct 26 00:37:31 2020(r367048) @@ -28,7 +28,7 @@ .\" @(#)write.28.5 (Berkeley) 4/2/94 .\" $FreeBSD$ .\" -.Dd March 30, 2020 +.Dd October 25, 2020 .Dt WRITE 2 .Os .Sh NAME @@ -240,9 +240,13 @@ array was negative. .It Bq Er EINVAL The sum of the .Fa iov_len -values in the -.Fa iov -array overflowed a 32-bit integer. +values is greater than +.Dv SSIZE_MAX +(or greater than +.Dv INT_MAX , +if the sysctl +.Va debug.iosize_max_clamp +is non-zero). .It Bq Er ENOBUFS The mbuf pool has been completely exhausted when writing to a socket. .El ___ 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: r367048 - head/lib/libc/sys
In message <202010260037.09q0bvpn090...@repo.freebsd.org>, John-Mark Gurney wri tes: > Author: jmg > Date: Mon Oct 26 00:37:31 2020 > New Revision: 367048 > URL: https://svnweb.freebsd.org/changeset/base/367048 > > Log: > update write(2)'s iovec limit w/ info about the iosize_max_clamp sysctl... > > Modified: > head/lib/libc/sys/write.2 > > Modified: head/lib/libc/sys/write.2 > = > = > --- head/lib/libc/sys/write.2 Sun Oct 25 23:26:07 2020(r367047) > +++ head/lib/libc/sys/write.2 Mon Oct 26 00:37:31 2020(r367048) > @@ -28,7 +28,7 @@ > .\" @(#)write.2 8.5 (Berkeley) 4/2/94 > .\" $FreeBSD$ > .\" > -.Dd March 30, 2020 > +.Dd October 25, 2020 > .Dt WRITE 2 > .Os > .Sh NAME > @@ -240,9 +240,13 @@ array was negative. > .It Bq Er EINVAL > The sum of the > .Fa iov_len > -values in the > -.Fa iov > -array overflowed a 32-bit integer. > +values is greater than > +.Dv SSIZE_MAX > +(or greater than > +.Dv INT_MAX , > +if the sysctl > +.Va debug.iosize_max_clamp Should we also include SEE ALSO reference to sysctl(8) or sysctl(3)? Personally I think a reference to sysctl(8) would be more apropos. > +is non-zero). > .It Bq Er ENOBUFS > The mbuf pool has been completely exhausted when writing to a socket. > .El > -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. ___ 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: r367048 - head/lib/libc/sys
In message <202010260059.09q0xbxt003...@slippy.cwsent.com>, Cy Schubert writes: > In message <202010260037.09q0bvpn090...@repo.freebsd.org>, John-Mark Gurney > wri > tes: > > Author: jmg > > Date: Mon Oct 26 00:37:31 2020 > > New Revision: 367048 > > URL: https://svnweb.freebsd.org/changeset/base/367048 > > > > Log: > > update write(2)'s iovec limit w/ info about the iosize_max_clamp sysctl.. > . > > > > Modified: > > head/lib/libc/sys/write.2 > > > > Modified: head/lib/libc/sys/write.2 > > === > == > > = > > --- head/lib/libc/sys/write.2 Sun Oct 25 23:26:07 2020(r36704 > 7) > > +++ head/lib/libc/sys/write.2 Mon Oct 26 00:37:31 2020(r36704 > 8) > > @@ -28,7 +28,7 @@ > > .\" @(#)write.28.5 (Berkeley) 4/2/94 > > .\" $FreeBSD$ > > .\" > > -.Dd March 30, 2020 > > +.Dd October 25, 2020 > > .Dt WRITE 2 > > .Os > > .Sh NAME > > @@ -240,9 +240,13 @@ array was negative. > > .It Bq Er EINVAL > > The sum of the > > .Fa iov_len > > -values in the > > -.Fa iov > > -array overflowed a 32-bit integer. > > +values is greater than > > +.Dv SSIZE_MAX > > +(or greater than > > +.Dv INT_MAX , > > +if the sysctl > > +.Va debug.iosize_max_clamp > > Should we also include SEE ALSO reference to sysctl(8) or sysctl(3)? > Personally I think a reference to sysctl(8) would be more apropos. Or maybe both. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. ___ 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: r367051 - in head: . usr.bin/calendar usr.bin/calendar/calendars usr.bin/calendar/calendars/de_AT.ISO_8859-15 usr.bin/calendar/calendars/de_DE.ISO8859-1 usr.bin/calendar/calendars/fr_FR...
Author: imp Date: Mon Oct 26 03:26:18 2020 New Revision: 367051 URL: https://svnweb.freebsd.org/changeset/base/367051 Log: calendar: remove all datafiles except freebsd one Move all the data files for the calendar(1) program, except calendar.freebsd to the calendar-data package. When a file can't be found, and /usr/local/share/calendar doesn't exist provide a helpful hint to install this package. Reviewed by: se@ Differential Revision: https://reviews.freebsd.org/D26926 Deleted: head/usr.bin/calendar/calendars/calendar.all head/usr.bin/calendar/calendars/calendar.australia head/usr.bin/calendar/calendars/calendar.birthday head/usr.bin/calendar/calendars/calendar.brazilian head/usr.bin/calendar/calendars/calendar.christian head/usr.bin/calendar/calendars/calendar.computer head/usr.bin/calendar/calendars/calendar.croatian head/usr.bin/calendar/calendars/calendar.dutch head/usr.bin/calendar/calendars/calendar.french head/usr.bin/calendar/calendars/calendar.german head/usr.bin/calendar/calendars/calendar.history head/usr.bin/calendar/calendars/calendar.holiday head/usr.bin/calendar/calendars/calendar.hungarian head/usr.bin/calendar/calendars/calendar.judaic head/usr.bin/calendar/calendars/calendar.lotr head/usr.bin/calendar/calendars/calendar.music head/usr.bin/calendar/calendars/calendar.newzealand head/usr.bin/calendar/calendars/calendar.russian head/usr.bin/calendar/calendars/calendar.southafrica head/usr.bin/calendar/calendars/calendar.ukrainian head/usr.bin/calendar/calendars/calendar.usholiday head/usr.bin/calendar/calendars/calendar.world head/usr.bin/calendar/calendars/de_AT.ISO_8859-15/ head/usr.bin/calendar/calendars/de_DE.ISO8859-1/ head/usr.bin/calendar/calendars/fr_FR.ISO8859-1/ head/usr.bin/calendar/calendars/hr_HR.ISO8859-2/ head/usr.bin/calendar/calendars/hu_HU.ISO8859-2/ head/usr.bin/calendar/calendars/pt_BR.ISO8859-1/ head/usr.bin/calendar/calendars/pt_BR.UTF-8/ head/usr.bin/calendar/calendars/ru_RU.KOI8-R/ head/usr.bin/calendar/calendars/ru_RU.UTF-8/ head/usr.bin/calendar/calendars/uk_UA.KOI8-U/ Modified: head/ObsoleteFiles.inc head/UPDATING head/usr.bin/calendar/Makefile head/usr.bin/calendar/calendar.1 head/usr.bin/calendar/io.c Modified: head/ObsoleteFiles.inc == --- head/ObsoleteFiles.inc Mon Oct 26 01:23:14 2020(r367050) +++ head/ObsoleteFiles.inc Mon Oct 26 03:26:18 2020(r367051) @@ -36,6 +36,72 @@ # xargs -n1 | sort | uniq -d; # done +# 20201025: Remove cal data files +OLD_FILES+=usr/share/calendar/calendar.all +OLD_FILES+=usr/share/calendar/calendar.australia +OLD_FILES+=usr/share/calendar/calendar.birthday +OLD_FILES+=usr/share/calendar/calendar.brazilian +OLD_FILES+=usr/share/calendar/calendar.christian +OLD_FILES+=usr/share/calendar/calendar.computer +OLD_FILES+=usr/share/calendar/calendar.croatian +OLD_FILES+=usr/share/calendar/calendar.dutch +OLD_FILES+=usr/share/calendar/calendar.french +OLD_FILES+=usr/share/calendar/calendar.german +OLD_FILES+=usr/share/calendar/calendar.history +OLD_FILES+=usr/share/calendar/calendar.holiday +OLD_FILES+=usr/share/calendar/calendar.hungarian +OLD_FILES+=usr/share/calendar/calendar.judaic +OLD_FILES+=usr/share/calendar/calendar.lotr +OLD_FILES+=usr/share/calendar/calendar.music +OLD_FILES+=usr/share/calendar/calendar.newzealand +OLD_FILES+=usr/share/calendar/calendar.russian +OLD_FILES+=usr/share/calendar/calendar.southafrica +OLD_FILES+=usr/share/calendar/calendar.ukrainian +OLD_FILES+=usr/share/calendar/calendar.usholiday +OLD_FILES+=usr/share/calendar/calendar.world +OLD_FILES+=usr/share/calendar/de_AT.ISO_8859-15/calendar.feiertag +OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.all +OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.feiertag +OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.geschichte +OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.kirche +OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.literatur +OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.musik +OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.wissenschaft +OLD_FILES+=usr/share/calendar/fr_FR.ISO8859-1/calendar.all +OLD_FILES+=usr/share/calendar/fr_FR.ISO8859-1/calendar.fetes +OLD_FILES+=usr/share/calendar/fr_FR.ISO8859-1/calendar.french +OLD_FILES+=usr/share/calendar/fr_FR.ISO8859-1/calendar.jferies +OLD_FILES+=usr/share/calendar/fr_FR.ISO8859-1/calendar.proverbes +OLD_FILES+=usr/share/calendar/hr_HR.ISO8859-2/calendar.all +OLD_FILES+=usr/share/calendar/hr_HR.ISO8859-2/calendar.praznici +OLD_FILES+=usr/share/calendar/hu_HU.ISO8859-2/calendar.all +OLD_FILES+=usr/share/calendar/hu_HU.ISO8859-2/calendar.nevnapok +OLD_FILES+=usr/share/calendar/hu_HU.ISO8859-2/calendar.unnepek +OLD_FILES+=usr/share/calendar/pt_BR.ISO8859-1/calendar.all +OLD_FILES+=usr/share/calendar/pt_BR.ISO8859-1/calendar.commemorative +OLD_
svn commit: r367052 - head/sys/kern
Author: mav
Date: Mon Oct 26 04:04:06 2020
New Revision: 367052
URL: https://svnweb.freebsd.org/changeset/base/367052
Log:
Enable bioq 'car limit' added at r335066 at 128 bios.
Without the 'car limit' enabled (before this), running sequential ZFS scrub
on HDD without command queuing support, I've measured latency on concurrent
random reads reaching 4 seconds (surprised that not more). Enabling this
reduced the latency to 65 milliseconds, while scrub still doing ~180MB/s.
For disks with command queuing this does not make much difference (if any),
since most time all the requests are queued down to the disk or HBA, leaving
nothing in the queue to sort. And even if something does not fit, staying on
the queue, it is likely not for long. To not limit sorting in such bursty
scenarios I've added batched counter zeroing when the queue is getting empty.
The internal scheduler of the SAS HDD I was testing seems to be even more
loyal to random I/O, reducing the scrub speed to ~120MB/s. So in case
somebody worried this is limit is too strict -- it actually looks relaxed.
MFC after:2 weeks
Sponsored by: iXsystems, Inc.
Modified:
head/sys/kern/subr_disk.c
Modified: head/sys/kern/subr_disk.c
==
--- head/sys/kern/subr_disk.c Mon Oct 26 03:26:18 2020(r367051)
+++ head/sys/kern/subr_disk.c Mon Oct 26 04:04:06 2020(r367052)
@@ -26,7 +26,7 @@ __FBSDID("$FreeBSD$");
#include
#include
-static int bioq_batchsize = 0;
+static int bioq_batchsize = 128;
SYSCTL_INT(_debug, OID_AUTO, bioq_batchsize, CTLFLAG_RW,
&bioq_batchsize, 0, "BIOQ batch size");
@@ -172,6 +172,8 @@ bioq_remove(struct bio_queue_head *head, struct bio *b
head->insert_point = NULL;
TAILQ_REMOVE(&head->queue, bp, bio_queue);
+ if (TAILQ_EMPTY(&head->queue))
+ head->batched = 0;
head->total--;
}
___
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: r367053 - head/usr.bin/calendar/calendars
Author: scottl Date: Mon Oct 26 05:22:52 2020 New Revision: 367053 URL: https://svnweb.freebsd.org/changeset/base/367053 Log: Correct calendar entry for myself Modified: head/usr.bin/calendar/calendars/calendar.freebsd Modified: head/usr.bin/calendar/calendars/calendar.freebsd == --- head/usr.bin/calendar/calendars/calendar.freebsdMon Oct 26 04:04:06 2020(r367052) +++ head/usr.bin/calendar/calendars/calendar.freebsdMon Oct 26 05:22:52 2020(r367053) @@ -331,7 +331,7 @@ 08/24 Alexander Botero-Lowry died in San Francisco, California, United States, 2012 08/25 Beech Rintoul born in Oakland, California, United States, 1952 08/25 Jean Milanez Melo born in Divinopolis, Minas Gerais, Brazil, 1982 -08/26 Scott Long born in Chicago, Illinois, United States, 1974 +08/25 Scott Long born in Chicago, Illinois, United States, 1974 08/26 Dima Ruban born in Nalchik, USSR, 1970 08/26 Marc Fonvieille born in Avignon, France, 1972 08/26 Herve Quiroz born in Aix-en-Provence, France, 1977 ___ 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: r366962 - in head: include usr.bin/calendar
On Sun, Oct 25, 2020 at 11:37:34AM +0100, Stefan Esser wrote: > Am 25.10.20 um 06:56 schrieb Alex Kozlov: > > On Sat, Oct 24, 2020 at 04:37:45PM +0200, Stefan Esser wrote: > > > Am 24.10.20 um 09:48 schrieb Alex Kozlov: > [...] > > > > You are hardcoding assumption that LOCALBASE = /usr/local. Please make > > > > it > > > > overridable with LOCALBASE environment variable. > > > This was a trivial change to get us going with calendars provided by > > > a port (which has not been committed, yet - therefore there are no > > > port-provided calendars, neither under /usr/local nor under any other > > > PREFIX, as of now). > > > > > I understand what you are asking for, but in such a case I'd rather > > > think you want to rebuild FreeBSD with _PATH_LOCALBASE modified in > > > paths.h. > > The PREFIX != LOCALBASE and both != /usr/local configurations > > are supported in the ports tree and the base for a long time, please see > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html > > Yes, and I do not need to look that up in the handbook, having been > a ports committer for 2 decades by now. > > > If after this commit you need to rebuild base to use non-default > > LOCALBASE/PREFIX > > it is pretty big regression and POLA. > > How is that any different than before? > > What I did is make the PATH easier to change when you rebuild base. > > There are numerous programs in base that contain the literal string > /usr/local - and what I did was implement a mechanism that allows > to replace this literal reference with a simple change in paths.h. > > If you do not modify paths.h for a different LOCALBASE, then you'll > get a wrong _PATH_DEFPATH compiled into your binaries, for example. > > > > And I have made this a single instance that needs to be changed. > > > Before my change there were 2 instances of /usr/local hard-coded > > > in _PATH_DEFPATH - now you have to only change the definition of > > > _PATH_LOCALBASE to adjust all 3 locations that use it. > > I think you made situation worse, there were two stray hardcoded > > string and now there is official LOCALBASE define which likely will be > > used by other people in the future. > > I'd hope so to get rid of many of the 1713 literal uses of /usr/local > in our source tree. > > > > If you can show me precedence of a LOCALBASE environment variable > > > being used in the way you suggest, I'd be willing to make calendar > > > use it. > > Just an analogy from LOCALBASE make variable, perhaps CALENDAR_HOME > > is a better name. > > Yes, I already suggested CALENDAR_HOME, but as an environment variable > to check, if you want to be able to path an additional directory (or > search path) to the calendar program at run-time. But why introduce > a CALENDAR_HOME macro in the sources, if the port supplied calendar > files are known to be found at LOCALBASE/share/calendar (for some value > of LOCALBASE). > > I want to make more programs that currently hard-code /usr/local use > _PATH_LOCALBASE instead. This C macro can then be default to /usr/local > but can be overridden by passing LOCALBASE to the compiler (from the > build infrastructure) when paths.h is included. > > Instead of referring to _PATH_LOCALBASE these files could directly use > LOCALBASE, but since other paths are defined as _PATH_xxx in paths.h I > think it is best to follow this precedent. > > > > But then I think a CALENDAR_HOME variable would be even more useful, > > > since it would allow to search an additional user selected directory > > > (and not just share/calendar within what you provide as LOCALBASE). > > My change did not add any dependency on LOCALBASE to any previously > existing functionality. It added support for calendar files provided > by a port (a feature that did not exist before) at a location that is > correct for the big majority of users (who do not modify LOCALBASE). > > As I said: I'm going to make it easier to build the base system with > a different LOCALBASE, but not by run-time checking an environment > variable that specifies LOCALBASE in each affected program. It seems that you intend to follow through no matter what. So, just for the record, I think that hardcoding LOCALBASE and requiring base rebuild to change it is a very wrong approach. -- Alex ___ 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: r366962 - in head: include usr.bin/calendar
On Mon, Oct 26, 2020 at 12:01 AM Alex Kozlov wrote: > On Sun, Oct 25, 2020 at 11:37:34AM +0100, Stefan Esser wrote: > > Am 25.10.20 um 06:56 schrieb Alex Kozlov: > > > On Sat, Oct 24, 2020 at 04:37:45PM +0200, Stefan Esser wrote: > > > > Am 24.10.20 um 09:48 schrieb Alex Kozlov: > > [...] > > > > > You are hardcoding assumption that LOCALBASE = /usr/local. Please > make it > > > > > overridable with LOCALBASE environment variable. > > > > This was a trivial change to get us going with calendars provided by > > > > a port (which has not been committed, yet - therefore there are no > > > > port-provided calendars, neither under /usr/local nor under any other > > > > PREFIX, as of now). > > > > > > > I understand what you are asking for, but in such a case I'd rather > > > > think you want to rebuild FreeBSD with _PATH_LOCALBASE modified in > > > > paths.h. > > > The PREFIX != LOCALBASE and both != /usr/local configurations > > > are supported in the ports tree and the base for a long time, please > see > > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html > > > > Yes, and I do not need to look that up in the handbook, having been > > a ports committer for 2 decades by now. > > > > > If after this commit you need to rebuild base to use non-default > LOCALBASE/PREFIX > > > it is pretty big regression and POLA. > > > > How is that any different than before? > > > > What I did is make the PATH easier to change when you rebuild base. > > > > There are numerous programs in base that contain the literal string > > /usr/local - and what I did was implement a mechanism that allows > > to replace this literal reference with a simple change in paths.h. > > > > If you do not modify paths.h for a different LOCALBASE, then you'll > > get a wrong _PATH_DEFPATH compiled into your binaries, for example. > > > > > > And I have made this a single instance that needs to be changed. > > > > Before my change there were 2 instances of /usr/local hard-coded > > > > in _PATH_DEFPATH - now you have to only change the definition of > > > > _PATH_LOCALBASE to adjust all 3 locations that use it. > > > I think you made situation worse, there were two stray hardcoded > > > string and now there is official LOCALBASE define which likely will be > > > used by other people in the future. > > > > I'd hope so to get rid of many of the 1713 literal uses of /usr/local > > in our source tree. > > > > > > If you can show me precedence of a LOCALBASE environment variable > > > > being used in the way you suggest, I'd be willing to make calendar > > > > use it. > > > Just an analogy from LOCALBASE make variable, perhaps CALENDAR_HOME > > > is a better name. > > > > Yes, I already suggested CALENDAR_HOME, but as an environment variable > > to check, if you want to be able to path an additional directory (or > > search path) to the calendar program at run-time. But why introduce > > a CALENDAR_HOME macro in the sources, if the port supplied calendar > > files are known to be found at LOCALBASE/share/calendar (for some value > > of LOCALBASE). > > > > I want to make more programs that currently hard-code /usr/local use > > _PATH_LOCALBASE instead. This C macro can then be default to /usr/local > > but can be overridden by passing LOCALBASE to the compiler (from the > > build infrastructure) when paths.h is included. > > > > Instead of referring to _PATH_LOCALBASE these files could directly use > > LOCALBASE, but since other paths are defined as _PATH_xxx in paths.h I > > think it is best to follow this precedent. > > > > > > But then I think a CALENDAR_HOME variable would be even more useful, > > > > since it would allow to search an additional user selected directory > > > > (and not just share/calendar within what you provide as LOCALBASE). > > > > My change did not add any dependency on LOCALBASE to any previously > > existing functionality. It added support for calendar files provided > > by a port (a feature that did not exist before) at a location that is > > correct for the big majority of users (who do not modify LOCALBASE). > > > > As I said: I'm going to make it easier to build the base system with > > a different LOCALBASE, but not by run-time checking an environment > > variable that specifies LOCALBASE in each affected program. > It seems that you intend to follow through no matter what. So, just for > the record, I think that hardcoding LOCALBASE and requiring base rebuild > to change it is a very wrong approach. > So, first off, it's already hard coded. Stefan's changes change the hard coding from 'impossible to change' to 'changeable with a recompile' which is an improvement. It might even wind up as a build variable (or not, doing that has some really ugly, nasty dependencies). But even in ports-land, it's a compile time constant. Quite a large number of ports will allow you to change it at compile / build time, but not after. You have to rebuild if you want to change PREFIX... So I'm a bit
