Re: svn commit: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys
Dne 23.07.2016 v 20:35 Nathan Whitehorn napsal(a): > > > On 07/23/16 03:45, Michal Meloun wrote: >> Dne 21.07.2016 v 17:53 Nathan Whitehorn napsal(a): >>> >>> On PowerPC, GENERIC64 supports FDT systems (some IBM hardware), OFW >>> systems (Macs, some IBM hardware), systems with no device trees at >>> all (old-style PS3), and systems with a mixture of device tree and >>> no device tree (new-style PS3). On these, there is a mixture of >>> "real" interrupts and GPIO-type interrupts. There is no limitation >>> that this be used only for device-tree-type systems. >>> >>> The system requires two things: an interrupt domain key and an >>> arbitrary unique byte string describing the interrupt. When running >>> with a device tree, these are set to the phandle of the >>> interrupt-parent and the contents of the device tree interrupt >>> specifier, respectively, and the system was of course developed with >>> that in mind. But they don't need to be, and often aren't. You could >>> make the domain an element of an enum (where "ACPI" is a choice, for >>> instance -- this is what PS3 does), or set it to a pointer to a >>> device_t, or really anything you like. Similarly, the interrupt >>> specifier is totally free-form. >> >> Yes, I agree. and i think that we followed the same direction. But i >> see two problems with this approach. >> - in some cases (OFW, device_t) you don't have control over domain >> key value, so you cannot guarantee its uniqueness. >> Of course, probability of collision is low, but it is. > > We could solve this in a number of ways, for example widening to 64 > bits, or adding another value (domain type, for example). You could > also make an acpi_bus_map_intr() to go with the OFW one that connect > in some machine-dependent code if you have fundamentally incompatible > bus enumeration mechanisms that you expect to exist simultaneously -- > but, of course, no systems like this seem to actually exist, so the > problem is both easily solved and totally theoretical. > >> - within ofw_bus_map_intr() (or later - at the time when byte string >> must be decoded) you are not able (easily) to differentiate >> between different formats, thus you are not able to select >> appropriate decoder. The GPIO controller, for example, >> must be able to handle interrupts defined by standard OFW property, >> or by pair concurrently. > > In principle, you could solve that as above, or by registering a > second interrupt domain for the same controller. > > In practice, it doesn't matter since, in the GPIO case, for example, > the GPIO controller is never itself also a normal interrupt controller > (i.e. the GIC and GPIO controller are always different devices). As > such, the theoretical does not occur in practice. form https://svnweb.freebsd.org/base/head/sys/gnu/dts/arm/tegra124-jetson-tk1.dts?revision=295436&view=markup#l1380 "interrupts = ; " Do you want more examples ? > >> For this reason we makes domain key composite, in our model, the >> domain key consist of "domain key type" >> and "domain key value". This composite key guarantees uniqueness and >> it also allows to select proper parser for byte string. > > Yes, but this solves what is a nonexistant problem by making the > system substantially less flexible and more invasive. Which is not a > good tradeoff. > I think that existence of problem is confirmed in the above example . Quote from previous paragraph: "We could solve this in a number of ways, ... , or adding another value (domain type, for example)." What can I say more ... >> This is, imho, only one difference between us. > > One of many, yes. > >> >>> You could, for instance, set it to one of the structures introduced >>> in r301453 if you wanted to. >>> >>> I would have zero problems with changing the prototype of the >>> existing dev/ofw function to something more generic in name, like: >>> >>> bus_map_intr(device_t dev, uintptr_t iparent, size_t intrlen, void >>> *intr) >>> >>> instead of the existing equivalent: >>> >>> ofw_bus_map_intr(device_t dev, phandle_t iparent, int icells, >>> pcell_t *intr) >>> >> Our bus_map_intr() method is not indeed as replacement of >> ofw_bus_map_intr(). Its evolution of "how we can store more complex >> data to resource list (from bus enumerator) and transfer it to >> bus_allocate_resource() and/or to bus_setup_intr()" in driver >> independent way. We found no reasonable way to do it, so we postponed >> reading of properties to bus_allocate_resource() time. > > Right, but that is (a) a solved problem with ofw_bus_map_intr() and > (b) this code doesn't solve it as completely. What does it let you do > that the existing code does not? There has not been a single concrete > example of something anyone wants to do on actual hardware so far in > this discussion. > >> But now jhb@ gives us alternative and I must say that this looks >> like a clean and elegant way how to make this (assuming that we can >> expand resource_list_entry by pointer to
svn commit: r303258 - in head/sys: conf dev/nvram2env
Author: mizhka
Date: Sun Jul 24 08:35:45 2016
New Revision: 303258
URL: https://svnweb.freebsd.org/changeset/base/303258
Log:
[nvram2env] split implementation into generic & MIPS-based code
Split implementation of nvram2env to generic (MI) & MIPS-based code:
- removed includes like "*siba*", because they are unused
- added nvram2env_mips.c file with MIPS-specific code, code moved from
nvram2env.c
- added header file to shared defines/structures/function prototypes between
MI and MIPS code
Also this fix allows to implement own nvram2env drivers.
Reviewed by:ray, adrian (mentor)
Approved by:adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6513
Added:
head/sys/dev/nvram2env/nvram2env.h (contents, props changed)
head/sys/dev/nvram2env/nvram2env_mips.c (contents, props changed)
Modified:
head/sys/conf/files.mips
head/sys/dev/nvram2env/nvram2env.c
Modified: head/sys/conf/files.mips
==
--- head/sys/conf/files.mipsSun Jul 24 08:21:21 2016(r303257)
+++ head/sys/conf/files.mipsSun Jul 24 08:35:45 2016(r303258)
@@ -86,6 +86,7 @@ crypto/blowfish/bf_enc.c optionalcrypt
crypto/des/des_enc.c optionalcrypto | ipsec | netsmb
# AP common nvram interface MIPS specific, but maybe should be more generic
+dev/nvram2env/nvram2env_mips.c optionalnvram2env
dev/nvram2env/nvram2env.c optionalnvram2env
# hwpmc support
Modified: head/sys/dev/nvram2env/nvram2env.c
==
--- head/sys/dev/nvram2env/nvram2env.c Sun Jul 24 08:21:21 2016
(r303257)
+++ head/sys/dev/nvram2env/nvram2env.c Sun Jul 24 08:35:45 2016
(r303258)
@@ -46,50 +46,7 @@ __FBSDID("$FreeBSD$");
#include
-#include
-#include
-#include
-
-#define nvram2env_read_1(sc, reg) \
- bus_space_read_1((sc)->sc_bt, (sc)->sc_bh,(reg))
-
-#define nvram2env_read_2(sc, reg) \
- bus_space_read_2((sc)->sc_bt, (sc)->sc_bh,(reg))
-
-#define nvram2env_read_4(sc, reg) \
- bus_space_read_4((sc)->sc_bt, (sc)->sc_bh,(reg))
-
-#define nvram2env_write_1(sc, reg, val)\
- bus_space_write_1((sc)->sc_bt, (sc)->sc_bh, \
-(reg), (val))
-
-#define nvram2env_write_2(sc, reg, val)\
- bus_space_write_2((sc)->sc_bt, (sc)->sc_bh, \
-(reg), (val))
-
-#define nvram2env_write_4(sc, reg, val)\
- bus_space_write_4((sc)->sc_bt, (sc)->sc_bh, \
-(reg), (val))
-
-struct nvram2env_softc {
- bus_space_tag_t bst;
- bus_space_handle_t bsh;
- bus_addr_t addr;
- int need_swap;
- uint32_t sig;
- uint32_t flags;
-#define NVRAM_FLAGS_NOCHECK0x0001 /* Do not check(CRC or somthing else)*/
-#define NVRAM_FLAGS_GENERIC0x0002 /* Format Generic, skip 4b and read */
-#define NVRAM_FLAGS_BROADCOM 0x0004 /* Format Broadcom, use struct nvram */
-#define NVRAM_FLAGS_UBOOT 0x0008 /* Format Generic, skip 4b of CRC and
read */
- uint32_t maxsize;
- uint32_t crc;
-};
-
-static int nvram2env_attach(device_t);
-static int nvram2env_probe(device_t);
-
-#define NVRAM_MAX_SIZE 0x1
+#include "nvram2env.h"
static void
nvram2env_identify(driver_t * drv, device_t parent)
@@ -100,34 +57,55 @@ nvram2env_identify(driver_t * drv, devic
BUS_ADD_CHILD(parent, 0, "nvram2env", i);
}
-static int
+int
nvram2env_probe(device_t dev)
{
uint32_t i, ivar, sig;
struct nvram2env_softc * sc = device_get_softc(dev);
- sc->bst = mips_bus_space_generic;
- if (resource_int_value("nvram", device_get_unit(dev), "sig",
- &sc->sig) != 0 || sc->sig == 0)
- sc->sig = 0x48534c46;
-
- if (resource_int_value("nvram", device_get_unit(dev), "maxsize",
- &sc->maxsize) != 0 || sc->maxsize == 0)
- sc->maxsize = NVRAM_MAX_SIZE;
-
- if (resource_int_value("nvram", device_get_unit(dev), "flags",
- &sc->flags) != 0 || sc->flags == 0)
- sc->flags = NVRAM_FLAGS_GENERIC;
+ /*
+* Please ensure that your implementation of NVRAM->ENV specifies
+* bus tag
+*/
+ if (sc->bst == NULL)
+ return (ENXIO);
+
+ if (sc->sig == 0)
+ if (resource_int_value("nvram", device_get_unit(dev), "sig",
+ &sc->sig) != 0 || sc->sig == 0)
+ sc->sig = CFE_NVRAM_SIGNATURE;
+
+ if (sc->maxsize == 0)
+ if (resource_int_value("nvram", device_get_unit(dev), "maxsize",
+ &sc->maxsize) != 0 || sc->maxsize == 0)
+
Re: svn commit: r303253 - head/sys/arm/ti
On Sun, 24 Jul 2016 01:31:41 + (UTC) Luiz Otavio O Souza wrote: > Author: loos > Date: Sun Jul 24 01:31:41 2016 > New Revision: 303253 > URL: https://svnweb.freebsd.org/changeset/base/303253 > > Log: > Allow the use of micphy on am335x devices. > > The Micrel PHYs reads the optional external delays from DTB. > > Tested and used by uBMC and uFW. > > Sponsored by: Rubicon Communications (Netgate) > > Modified: > head/sys/arm/ti/files.ti > > Modified: head/sys/arm/ti/files.ti > == > --- head/sys/arm/ti/files.ti Sat Jul 23 22:50:59 2016 > (r303252) +++ head/sys/arm/ti/files.tiSun Jul 24 01:31:41 > 2016 (r303253) @@ -20,6 +20,7 @@ > arm/ti/ti_i2c.c > optional ti_i2c arm/ti/ti_sdhci.c > optionalsdhci > arm/ti/ti_spi.c > optional ti_spi > +dev/mii/micphy.c optional > micphy Why add it here and not sys/conf/files? It doesn't seem to be Ti specific. Andrew ___ 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: r303259 - head/sys/dev/uart
Author: andrew
Date: Sun Jul 24 08:52:49 2016
New Revision: 303259
URL: https://svnweb.freebsd.org/changeset/base/303259
Log:
Remove now unused functions from the FDT uart cpu driver.
Obtained from:ABT Systems Ltd
MFC after:1 month
X-MFC with: r303100
Sponsored by: The FreeBSD Foundation
Modified:
head/sys/dev/uart/uart_cpu_fdt.c
Modified: head/sys/dev/uart/uart_cpu_fdt.c
==
--- head/sys/dev/uart/uart_cpu_fdt.cSun Jul 24 08:35:45 2016
(r303258)
+++ head/sys/dev/uart/uart_cpu_fdt.cSun Jul 24 08:52:49 2016
(r303259)
@@ -70,53 +70,6 @@ uart_cpu_eqres(struct uart_bas *b1, stru
return ((pmap_kextract(b1->bsh) == pmap_kextract(b2->bsh)) ? 1 : 0);
}
-static int
-phandle_chosen_propdev(phandle_t chosen, const char *name, phandle_t *node)
-{
- char buf[64];
-
- if (OF_getprop(chosen, name, buf, sizeof(buf)) <= 0)
- return (ENXIO);
- if ((*node = OF_finddevice(buf)) == -1)
- return (ENXIO);
-
- return (0);
-}
-
-static const struct ofw_compat_data *
-uart_fdt_find_compatible(phandle_t node, const struct ofw_compat_data *cd)
-{
- const struct ofw_compat_data *ocd;
-
- for (ocd = cd; ocd->ocd_str != NULL; ocd++) {
- if (fdt_is_compatible(node, ocd->ocd_str))
- return (ocd);
- }
- return (NULL);
-}
-
-static uintptr_t
-uart_fdt_find_by_node(phandle_t node, int class_list)
-{
- struct ofw_compat_data **cd;
- const struct ofw_compat_data *ocd;
-
- if (class_list) {
- SET_FOREACH(cd, uart_fdt_class_set) {
- ocd = uart_fdt_find_compatible(node, *cd);
- if ((ocd != NULL) && (ocd->ocd_data != 0))
- return (ocd->ocd_data);
- }
- } else {
- SET_FOREACH(cd, uart_fdt_class_and_device_set) {
- ocd = uart_fdt_find_compatible(node, *cd);
- if ((ocd != NULL) && (ocd->ocd_data != 0))
- return (ocd->ocd_data);
- }
- }
- return (0);
-}
-
int
uart_cpu_getdev(int devtype, struct uart_devinfo *di)
{
___
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: r303261 - in head/sys: amd64/amd64 amd64/include/pc arm/arm arm64/arm64 i386/include/pc sys
Author: mav
Date: Sun Jul 24 09:15:11 2016
New Revision: 303261
URL: https://svnweb.freebsd.org/changeset/base/303261
Log:
Add more UEFI/e820 memory types from latest specifications.
This is only cosmetics.
MFC after:2 weeks
Modified:
head/sys/amd64/amd64/machdep.c
head/sys/amd64/include/pc/bios.h
head/sys/arm/arm/machdep.c
head/sys/arm64/arm64/machdep.c
head/sys/i386/include/pc/bios.h
head/sys/sys/efi.h
Modified: head/sys/amd64/amd64/machdep.c
==
--- head/sys/amd64/amd64/machdep.c Sun Jul 24 09:00:16 2016
(r303260)
+++ head/sys/amd64/amd64/machdep.c Sun Jul 24 09:15:11 2016
(r303261)
@@ -1090,7 +1090,8 @@ add_efi_map_entries(struct efi_map_heade
"ACPIMemoryNVS",
"MemoryMappedIO",
"MemoryMappedIOPortSpace",
- "PalCode"
+ "PalCode",
+ "PersistentMemory"
};
/*
@@ -,7 +1112,7 @@ add_efi_map_entries(struct efi_map_heade
for (i = 0, p = map; i < ndesc; i++,
p = efi_next_descriptor(p, efihdr->descriptor_size)) {
if (boothowto & RB_VERBOSE) {
- if (p->md_type <= EFI_MD_TYPE_PALCODE)
+ if (p->md_type < nitems(types))
type = types[p->md_type];
else
type = "";
@@ -1133,6 +1134,12 @@ add_efi_map_entries(struct efi_map_heade
printf("RP ");
if (p->md_attr & EFI_MD_ATTR_XP)
printf("XP ");
+ if (p->md_attr & EFI_MD_ATTR_NV)
+ printf("NV ");
+ if (p->md_attr & EFI_MD_ATTR_MORE_RELIABLE)
+ printf("MORE_RELIABLE ");
+ if (p->md_attr & EFI_MD_ATTR_RO)
+ printf("RO ");
if (p->md_attr & EFI_MD_ATTR_RT)
printf("RUNTIME");
printf("\n");
Modified: head/sys/amd64/include/pc/bios.h
==
--- head/sys/amd64/include/pc/bios.hSun Jul 24 09:00:16 2016
(r303260)
+++ head/sys/amd64/include/pc/bios.hSun Jul 24 09:15:11 2016
(r303261)
@@ -40,6 +40,9 @@
#defineSMAP_TYPE_ACPI_RECLAIM 3
#defineSMAP_TYPE_ACPI_NVS 4
#defineSMAP_TYPE_ACPI_ERROR5
+#defineSMAP_TYPE_DISABLED 6
+#defineSMAP_TYPE_PMEM 7
+#defineSMAP_TYPE_PRAM 12
#defineSMAP_XATTR_ENABLED 0x0001
#defineSMAP_XATTR_NON_VOLATILE 0x0002
Modified: head/sys/arm/arm/machdep.c
==
--- head/sys/arm/arm/machdep.c Sun Jul 24 09:00:16 2016(r303260)
+++ head/sys/arm/arm/machdep.c Sun Jul 24 09:15:11 2016(r303261)
@@ -1424,7 +1424,8 @@ add_efi_map_entries(struct efi_map_heade
"ACPIMemoryNVS",
"MemoryMappedIO",
"MemoryMappedIOPortSpace",
- "PalCode"
+ "PalCode",
+ "PersistentMemory"
};
*mrcnt = 0;
@@ -1448,7 +1449,7 @@ add_efi_map_entries(struct efi_map_heade
for (i = 0, j = 0, p = map; i < ndesc; i++,
p = efi_next_descriptor(p, efihdr->descriptor_size)) {
if (boothowto & RB_VERBOSE) {
- if (p->md_type <= EFI_MD_TYPE_PALCODE)
+ if (p->md_type < nitems(types))
type = types[p->md_type];
else
type = "";
@@ -1470,6 +1471,12 @@ add_efi_map_entries(struct efi_map_heade
printf("RP ");
if (p->md_attr & EFI_MD_ATTR_XP)
printf("XP ");
+ if (p->md_attr & EFI_MD_ATTR_NV)
+ printf("NV ");
+ if (p->md_attr & EFI_MD_ATTR_MORE_RELIABLE)
+ printf("MORE_RELIABLE ");
+ if (p->md_attr & EFI_MD_ATTR_RO)
+ printf("RO ");
if (p->md_attr & EFI_MD_ATTR_RT)
printf("RUNTIME");
printf("\n");
Modified: head/sys/arm64/arm64/machdep.c
==
--- head/sys/arm64/arm64/machdep.c Sun Jul 24 09:00:16 2016
(r303260)
+++ head/sys/arm64/arm64/machdep.c Sun Jul 24 09:15:11 2016
(r303261)
@@ -707,7 +707,8 @@ add_efi_map_entries(struct efi_map_heade
"ACPIMemoryNVS",
"MemoryMappedIO",
svn commit: r303263 - in head/sys: compat/svr4 net
Author: glebius
Date: Sun Jul 24 10:10:09 2016
New Revision: 303263
URL: https://svnweb.freebsd.org/changeset/base/303263
Log:
Partially revert r257696/r257713, which have an issue with writing to user
controlled address. Restore the old code that emulated OSIOCGIFCONF in if.c.
Noticed by: C Turt
Modified:
head/sys/compat/svr4/svr4_sockio.c
head/sys/net/if.c
Modified: head/sys/compat/svr4/svr4_sockio.c
==
--- head/sys/compat/svr4/svr4_sockio.c Sun Jul 24 10:00:29 2016
(r303262)
+++ head/sys/compat/svr4/svr4_sockio.c Sun Jul 24 10:10:09 2016
(r303263)
@@ -73,6 +73,8 @@ bsd_to_svr4_flags(bf)
return sf;
}
+#defineOSIOCGIFCONF_IOWR('i', 20, struct ifconf)
+
int
svr4_sock_ioctl(fp, td, retval, fd, cmd, data)
struct file *fp;
@@ -144,7 +146,6 @@ svr4_sock_ioctl(fp, td, retval, fd, cmd,
case SVR4_SIOCGIFCONF:
{
struct svr4_ifconf sc;
- struct ifconf *ifc;
if ((error = copyin(data, &sc, sizeof(sc))) != 0)
return error;
@@ -153,19 +154,9 @@ svr4_sock_ioctl(fp, td, retval, fd, cmd,
sizeof(struct ifreq), sizeof(struct svr4_ifreq),
sc.svr4_ifc_len));
- ifc = (struct ifconf *)≻
- ifc->ifc_req->ifr_addr.sa_family =
- sc.svr4_ifc_req->svr4_ifr_addr.sa_family;
- ifc->ifc_req->ifr_addr.sa_len =
- sizeof(struct osockaddr);
-
- error = fo_ioctl(fp, SIOCGIFCONF, &sc, td->td_ucred,
- td);
-
- sc.svr4_ifc_req->svr4_ifr_addr.sa_family =
- ifc->ifc_req->ifr_addr.sa_family;
-
- if (error != 0)
+ if ((error = fo_ioctl(fp, OSIOCGIFCONF,
+ (caddr_t) &sc, td->td_ucred,
+ td)) != 0)
return error;
DPRINTF(("SIOCGIFCONF\n"));
Modified: head/sys/net/if.c
==
--- head/sys/net/if.c Sun Jul 24 10:00:29 2016(r303262)
+++ head/sys/net/if.c Sun Jul 24 10:10:09 2016(r303263)
@@ -2699,6 +2699,9 @@ ifhwioctl(u_long cmd, struct ifnet *ifp,
return (error);
}
+/* COMPAT_SVR4 */
+#defineOSIOCGIFCONF_IOWR('i', 20, struct ifconf)
+
#ifdef COMPAT_FREEBSD32
struct ifconf32 {
int32_t ifc_len;
@@ -2738,6 +2741,7 @@ ifioctl(struct socket *so, u_long cmd, c
switch (cmd) {
case SIOCGIFCONF:
+ case OSIOCGIFCONF: /* COMPAT_SVR4 */
error = ifconf(cmd, data);
CURVNET_RESTORE();
return (error);
@@ -3009,6 +3013,15 @@ again:
if (prison_if(curthread->td_ucred, sa) != 0)
continue;
addrs++;
+ /* COMPAT_SVR4 */
+ if (cmd == OSIOCGIFCONF) {
+ struct osockaddr *osa =
+ (struct osockaddr *)&ifr.ifr_addr;
+ ifr.ifr_addr = *sa;
+ osa->sa_family = sa->sa_family;
+ sbuf_bcat(sb, &ifr, sizeof(ifr));
+ max_len += sizeof(ifr);
+ } else
if (sa->sa_len <= sizeof(*sa)) {
ifr.ifr_addr = *sa;
sbuf_bcat(sb, &ifr, sizeof(ifr));
___
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: r303263 - in head/sys: compat/svr4 net
On Sun, Jul 24, 2016 at 10:10:09AM +, Gleb Smirnoff wrote: T> Author: glebius T> Date: Sun Jul 24 10:10:09 2016 T> New Revision: 303263 T> URL: https://svnweb.freebsd.org/changeset/base/303263 T> T> Log: T> Partially revert r257696/r257713, which have an issue with writing to user T> controlled address. Restore the old code that emulated OSIOCGIFCONF in if.c. T> T> Noticed by:C Turt I believe no one on the planet uses compat_svr4, but better fix it for 11.0-RELEASE, since too late to remove it. Note that SVR4_SIOCGIFCONF actually won't work for FreeBSD 10.x, if you load in compat_svr4.ko, since it depends on COMPAT_43 functionality compiled in kernel, which isn't case for i386 GENERIC. Of course the change wasn't tested, since I don't know how to produce or where to take an SVR4 binary that does something useful with SVR4_SIOCGIFCONF. -- Totus tuus, Glebius. ___ 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: r303264 - head/usr.bin/calendar/calendars/ru_RU.UTF-8
Author: glebius Date: Sun Jul 24 10:35:44 2016 New Revision: 303264 URL: https://svnweb.freebsd.org/changeset/base/303264 Log: The date format for ru_RU.UTF-8 locale has changed some time ago, adjust the ru_RU.UTF-8 calendar files. Modified: head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.common head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.holiday head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.military head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.orthodox head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.pagan Modified: head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.common == --- head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.common Sun Jul 24 10:10:09 2016(r303263) +++ head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.common Sun Jul 24 10:35:44 2016(r303264) @@ -9,97 +9,97 @@ LANG=ru_RU.UTF-8 -12 янв День работника прокуратуры -13 янв День российской печати -14 янв Старый Новый год -21 янв День инженерных войск -25 янв Татьянин день. Студенческий праздник - 8 фев День российской науки -10 фев День дипломатического работника - 1 мар Всемирный день гражданской обороны +12 янв.День работника прокуратуры +13 янв.День российской печати +14 янв.Старый Новый год +21 янв.День инженерных войск +25 янв.Татьянин день. Студенческий праздник + 8 февр. День российской науки +10 февр. День дипломатического работника + 1 марта Всемирный день гражданской обороны 03/SunSecond День работников геодезии и картографии -11 мар День работника органов наркоконтроля -18 мар День налоговой полиции +11 марта День работника органов наркоконтроля +18 марта День налоговой полиции 03/SunThirdДень работников торговли, бытового обслуживания населения и жилищно-коммунального хозяйства -27 мар Международный день театра -27 мар День внутренних войск - 1 апр День смеха - 2 апр День единения народов +27 марта Международный день театра +27 марта День внутренних войск + 1 апр.День смеха + 2 апр.День единения народов 04/SunFirstДень геолога -12 апр День космонавтики +12 апр.День космонавтики 04/SunSecond День войск противовоздушной обороны -26 апр День памяти погибших в радиационных авариях и катастрофах -30 апр День пожарной охраны - 7 май День радио -17 май Международный день телекоммуникаций -18 май Международный день музеев -24 май День славянской письменности и культуры -26 май День российского предпринимательства -27 май Общероссийский день библиотек -28 май День пограничника -30 май День пожарной охраны -31 май День Российской Адвокатуры +26 апр.День памяти погибших в радиационных авариях и катастрофах +30 апр.День пожарной охраны + 7 мая День радио +17 мая Международный день телекоммуникаций +18 мая Международный день музеев +24 мая День славянской письменности и культуры +26 мая День российского предпринимательства +27 мая Общероссийский день библиотек +28 мая День пограничника +30 мая День пожарной охраны +31 мая День Российской Адвокатуры 05/SunLast День химика - 1 июн День защиты детей - 5 июн День эколога - 6 июн Пушкинский день - 8 июн День социального работника + 1 июняДень защиты детей + 5 июняДень эколога + 6 июняПушкинский день + 8 июняДень социального работника 06/SunSecond День работников легкой промышленности 06/SunThirdДень медицинского работника -22 июн День памяти и скорби (Начало Великой Отечественной Войны, 1941 год) -27 июн День молодежи -29 июн День партизан и подпольщиков +22 июняДень памяти и скорби (Начало Великой Отечественной Войны, 1941 год) +27 июняДень молодежи +29 июняДень партизан и подпольщиков 06/SatLast День изобретателя и рационализатора 07/SunFirstДень работников морского и речного флота 07/SunSecond День рыбака 07/SunSecond День российской почты 07/SunThirdДень металлурга 07/SunLast День Военно-Морского Флота -28 июл День крещения Руси - 6 авг День железнодорожных войск +28 июляДень крещения Руси + 6 авг.День железнодорожных войск 08/SunFirstДень железнодорожника -12 авг День военно-воздушных сил +12 авг.День военно-воздушных сил 08/SunSecond День строителя 08/SunThirdДень Воздушного Флота -22 авг День государственного флага -27 авг День кино +22 авг.День государственного флага +27 авг.День кино 08/SunLast День шахтера - 1 сен День знаний - 2 сен День российской гвардии - 3 сен День солидарности в борьбе с терроризмом - 4 сен День специалиста по ядерному обеспечению + 1 сент. День знаний + 2 сент. День российской гвардии + 3 сент. День солидарности в борьбе с терроризмом + 4 сент. День специалиста по ядерному обеспечению 09/SunFirstДень работников нефтяной и газовой промышленности 09/SunSecond День танкиста 09/SunThirdДен
svn commit: r303265 - head/usr.bin/calendar
Author: bapt Date: Sun Jul 24 11:05:23 2016 New Revision: 303265 URL: https://svnweb.freebsd.org/changeset/base/303265 Log: Remove reference cpp(1) which is not used anymore Modified: head/usr.bin/calendar/calendar.1 Modified: head/usr.bin/calendar/calendar.1 == --- head/usr.bin/calendar/calendar.1Sun Jul 24 10:35:44 2016 (r303264) +++ head/usr.bin/calendar/calendar.1Sun Jul 24 11:05:23 2016 (r303265) @@ -28,7 +28,7 @@ .\" @(#)calendar.1 8.1 (Berkeley) 6/29/93 .\" $FreeBSD$ .\" -.Dd April 6, 2013 +.Dd July 24, 2016 .Dt CALENDAR 1 .Os .Sh NAME @@ -295,7 +295,6 @@ This is no longer true, the date is only at the beginning of a line. .Sh SEE ALSO .Xr at 1 , -.Xr cpp 1 , .Xr mail 1 , .Xr cron 8 .Sh HISTORY ___ 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: r303266 - head/sys/dev/ntb/ntb_hw
Author: mav
Date: Sun Jul 24 14:42:11 2016
New Revision: 303266
URL: https://svnweb.freebsd.org/changeset/base/303266
Log:
Postpone ntb_get_msix_info() till we need to negotiate MSIX.
Calling it earlier increases the window when MSIX info may change.
This change does not solve the problem completely, but seems logical.
Complete solution should probably include link reset in case of MSIX
remap to trigger new negotiation, but we have no way to get notified
about that now.
Modified:
head/sys/dev/ntb/ntb_hw/ntb_hw.c
Modified: head/sys/dev/ntb/ntb_hw/ntb_hw.c
==
--- head/sys/dev/ntb/ntb_hw/ntb_hw.cSun Jul 24 11:05:23 2016
(r303265)
+++ head/sys/dev/ntb/ntb_hw/ntb_hw.cSun Jul 24 14:42:11 2016
(r303266)
@@ -1084,8 +1084,6 @@ ntb_init_isr(struct ntb_softc *ntb)
ntb_create_msix_vec(ntb, num_vectors);
rc = ntb_setup_msix(ntb, num_vectors);
- if (rc == 0 && HAS_FEATURE(ntb, NTB_SB01BASE_LOCKUP))
- ntb_get_msix_info(ntb);
}
if (rc != 0) {
device_printf(ntb->device,
@@ -2715,6 +2713,7 @@ ntb_exchange_msix(void *ctx)
if (ntb->peer_msix_done)
goto msix_done;
+ ntb_get_msix_info(ntb);
for (i = 0; i < XEON_NONLINK_DB_MSIX_BITS; i++) {
ntb_peer_spad_write(ntb->device, NTB_MSIX_DATA0 + i,
ntb->msix_data[i].nmd_data);
___
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: r303264 - head/usr.bin/calendar/calendars/ru_RU.UTF-8
What happens with the lines below? On 24.07.2016 13:35, Gleb Smirnoff wrote: > Modified: head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.orthodox > -Пасха-7 Вход Господень в Иерусалим. Вербное Воскресенье > +Пасха-7 Вход Господень в Иерусалим. Вербное Воскресент.ье > +ПасхаВоскресент.ие Христово > +Пасха+39 Вознесент.ие > Modified: head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.pagan > -14 мар Новый Год, Овсень малый > +14 марта Новый Год, Овсент.ь малый > -20 мар* Весенние равноденствие > - 7 апр День Марены (сдвинутое весеннее равноденствие) > +20 марта*Весент.ние равноденствие > + 7 апр. День Марены (сдвинутое весент.нее равноденствие) > + 6 мая День Дажьбога, Овсент.ь большой ___ 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: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys
On 07/24/16 00:45, Michal Meloun wrote: Dne 23.07.2016 v 20:35 Nathan Whitehorn napsal(a): On 07/23/16 03:45, Michal Meloun wrote: Dne 21.07.2016 v 17:53 Nathan Whitehorn napsal(a): On PowerPC, GENERIC64 supports FDT systems (some IBM hardware), OFW systems (Macs, some IBM hardware), systems with no device trees at all (old-style PS3), and systems with a mixture of device tree and no device tree (new-style PS3). On these, there is a mixture of "real" interrupts and GPIO-type interrupts. There is no limitation that this be used only for device-tree-type systems. The system requires two things: an interrupt domain key and an arbitrary unique byte string describing the interrupt. When running with a device tree, these are set to the phandle of the interrupt-parent and the contents of the device tree interrupt specifier, respectively, and the system was of course developed with that in mind. But they don't need to be, and often aren't. You could make the domain an element of an enum (where "ACPI" is a choice, for instance -- this is what PS3 does), or set it to a pointer to a device_t, or really anything you like. Similarly, the interrupt specifier is totally free-form. Yes, I agree. and i think that we followed the same direction. But i see two problems with this approach. - in some cases (OFW, device_t) you don't have control over domain key value, so you cannot guarantee its uniqueness. Of course, probability of collision is low, but it is. We could solve this in a number of ways, for example widening to 64 bits, or adding another value (domain type, for example). You could also make an acpi_bus_map_intr() to go with the OFW one that connect in some machine-dependent code if you have fundamentally incompatible bus enumeration mechanisms that you expect to exist simultaneously -- but, of course, no systems like this seem to actually exist, so the problem is both easily solved and totally theoretical. - within ofw_bus_map_intr() (or later - at the time when byte string must be decoded) you are not able (easily) to differentiate between different formats, thus you are not able to select appropriate decoder. The GPIO controller, for example, must be able to handle interrupts defined by standard OFW property, or by pair concurrently. In principle, you could solve that as above, or by registering a second interrupt domain for the same controller. In practice, it doesn't matter since, in the GPIO case, for example, the GPIO controller is never itself also a normal interrupt controller (i.e. the GIC and GPIO controller are always different devices). As such, the theoretical does not occur in practice. form https://svnweb.freebsd.org/base/head/sys/gnu/dts/arm/tegra124-jetson-tk1.dts?revision=295436&view=markup#l1380 "interrupts = ; " Do you want more examples ? Those have the identical format to the GPIO properties, because they are the same thing. So it works out of the box. Do you have examples of something that *doesn't work*? For this reason we makes domain key composite, in our model, the domain key consist of "domain key type" and "domain key value". This composite key guarantees uniqueness and it also allows to select proper parser for byte string. Yes, but this solves what is a nonexistant problem by making the system substantially less flexible and more invasive. Which is not a good tradeoff. I think that existence of problem is confirmed in the above example . Quote from previous paragraph: "We could solve this in a number of ways, ... , or adding another value (domain type, for example)." What can I say more ... Except that the example you gave *is not an example* of the problem you are describing. You would only end up with a problem if: 1) You had interrupts in a GPIO property rather than in an interrupts property (or equivalent). 2) *And* you had interrupts on GPIOs in an interrupts property (or equivalent) 3) *and* those are encoded differently 4) *and* the different encodings use the same number of cells 5) *and* are not otherwise distinguishable Does that ever actually happen, in the real world, on any device tree? You could imagine any kind of messed up thing you want, but we shouldn't structure APIs around them, especially given that the current alternative you are proposing has real, concrete problems on real hardware that actually exists. [snip] It is much easier to do this correctly at bus attach time when the resource lists are made (how PPC does it). I don't agree. I don't agree. Making this at bus attach time leads into complicated 'virtual' IRQ infrastructure, with many unresolved corner cases. Which unresolved corner cases? This has been working correctly on a number of platforms in both FreeBSD and Linux for many years. Nope, it doesn't work for ARM yet (for GPIO interrupts for example) and Linux uses EPROBE_DEFER mechanism for a long time. See: http://lxr.f
Re: svn commit: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys
On Sun, Jul 24, 2016 at 9:32 AM, Nathan Whitehorn wrote: > This will make this much harder to untangle, unfortunately, and probably > means we are stuck with this as a rump API in stable/11. The time to have had this discussion was 9 months ago when it first started to appear in the tree and on differential and on the mailing lists. I'm also not convinced that 'planes' would be the right way to solve the interrupt issues. There's been talk about it for a long time, but no action. The relationships in FDT are DAGs, not trees, and newbus is inherently tree-based. Warner ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r303218 - head/tools/tools/locale/tools
On 23.07.2016 15:32, Baptiste Daroussin wrote:
> On Sat, Jul 23, 2016 at 02:58:31PM +0300, Andrey Chernov wrote:
>> On 23.07.2016 14:52, Baptiste Daroussin wrote:
>>> On Sat, Jul 23, 2016 at 02:41:39PM +0300, Andrey Chernov wrote:
On 23.07.2016 14:24, Baptiste Daroussin wrote:
> Author: bapt
> Date: Sat Jul 23 11:24:05 2016
> New Revision: 303218
> URL: https://svnweb.freebsd.org/changeset/base/303218
>
> Log:
> Add another hack to add weekday to date format to more locales
>
> While here only initialize the iconv converter when needed
>
> Modified:
> head/tools/tools/locale/tools/cldr2def.pl
BTW, is there any progress in generating all collates with -m ${area} as
you planned?
>>> you mean the @modifier?
>>
>> No, I mean that:
Perhaps all uk_UA should be generated with -m ${area} too - Ukrainians
have extended Cyrillics in their alphabet and I am not sure that their
order match default Unicode order for Cyrillic. The same about be_BY,
bg_BG and sr_Cyrl_RS. They may match or may not, I don't check such
>>> deeply.
It seems the safest side will be to generate all with -m ${area}
>>> Yes that is my plan, except for the 1 or 2 that cannot be generated
>> >from cldr
>>> directly
>>
>
> Nope I haven't made any progress, and I actually did a bunch of tests of some
> (honnestly not all locales) trying to get a representative set and could not
> find differnce in ordering between locales generated with -m ${area}.
>
> It would also needs lots of work on the generation tools.
>
> I first need to write a tool that compares collation rules for various ${area}
> (not done yet) to see how much this is really needed and use it in the
> generation tools.
>
> I will try to do that for 12 if it is really worth it (based on the result
> from
> that comparison tools)
IMHO we don't need comparison tools, just blindly adding -m ${area} to
generating of every collate with different area be enough. CLDR may
involve from time to time including national alphabets changes (which
may happen often enough too), so it will be better to not run such tests
every time with new CLDR import, but just the make code which do it
correctly independently (-m ${area}) and forget about it, it will be
much easier to maintain. Moreover, you'll spend more time writing such
testing tool than adding -m ${area} :)
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r303218 - head/tools/tools/locale/tools
On Sun, Jul 24, 2016 at 06:48:00PM +0300, Andrey Chernov wrote:
> On 23.07.2016 15:32, Baptiste Daroussin wrote:
> > On Sat, Jul 23, 2016 at 02:58:31PM +0300, Andrey Chernov wrote:
> >> On 23.07.2016 14:52, Baptiste Daroussin wrote:
> >>> On Sat, Jul 23, 2016 at 02:41:39PM +0300, Andrey Chernov wrote:
> On 23.07.2016 14:24, Baptiste Daroussin wrote:
> > Author: bapt
> > Date: Sat Jul 23 11:24:05 2016
> > New Revision: 303218
> > URL: https://svnweb.freebsd.org/changeset/base/303218
> >
> > Log:
> > Add another hack to add weekday to date format to more locales
> >
> > While here only initialize the iconv converter when needed
> >
> > Modified:
> > head/tools/tools/locale/tools/cldr2def.pl
>
> BTW, is there any progress in generating all collates with -m ${area} as
> you planned?
>
> >>> you mean the @modifier?
> >>
> >> No, I mean that:
> Perhaps all uk_UA should be generated with -m ${area} too - Ukrainians
> have extended Cyrillics in their alphabet and I am not sure that their
> order match default Unicode order for Cyrillic. The same about be_BY,
> bg_BG and sr_Cyrl_RS. They may match or may not, I don't check such
> >>> deeply.
>
> It seems the safest side will be to generate all with -m ${area}
>
> >>> Yes that is my plan, except for the 1 or 2 that cannot be generated
> >> >from cldr
> >>> directly
> >>
> >
> > Nope I haven't made any progress, and I actually did a bunch of tests of
> > some
> > (honnestly not all locales) trying to get a representative set and could not
> > find differnce in ordering between locales generated with -m ${area}.
> >
> > It would also needs lots of work on the generation tools.
> >
> > I first need to write a tool that compares collation rules for various
> > ${area}
> > (not done yet) to see how much this is really needed and use it in the
> > generation tools.
> >
> > I will try to do that for 12 if it is really worth it (based on the result
> > from
> > that comparison tools)
>
> IMHO we don't need comparison tools, just blindly adding -m ${area} to
> generating of every collate with different area be enough. CLDR may
> involve from time to time including national alphabets changes (which
> may happen often enough too), so it will be better to not run such tests
> every time with new CLDR import, but just the make code which do it
> correctly independently (-m ${area}) and forget about it, it will be
> much easier to maintain. Moreover, you'll spend more time writing such
> testing tool than adding -m ${area} :)
>
Point taken, still the whole tooling has been made around not doing the -m
${area} thing which I worked around for a few collation, I need to rework (aka
greatly simplify those tools so good direction) to be able to do a full -m
${area}. I will do that for sure for 12.0
Best regards,
Bapt
signature.asc
Description: PGP signature
Re: svn commit: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys
On 07/24/16 08:45, Warner Losh wrote: On Sun, Jul 24, 2016 at 9:32 AM, Nathan Whitehorn wrote: This will make this much harder to untangle, unfortunately, and probably means we are stuck with this as a rump API in stable/11. The time to have had this discussion was 9 months ago when it first started to appear in the tree and on differential and on the mailing lists. I'm also not convinced that 'planes' would be the right way to solve the interrupt issues. There's been talk about it for a long time, but no action. The relationships in FDT are DAGs, not trees, and newbus is inherently tree-based. Warner I at least had never seen this code until it appeared in the tree and went through a phabricator review during code slush in which no one approved it. The general discussion of INTRNG 9 months ago was great, and I wrote some of the code. It is a big step forward. This particular code, however, is not consistent with the understanding of what INTRNG would be that I got from that discussion. The actual discussion on mailing lists seems to consist only of this cryptic email on an ARM list (https://lists.freebsd.org/pipermail/freebsd-arm/2016-June/013976.html) with no meaningful content right before the commit and some phabricator reviews that no one signed off on, that do not include all the relevant maintainers, and that end in one case with open questions followed by a commit. Since this fundamentally affects parts of kern/ and newbus, this needed to be on freebsd-arch for a month at the *very* least and to have positive approval. Given how this was handled and where we are in the release cycle, I don't know what the right course of action is; I see no good outcomes at this point. The core problem is that the code in this commit series duplicates an existing architecture that solves all the problems it purports, but can't ever be portable to other platforms because of its dependency model. As such, it will either (a) bitrot or (b) sit in the tree as a permanent, inflexible, ARM-only adjunct to the systems used on other platforms, filling kern and dev/ofw with progressively more #ifdef. We worked very hard to *remove* an API very similar from this on MIPS in the initial parts of INTRNG because it crippled the flexibility of the system. Having it appear again, under the radar, during code slush with no meaningful review and the author unreachable right before a major release is extremely disappointing. -Nathan ___ 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: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys
Dne 24.07.2016 v 17:32 Nathan Whitehorn napsal(a): > > > On 07/24/16 00:45, Michal Meloun wrote: >> Dne 23.07.2016 v 20:35 Nathan Whitehorn napsal(a): >>> >>> >>> On 07/23/16 03:45, Michal Meloun wrote: Dne 21.07.2016 v 17:53 Nathan Whitehorn napsal(a): > > On PowerPC, GENERIC64 supports FDT systems (some IBM hardware), > OFW systems (Macs, some IBM hardware), systems with no device > trees at all (old-style PS3), and systems with a mixture of device > tree and no device tree (new-style PS3). On these, there is a > mixture of "real" interrupts and GPIO-type interrupts. There is no > limitation that this be used only for device-tree-type systems. > > The system requires two things: an interrupt domain key and an > arbitrary unique byte string describing the interrupt. When > running with a device tree, these are set to the phandle of the > interrupt-parent and the contents of the device tree interrupt > specifier, respectively, and the system was of course developed > with that in mind. But they don't need to be, and often aren't. > You could make the domain an element of an enum (where "ACPI" is a > choice, for instance -- this is what PS3 does), or set it to a > pointer to a device_t, or really anything you like. Similarly, the > interrupt specifier is totally free-form. Yes, I agree. and i think that we followed the same direction. But i see two problems with this approach. - in some cases (OFW, device_t) you don't have control over domain key value, so you cannot guarantee its uniqueness. Of course, probability of collision is low, but it is. >>> >>> We could solve this in a number of ways, for example widening to 64 >>> bits, or adding another value (domain type, for example). You could >>> also make an acpi_bus_map_intr() to go with the OFW one that connect >>> in some machine-dependent code if you have fundamentally >>> incompatible bus enumeration mechanisms that you expect to exist >>> simultaneously -- but, of course, no systems like this seem to >>> actually exist, so the problem is both easily solved and totally >>> theoretical. >>> - within ofw_bus_map_intr() (or later - at the time when byte string must be decoded) you are not able (easily) to differentiate between different formats, thus you are not able to select appropriate decoder. The GPIO controller, for example, must be able to handle interrupts defined by standard OFW property, or by pair concurrently. >>> >>> In principle, you could solve that as above, or by registering a >>> second interrupt domain for the same controller. >>> >>> In practice, it doesn't matter since, in the GPIO case, for example, >>> the GPIO controller is never itself also a normal interrupt >>> controller (i.e. the GIC and GPIO controller are always different >>> devices). As such, the theoretical does not occur in practice. >> form >> https://svnweb.freebsd.org/base/head/sys/gnu/dts/arm/tegra124-jetson-tk1.dts?revision=295436&view=markup#l1380 >> "interrupts = ; " >> Do you want more examples ? > > Those have the identical format to the GPIO properties, because they > are the same thing. So it works out of the box. Do you have examples > of something that *doesn't work*? > >> >>> For this reason we makes domain key composite, in our model, the domain key consist of "domain key type" and "domain key value". This composite key guarantees uniqueness and it also allows to select proper parser for byte string. >>> >>> Yes, but this solves what is a nonexistant problem by making the >>> system substantially less flexible and more invasive. Which is not a >>> good tradeoff. >>> >> I think that existence of problem is confirmed in the above example . >> Quote from previous paragraph: >> "We could solve this in a number of ways, ... , or adding another >> value (domain type, for example)." >> What can I say more ... > > Except that the example you gave *is not an example* of the problem > you are describing. You would only end up with a problem if: > 1) You had interrupts in a GPIO property rather than in an interrupts > property (or equivalent). > 2) *And* you had interrupts on GPIOs in an interrupts property (or > equivalent) > 3) *and* those are encoded differently > 4) *and* the different encodings use the same number of cells > 5) *and* are not otherwise distinguishable > > Does that ever actually happen, in the real world, on any device tree? > You could imagine any kind of messed up thing you want, but we > shouldn't structure APIs around them, especially given that the > current alternative you are proposing has real, concrete problems on > real hardware that actually exists. > >> >> > > [snip] > > >> >>> > It is much easier to do this correctly at bus attach time when > the resource lists are made (how PPC does it). > I don't agree. I d
Re: svn commit: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys
I'm sorry for the blank response sent by mistake. Dne 24.07.2016 v 17:32 Nathan Whitehorn napsal(a): > > > On 07/24/16 00:45, Michal Meloun wrote: >> Dne 23.07.2016 v 20:35 Nathan Whitehorn napsal(a): >>> >>> >>> On 07/23/16 03:45, Michal Meloun wrote: Dne 21.07.2016 v 17:53 Nathan Whitehorn napsal(a): > > On PowerPC, GENERIC64 supports FDT systems (some IBM hardware), > OFW systems (Macs, some IBM hardware), systems with no device > trees at all (old-style PS3), and systems with a mixture of device > tree and no device tree (new-style PS3). On these, there is a > mixture of "real" interrupts and GPIO-type interrupts. There is no > limitation that this be used only for device-tree-type systems. > > The system requires two things: an interrupt domain key and an > arbitrary unique byte string describing the interrupt. When > running with a device tree, these are set to the phandle of the > interrupt-parent and the contents of the device tree interrupt > specifier, respectively, and the system was of course developed > with that in mind. But they don't need to be, and often aren't. > You could make the domain an element of an enum (where "ACPI" is a > choice, for instance -- this is what PS3 does), or set it to a > pointer to a device_t, or really anything you like. Similarly, the > interrupt specifier is totally free-form. Yes, I agree. and i think that we followed the same direction. But i see two problems with this approach. - in some cases (OFW, device_t) you don't have control over domain key value, so you cannot guarantee its uniqueness. Of course, probability of collision is low, but it is. >>> >>> We could solve this in a number of ways, for example widening to 64 >>> bits, or adding another value (domain type, for example). You could >>> also make an acpi_bus_map_intr() to go with the OFW one that connect >>> in some machine-dependent code if you have fundamentally >>> incompatible bus enumeration mechanisms that you expect to exist >>> simultaneously -- but, of course, no systems like this seem to >>> actually exist, so the problem is both easily solved and totally >>> theoretical. >>> - within ofw_bus_map_intr() (or later - at the time when byte string must be decoded) you are not able (easily) to differentiate between different formats, thus you are not able to select appropriate decoder. The GPIO controller, for example, must be able to handle interrupts defined by standard OFW property, or by pair concurrently. >>> >>> In principle, you could solve that as above, or by registering a >>> second interrupt domain for the same controller. >>> >>> In practice, it doesn't matter since, in the GPIO case, for example, >>> the GPIO controller is never itself also a normal interrupt >>> controller (i.e. the GIC and GPIO controller are always different >>> devices). As such, the theoretical does not occur in practice. >> form >> https://svnweb.freebsd.org/base/head/sys/gnu/dts/arm/tegra124-jetson-tk1.dts?revision=295436&view=markup#l1380 >> "interrupts = ; " >> Do you want more examples ? > > Those have the identical format to the GPIO properties, because they > are the same thing. So it works out of the box. Do you have examples > of something that *doesn't work*? >> >>> For this reason we makes domain key composite, in our model, the domain key consist of "domain key type" and "domain key value". This composite key guarantees uniqueness and it also allows to select proper parser for byte string. >>> >>> Yes, but this solves what is a nonexistant problem by making the >>> system substantially less flexible and more invasive. Which is not a >>> good tradeoff. >>> >> I think that existence of problem is confirmed in the above example . >> Quote from previous paragraph: >> "We could solve this in a number of ways, ... , or adding another >> value (domain type, for example)." >> What can I say more ... > > Except that the example you gave *is not an example* of the problem > you are describing. You would only end up with a problem if: > 1) You had interrupts in a GPIO property rather than in an interrupts > property (or equivalent). > 2) *And* you had interrupts on GPIOs in an interrupts property (or > equivalent) > 3) *and* those are encoded differently > 4) *and* the different encodings use the same number of cells > 5) *and* are not otherwise distinguishable > > Does that ever actually happen, in the real world, on any device tree? > You could imagine any kind of messed up thing you want, but we > shouldn't structure APIs around them, especially given that the > current alternative you are proposing has real, concrete problems on > real hardware that actually exists. > Allow me to respond to this issue only. I think that this main issue, everything else looks resolvable for me (or, in worst case, can be converted to MD code). fro
svn commit: r303271 - in head: share/mk sys/conf
Author: br
Date: Sun Jul 24 18:04:12 2016
New Revision: 303271
URL: https://svnweb.freebsd.org/changeset/base/303271
Log:
Fix style.
Modified:
head/share/mk/bsd.sys.mk
head/sys/conf/kern.mk
Modified: head/share/mk/bsd.sys.mk
==
--- head/share/mk/bsd.sys.mkSun Jul 24 17:07:39 2016(r303270)
+++ head/share/mk/bsd.sys.mkSun Jul 24 18:04:12 2016(r303271)
@@ -111,12 +111,30 @@ CWARNFLAGS+= -Wno-format
# GCC 5.2.0
.if ${COMPILER_TYPE} == "gcc" && ${COMPILER_VERSION} >= 50200
-CWARNFLAGS+= -Wno-error=unused-function -Wno-error=enum-compare
-Wno-error=logical-not-parentheses -Wno-error=bool-compare
-Wno-error=uninitialized -Wno-error=array-bounds -Wno-error=clobbered
-Wno-error=cast-align -Wno-error=extra -Wno-error=attributes -Wno-error=inline
-Wno-error=unused-but-set-variable -Wno-error=unused-value
-Wno-error=strict-aliasing -Wno-error=address
+CWARNFLAGS+= -Wno-error=address \
+ -Wno-error=array-bounds \
+ -Wno-error=attributes \
+ -Wno-error=bool-compare \
+ -Wno-error=cast-align \
+ -Wno-error=clobbered\
+ -Wno-error=enum-compare \
+ -Wno-error=extra\
+ -Wno-error=inline \
+ -Wno-error=logical-not-parentheses \
+ -Wno-error=strict-aliasing \
+ -Wno-error=uninitialized\
+ -Wno-error=unused-but-set-variable \
+ -Wno-error=unused-function \
+ -Wno-error=unused-value
.endif
# GCC 6.1.0
.if ${COMPILER_TYPE} == "gcc" && ${COMPILER_VERSION} >= 60100
-CWARNFLAGS+= -Wno-error=unused-const-variable= -Wno-error=nonnull-compare
-Wno-error=shift-negative-value -Wno-error=misleading-indentation
-Wno-error=tautological-compare
+CWARNFLAGS+= -Wno-error=misleading-indentation \
+ -Wno-error=nonnull-compare \
+ -Wno-error=shift-negative-value \
+ -Wno-error=tautological-compare \
+ -Wno-error=unused-const-variable
.endif
# How to handle FreeBSD custom printf format specifiers.
Modified: head/sys/conf/kern.mk
==
--- head/sys/conf/kern.mk Sun Jul 24 17:07:39 2016(r303270)
+++ head/sys/conf/kern.mk Sun Jul 24 18:04:12 2016(r303271)
@@ -51,7 +51,7 @@ CWARNEXTRA?= -Wno-error=inline -Wno-erro
-Wno-error=cast-qual -Wno-error=sequence-point
-Wno-error=attributes \
-Wno-error=strict-overflow -Wno-error=overflow
.if ${COMPILER_VERSION} >= 60100
-CWARNEXTRA+= -Wno-error=nonnull-compare -Wno-error=shift-overflow=
+CWARNEXTRA+= -Wno-error=nonnull-compare -Wno-error=shift-overflow
.endif
.else
# For gcc 4.2, eliminate the too-often-wrong warnings about uninitialized vars.
___
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: r303272 - head
Author: bdrewery
Date: Sun Jul 24 18:05:05 2016
New Revision: 303272
URL: https://svnweb.freebsd.org/changeset/base/303272
Log:
SYSTEM_COMPILER: Rework the logic to allow a 'make test-system-compiler'.
1. Always calculate what the expected values are.
2. Add 'make test-system-compiler' to show all of the computed values
vs the wanted values.
3. Extend the .info line to
buildkernel/kernel-toolchain/toolchain/_cross-tools.
4. Consolidate all of the logic to one condition.
MFC after:3 days
Sponsored by: EMC / Isilon Storage Division
Modified:
head/Makefile
head/Makefile.inc1
Modified: head/Makefile
==
--- head/Makefile Sun Jul 24 18:04:12 2016(r303271)
+++ head/Makefile Sun Jul 24 18:05:05 2016(r303272)
@@ -131,7 +131,8 @@ TGTS= all all-man buildenv buildenvvars
builddtb xdev xdev-build xdev-install \
xdev-links native-xtools stageworld stagekernel stage-packages \
create-world-packages create-kernel-packages create-packages \
- packages installconfig real-packages sign-packages package-pkg
+ packages installconfig real-packages sign-packages package-pkg \
+ test-system-compiler
# XXX: r156740: This can't work since bsd.subdir.mk is not included ever.
# It will only work for SUBDIR_TARGETS in make.conf.
@@ -151,7 +152,8 @@ TGTS+= ${BITGTS}
META_TGT_WHITELIST+= \
_* build32 buildfiles buildincludes buildkernel buildsoft \
buildworld everything kernel-toolchain kernel-toolchains kernel \
- kernels libraries native-xtools showconfig tinderbox toolchain \
+ kernels libraries native-xtools showconfig test-system-compiler \
+ tinderbox toolchain \
toolchains universe world worlds xdev xdev-build
.ORDER: buildworld installworld
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Sun Jul 24 18:04:12 2016(r303271)
+++ head/Makefile.inc1 Sun Jul 24 18:05:05 2016(r303272)
@@ -82,50 +82,66 @@ MK_CROSS_COMPILER= no
.include "share/mk/src.opts.mk"
# Check if there is a local compiler that can satisfy as an external compiler.
-.if ${MK_SYSTEM_COMPILER} == "yes" && ${MK_CROSS_COMPILER} == "yes" && \
-(${MK_CLANG_BOOTSTRAP} == "yes" || ${MK_GCC_BOOTSTRAP} == "yes") && \
-!make(showconfig) && !make(native-xtools) && !make(xdev*)
# Which compiler is expected to be used?
.if ${MK_CLANG_BOOTSTRAP} == "yes"
-_expected_compiler_type= clang
+WANT_COMPILER_TYPE=clang
.elif ${MK_GCC_BOOTSTRAP} == "yes"
-_expected_compiler_type= gcc
+WANT_COMPILER_TYPE=gcc
.endif
-# If the expected vs CC is different then we can't skip.
-# GCC cannot be used for cross-arch yet. For clang we pass -target later if
-# TARGET_ARCH!=MACHINE_ARCH.
-.if ${_expected_compiler_type} == ${COMPILER_TYPE} && \
-(${COMPILER_TYPE} == "clang" || ${TARGET_ARCH} == ${MACHINE_ARCH})
-# It needs to be the same revision as we would build for the bootstrap.
-.if !defined(CROSS_COMPILER_FREEBSD_VERSION)
-.if ${_expected_compiler_type} == "clang"
-CROSS_COMPILER_FREEBSD_VERSION!= \
+.if !defined(WANT_COMPILER_FREEBSD_VERSION)
+.if ${WANT_COMPILER_TYPE} == "clang"
+WANT_COMPILER_FREEBSD_VERSION_FILE= lib/clang/freebsd_cc_version.h
+WANT_COMPILER_FREEBSD_VERSION!= \
awk '$$2 == "FREEBSD_CC_VERSION" {printf("%d\n", $$3)}' \
- ${SRCDIR}/lib/clang/freebsd_cc_version.h || echo unknown
-CROSS_COMPILER_VERSION!= \
+ ${SRCDIR}/${WANT_COMPILER_FREEBSD_VERSION_FILE} || echo unknown
+WANT_COMPILER_VERSION_FILE= lib/clang/include/clang/Basic/Version.inc
+WANT_COMPILER_VERSION!= \
awk '$$2 == "CLANG_VERSION" {split($$3, a, "."); print a[1] * 1 +
a[2] * 100 + a[3]}' \
- ${SRCDIR}/lib/clang/include/clang/Basic/Version.inc || echo unknown
-.elif ${_expected_compiler_type} == "gcc"
-CROSS_COMPILER_FREEBSD_VERSION!= \
+ ${SRCDIR}/${WANT_COMPILER_VERSION_FILE} || echo unknown
+.elif ${WANT_COMPILER_TYPE} == "gcc"
+WANT_COMPILER_FREEBSD_VERSION_FILE= gnu/usr.bin/cc/cc_tools/freebsd-native.h
+WANT_COMPILER_FREEBSD_VERSION!= \
awk '$$2 == "FBSD_CC_VER" {printf("%d\n", $$3)}' \
- ${SRCDIR}/gnu/usr.bin/cc/cc_tools/freebsd-native.h || echo unknown
-CROSS_COMPILER_VERSION!= \
+ ${SRCDIR}/${WANT_COMPILER_FREEBSD_VERSION_FILE} || echo unknown
+WANT_COMPILER_VERSION_FILE= contrib/gcc/BASE-VER
+WANT_COMPILER_VERSION!= \
awk -F. '{print $$1 * 1 + $$2 * 100 + $$3}' \
- ${SRCDIR}/contrib/gcc/BASE-VER || echo unknown
+ ${SRCDIR}/${WANT_COMPILER_VERSION_FILE} || echo unknown
.endif
-.export CROSS_COMPILER_FREEBSD_VERSION CROSS_COMPILER_VERSION
-.endif # !defined(CROSS_COMPILER_FREEBSD_VERSION)
-.if ${COMPILER_VERSION} == ${CROSS_COMPILER_VERSION} && \
-${COMPILER_FREEBSD_VERSION} == ${CROSS_COMPILER_FREEBSD_VERSION}
+.export WANT_COMPILER_FR
svn commit: r303273 - head
Author: bdrewery
Date: Sun Jul 24 18:28:14 2016
New Revision: 303273
URL: https://svnweb.freebsd.org/changeset/base/303273
Log:
Fix empty WANT_COMPILER_TYPE when neither compiler is bootstrapped.
Bug in r303272.
MFC after:3 days
X-MFC-With: r303272
Sponsored by: EMC / Isilon Storage Division
Modified:
head/Makefile.inc1
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Sun Jul 24 18:05:05 2016(r303272)
+++ head/Makefile.inc1 Sun Jul 24 18:28:14 2016(r303273)
@@ -87,6 +87,8 @@ MK_CROSS_COMPILER=no
WANT_COMPILER_TYPE=clang
.elif ${MK_GCC_BOOTSTRAP} == "yes"
WANT_COMPILER_TYPE=gcc
+.else
+WANT_COMPILER_TYPE=
.endif
.if !defined(WANT_COMPILER_FREEBSD_VERSION)
.if ${WANT_COMPILER_TYPE} == "clang"
___
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: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys
[snip] Hi, I think a lot of this whole discussion stems from a reasonably unclear shared idea of where intrng is supposed to be going and what it's supposed to be doing. I'm sure everyone has their own ideas of what it is for their own needs, but this thread shows a clear separation between the original writers and people working on supporting their own platforms. So, my suggestion - also so I can understand it, since I kinda need it now for the atheros mips ports! - is maybe something gets written up in the wiki that's a more detailed technical overview of intrng, including the problems its trying to solve. Then, instead of flinging things around on the commit mailing list, people edit the wiki and discuss on -arm about the specific details. I think that'll avoid a lot of what's going on. (And honestly, I'd like it more sorted out sooner rather than later, as I really want to start attacking the QCA ARM ports (IPQ4019) if it's not already done, and that's all interrupt/gpio/etc gymnastics we need INTRNG for.) So, Nathan, wanna start a wiki page with the /current/ implementation that's in -HEAD and what the intention was from the PPC side? -adrian ___ 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: r303274 - head
Author: bdrewery
Date: Sun Jul 24 18:50:11 2016
New Revision: 303274
URL: https://svnweb.freebsd.org/changeset/base/303274
Log:
Don't disable binutils/elftoolchain bootstrapping with external compiler.
This was a regression from r300349.
Setting MK_CROSS_COMPILER=no forces the compiler bootstraping *and* the
binutils/elftoolchain bootstrapping to be disabled in share/mk/src.opts.mk.
The only intent with using an external compiler is to disable bootstrapping of
the compiler. The binutils/elftoolchain bootstrapping must still occur unless
XAS is set. This did not affect WITH_SYSTEM_COMPILER.
Now that setting an external compiler sets both MK_CLANG_BOOTSTRAP and
MK_GCC_BOOTSTRAP to no, and MK_CROSS_COMPILER does the same via
share/mk/src/opts.mk, remove redundant logic that checks for
MK_CROSS_COMPILER. It will not always be true now that MK_CROSS_COMPILER==no
when an external compiler is used and --sysroot/-target is needed.
Reported by: sbruno
Pointyhat to: bdrewery
MFC after:3 days
Sponsored by: EMC / Isilon Storage Division
Modified:
head/Makefile.inc1
head/Makefile.libcompat
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Sun Jul 24 18:28:14 2016(r303273)
+++ head/Makefile.inc1 Sun Jul 24 18:50:11 2016(r303274)
@@ -74,7 +74,8 @@ X${COMPILER}?=${${COMPILER}}
# If a full path to an external cross compiler is given, don't build
# a cross compiler.
.if ${XCC:N${CCACHE_BIN}:M/*}
-MK_CROSS_COMPILER= no
+MK_CLANG_BOOTSTRAP=no
+MK_GCC_BOOTSTRAP= no
.endif
# Pull in COMPILER_TYPE and COMPILER_FREEBSD_VERSION early.
@@ -116,7 +117,7 @@ WANT_COMPILER_VERSION!= \
# If the expected vs CC is different then we can't skip.
# GCC cannot be used for cross-arch yet. For clang we pass -target later if
# TARGET_ARCH!=MACHINE_ARCH.
-.if ${MK_SYSTEM_COMPILER} == "yes" && ${MK_CROSS_COMPILER} == "yes" && \
+.if ${MK_SYSTEM_COMPILER} == "yes" && \
(${MK_CLANG_BOOTSTRAP} == "yes" || ${MK_GCC_BOOTSTRAP} == "yes") && \
!make(showconfig) && !make(native-xtools) && !make(xdev*) && \
${WANT_COMPILER_TYPE} == ${COMPILER_TYPE} && \
@@ -550,8 +551,7 @@ BFLAGS+=-B${CROSS_BINUTILS_PREFIX}
.endif
# External compiler needs sysroot and target flags.
-.if ${MK_CROSS_COMPILER} == "no" || \
-(${MK_CLANG_BOOTSTRAP} == "no" && ${MK_GCC_BOOTSTRAP} == "no")
+.if ${MK_CLANG_BOOTSTRAP} == "no" && ${MK_GCC_BOOTSTRAP} == "no"
.if !defined(CROSS_BINUTILS_PREFIX) || !exists(${CROSS_BINUTILS_PREFIX})
BFLAGS+= -B${WORLDTMP}/usr/bin
.endif
@@ -579,7 +579,7 @@ TARGET_TRIPLE?= ${TARGET_ARCH:C/amd64/x8
XCFLAGS+= -target ${TARGET_TRIPLE}
.endif
XCFLAGS+= --sysroot=${WORLDTMP}
-.endif # ${MK_CROSS_COMPILER} == "no"
+.endif # ${MK_CLANG_BOOTSTRAP} == "no" && ${MK_GCC_BOOTSTRAP} == "no"
.if !empty(BFLAGS)
XCFLAGS+= ${BFLAGS}
@@ -1820,7 +1820,6 @@ _elftctools= lib/libelftc \
usr.bin/elfcopy
.endif
-.if ${MK_CROSS_COMPILER} != "no"
.if ${MK_CLANG_BOOTSTRAP} != "no"
_clang=usr.bin/clang
_clang_libs= lib/clang
@@ -1828,7 +1827,6 @@ _clang_libs= lib/clang
.if ${MK_GCC_BOOTSTRAP} != "no"
_cc= gnu/usr.bin/cc
.endif
-.endif
.if ${MK_USB} != "no"
_usb_tools=sys/boot/usb/tools
.endif
Modified: head/Makefile.libcompat
==
--- head/Makefile.libcompat Sun Jul 24 18:28:14 2016(r303273)
+++ head/Makefile.libcompat Sun Jul 24 18:50:11 2016(r303274)
@@ -81,8 +81,8 @@ LIBCOMPATCFLAGS+= -B${LIBCOMPATTMP}/usr/
LIBCOMPATCFLAGS+= -isystem ${LIBCOMPATTMP}/usr/include
# Force using libc++ for external GCC.
# XXX: This should be checking MK_GNUCXX == no
-.if ${X_COMPILER_VERSION} >= 40800 && (${MK_CROSS_COMPILER} == "no" || \
-(${MK_CLANG_BOOTSTRAP} == "no" && ${MK_GCC_BOOTSTRAP} == "no"))
+.if ${X_COMPILER_VERSION} >= 40800 && \
+(${MK_CLANG_BOOTSTRAP} == "no" && ${MK_GCC_BOOTSTRAP} == "no")
LIBCOMPATCXXFLAGS+=-isystem ${LIBCOMPATTMP}/usr/include/c++/v1 -std=c++11 \
-nostdinc++ -L${LIBCOMPAT_OBJTREE}${.CURDIR}/lib/libc++
.endif
___
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: r303264 - head/usr.bin/calendar/calendars/ru_RU.UTF-8
Andrey, thanks, I will fix that. Trusting script and not checking results was stupid. On Sun, Jul 24, 2016 at 06:16:26PM +0300, Andrey Chernov wrote: A> What happens with the lines below? A> A> On 24.07.2016 13:35, Gleb Smirnoff wrote: A> > Modified: head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.orthodox A> > -Пасха-7 Вход Господень в Иерусалим. Вербное Воскресенье A> > +Пасха-7 Вход Господень в Иерусалим. Вербное Воскресент.ье A> > +Пасха Воскресент.ие Христово A> > +Пасха+39 Вознесент.ие A> A> > Modified: head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.pagan A> > -14 марНовый Год, Овсень малый A> > +14 марта Новый Год, Овсент.ь малый A> > -20 мар* Весенние равноденствие A> > - 7 апрДень Марены (сдвинутое весеннее равноденствие) A> > +20 марта* Весент.ние равноденствие A> > + 7 апр. День Марены (сдвинутое весент.нее равноденствие) A> > + 6 маяДень Дажьбога, Овсент.ь большой A> -- Totus tuus, Glebius. ___ 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: r303277 - head/usr.bin/calendar/calendars/ru_RU.UTF-8
Author: glebius Date: Sun Jul 24 20:47:57 2016 New Revision: 303277 URL: https://svnweb.freebsd.org/changeset/base/303277 Log: Fix failures of scripted conversion. Noticed by: ache Pointy hat to:glebius Modified: head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.orthodox head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.pagan Modified: head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.orthodox == --- head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.orthodox Sun Jul 24 20:43:02 2016(r303276) +++ head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.orthodox Sun Jul 24 20:47:57 2016(r303277) @@ -19,11 +19,11 @@ Paskha=Пасха 19 янв.Богоявление или Крещение Господне 15 февр. Сретение Господне Пасха-48 Великий Пост -Пасха-7Вход Господень в Иерусалим. Вербное Воскресент.ье +Пасха-7Вход Господень в Иерусалим. Вербное Воскресенье Пасха-3Великий Четверг Пасха-2Страстная Пятница -Пасха Воскресент.ие Христово -Пасха+39 Вознесент.ие +Пасха Воскресение Христово +Пасха+39 Вознесение Пасха+49 День Святой Троицы. Пятидесятница 7 апр.Благовещение Пресвятой Богородицы 7 июляРождество Иоанна Предтечи Modified: head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.pagan == --- head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.pagan Sun Jul 24 20:43:02 2016(r303276) +++ head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.pagan Sun Jul 24 20:47:57 2016(r303277) @@ -16,13 +16,13 @@ Paskha=Пасха 24 февр. День Велеса 29 февр. День Кащея 1 марта День Марены -14 марта Новый Год, Овсент.ь малый +14 марта Новый Год, Овсень малый Пасха-55 Масленица Пасха+7Красная Горка Пасха+16 Радуница -20 марта* Весент.ние равноденствие - 7 апр.День Марены (сдвинутое весент.нее равноденствие) - 6 мая День Дажьбога, Овсент.ь большой +20 марта* Весеннее равноденствие + 7 апр.День Марены (сдвинутое весеннее равноденствие) + 6 мая День Дажьбога, Овсень большой 22 мая Ярилин День 15 июняДень Триглава 21 июня* Летнее солнцестояние ___ 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: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys
That's a good idea, Adrian. I've made a wiki page at https://wiki.freebsd.org/Complicated_Interrupts describing this and moved the discussion to freebsd-arch@ -Nathan On 07/24/16 11:48, Adrian Chadd wrote: [snip] Hi, I think a lot of this whole discussion stems from a reasonably unclear shared idea of where intrng is supposed to be going and what it's supposed to be doing. I'm sure everyone has their own ideas of what it is for their own needs, but this thread shows a clear separation between the original writers and people working on supporting their own platforms. So, my suggestion - also so I can understand it, since I kinda need it now for the atheros mips ports! - is maybe something gets written up in the wiki that's a more detailed technical overview of intrng, including the problems its trying to solve. Then, instead of flinging things around on the commit mailing list, people edit the wiki and discuss on -arm about the specific details. I think that'll avoid a lot of what's going on. (And honestly, I'd like it more sorted out sooner rather than later, as I really want to start attacking the QCA ARM ports (IPQ4019) if it's not already done, and that's all interrupt/gpio/etc gymnastics we need INTRNG for.) So, Nathan, wanna start a wiki page with the /current/ implementation that's in -HEAD and what the intention was from the PPC side? -adrian ___ 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: r303279 - head/contrib/elftoolchain/libelftc
Author: emaste Date: Sun Jul 24 23:40:33 2016 New Revision: 303279 URL: https://svnweb.freebsd.org/changeset/base/303279 Log: libelftc: fix demangling of wchar_t "wchar_t" is 7 characters long, not 6. PR: 208661 Submitted by: Daniel McRobb Obtained from:ELF Tool Chain r3480 MFC after:3 days Modified: head/contrib/elftoolchain/libelftc/libelftc_dem_gnu3.c Modified: head/contrib/elftoolchain/libelftc/libelftc_dem_gnu3.c == --- head/contrib/elftoolchain/libelftc/libelftc_dem_gnu3.c Sun Jul 24 20:54:30 2016(r303278) +++ head/contrib/elftoolchain/libelftc/libelftc_dem_gnu3.c Sun Jul 24 23:40:33 2016(r303279) @@ -2551,7 +2551,7 @@ again: case 'w': /* wchar_t */ - if (!cpp_demangle_push_str(ddata, "wchar_t", 6)) + if (!cpp_demangle_push_str(ddata, "wchar_t", 7)) goto clean; ++ddata->cur; goto rtn; ___ 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: r303282 - head/sys/modules
Author: emaste
Date: Mon Jul 25 00:49:27 2016
New Revision: 303282
URL: https://svnweb.freebsd.org/changeset/base/303282
Log:
avoid building otusfw when WITHOUT_SOURCELESS_UCODE set
PR: 204748
Submitted by: Fabian Keil
Obtained from:ElectroBSD
MFC after:1 week
Modified:
head/sys/modules/Makefile
Modified: head/sys/modules/Makefile
==
--- head/sys/modules/Makefile Mon Jul 25 00:46:45 2016(r303281)
+++ head/sys/modules/Makefile Mon Jul 25 00:49:27 2016(r303282)
@@ -279,7 +279,7 @@ SUBDIR= \
${_nxge} \
oce \
otus \
- otusfw \
+ ${_otusfw} \
ow \
${_padlock} \
${_padlock_rng} \
@@ -498,6 +498,7 @@ _fatm= fatm
_fxp= fxp
_ispfw=ispfw
_mwlfw=mwlfw
+_otusfw= otusfw
_ralfw=ralfw
_rtwnfw= rtwnfw
_urtwnfw= urtwnfw
___
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: r303283 - in head/sys/dev/hyperv: netvsc vmbus
Author: sephe
Date: Mon Jul 25 03:12:40 2016
New Revision: 303283
URL: https://svnweb.freebsd.org/changeset/base/303283
Log:
hyperv/vmbus: Rename hv_vmbus_priv.h to vmbus_brvar.h
It only contains bufring related bits for a while.
MFC after:1 week
Sponsored by: Microsoft OSTC
Differential Revision:https://reviews.freebsd.org/D7281
Added:
head/sys/dev/hyperv/vmbus/vmbus_brvar.h
- copied unchanged from r303282, head/sys/dev/hyperv/vmbus/hv_vmbus_priv.h
Deleted:
head/sys/dev/hyperv/vmbus/hv_vmbus_priv.h
Modified:
head/sys/dev/hyperv/netvsc/hv_rndis_filter.c
head/sys/dev/hyperv/vmbus/hv_ring_buffer.c
head/sys/dev/hyperv/vmbus/hyperv.c
head/sys/dev/hyperv/vmbus/hyperv_reg.h
head/sys/dev/hyperv/vmbus/vmbus.c
head/sys/dev/hyperv/vmbus/vmbus_chan.c
Modified: head/sys/dev/hyperv/netvsc/hv_rndis_filter.c
==
--- head/sys/dev/hyperv/netvsc/hv_rndis_filter.cMon Jul 25 00:49:27
2016(r303282)
+++ head/sys/dev/hyperv/netvsc/hv_rndis_filter.cMon Jul 25 03:12:40
2016(r303283)
@@ -46,7 +46,6 @@ __FBSDID("$FreeBSD$");
#include
#include
-#include
#include "hv_net_vsc.h"
#include "hv_rndis.h"
#include "hv_rndis_filter.h"
Modified: head/sys/dev/hyperv/vmbus/hv_ring_buffer.c
==
--- head/sys/dev/hyperv/vmbus/hv_ring_buffer.c Mon Jul 25 00:49:27 2016
(r303282)
+++ head/sys/dev/hyperv/vmbus/hv_ring_buffer.c Mon Jul 25 03:12:40 2016
(r303283)
@@ -31,8 +31,8 @@
#include
#include
-#include "hv_vmbus_priv.h"
#include
+#include
/* Amount of space to write to */
#defineHV_BYTES_AVAIL_TO_WRITE(r, w, z)\
Modified: head/sys/dev/hyperv/vmbus/hyperv.c
==
--- head/sys/dev/hyperv/vmbus/hyperv.c Mon Jul 25 00:49:27 2016
(r303282)
+++ head/sys/dev/hyperv/vmbus/hyperv.c Mon Jul 25 03:12:40 2016
(r303283)
@@ -43,12 +43,14 @@ __FBSDID("$FreeBSD$");
#include
#include
+#include
#include
-#include
#include
#include
#include
+#if 0
#include
+#endif
#define HYPERV_FREEBSD_BUILD 0ULL
#define HYPERV_FREEBSD_VERSION ((uint64_t)__FreeBSD_version)
Modified: head/sys/dev/hyperv/vmbus/hyperv_reg.h
==
--- head/sys/dev/hyperv/vmbus/hyperv_reg.h Mon Jul 25 00:49:27 2016
(r303282)
+++ head/sys/dev/hyperv/vmbus/hyperv_reg.h Mon Jul 25 03:12:40 2016
(r303283)
@@ -30,6 +30,7 @@
#define _HYPERV_REG_H_
#include
+#include
/*
* Hyper-V Synthetic MSRs
Modified: head/sys/dev/hyperv/vmbus/vmbus.c
==
--- head/sys/dev/hyperv/vmbus/vmbus.c Mon Jul 25 00:49:27 2016
(r303282)
+++ head/sys/dev/hyperv/vmbus/vmbus.c Mon Jul 25 03:12:40 2016
(r303283)
@@ -60,11 +60,11 @@ __FBSDID("$FreeBSD$");
#include
#include
-#include
#include
#include
#include
#include
+#include
#include
#include "acpi_if.h"
Copied: head/sys/dev/hyperv/vmbus/vmbus_brvar.h (from r303282,
head/sys/dev/hyperv/vmbus/hv_vmbus_priv.h)
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/sys/dev/hyperv/vmbus/vmbus_brvar.h Mon Jul 25 03:12:40 2016
(r303283, copy of r303282, head/sys/dev/hyperv/vmbus/hv_vmbus_priv.h)
@@ -0,0 +1,85 @@
+/*-
+ * Copyright (c) 2009-2012,2016 Microsoft Corp.
+ * Copyright (c) 2012 NetApp Inc.
+ * Copyright (c) 2012 Citrix Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice unmodified, this list of conditions, and the following
+ *disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
svn commit: r303284 - head/sys/dev/hyperv/vmbus
Author: sephe
Date: Mon Jul 25 03:30:26 2016
New Revision: 303284
URL: https://svnweb.freebsd.org/changeset/base/303284
Log:
hyperv/vmbus: Move bufring info definition to vmbus_brvar.h
MFC after:1 week
Sponsored by: Microsoft OSTC
Differential Revision:https://reviews.freebsd.org/D7282
Modified:
head/sys/dev/hyperv/vmbus/vmbus_brvar.h
head/sys/dev/hyperv/vmbus/vmbus_chanvar.h
Modified: head/sys/dev/hyperv/vmbus/vmbus_brvar.h
==
--- head/sys/dev/hyperv/vmbus/vmbus_brvar.h Mon Jul 25 03:12:40 2016
(r303283)
+++ head/sys/dev/hyperv/vmbus/vmbus_brvar.h Mon Jul 25 03:30:26 2016
(r303284)
@@ -28,22 +28,20 @@
* $FreeBSD$
*/
-#ifndef __HYPERV_PRIV_H__
-#define __HYPERV_PRIV_H__
+#ifndef _VMBUS_BRVAR_H_
+#define _VMBUS_BRVAR_H_
#include
#include
#include
-#include
#include
-#include
+typedef struct {
+ struct vmbus_bufring*ring_buffer;
+ struct mtx ring_lock;
+ uint32_tring_data_size; /* ring_size */
+} hv_vmbus_ring_buffer_info;
-struct vmbus_softc;
-
-/*
- * Private, VM Bus functions
- */
struct sysctl_ctx_list;
struct sysctl_oid;
@@ -82,4 +80,4 @@ void hv_ring_buffer_read_begin(
uint32_t hv_ring_buffer_read_end(
hv_vmbus_ring_buffer_info *ring_info);
-#endif /* __HYPERV_PRIV_H__ */
+#endif /* _VMBUS_BRVAR_H_ */
Modified: head/sys/dev/hyperv/vmbus/vmbus_chanvar.h
==
--- head/sys/dev/hyperv/vmbus/vmbus_chanvar.h Mon Jul 25 03:12:40 2016
(r303283)
+++ head/sys/dev/hyperv/vmbus/vmbus_chanvar.h Mon Jul 25 03:30:26 2016
(r303284)
@@ -39,12 +39,7 @@
#include
#include
#include
-
-typedef struct {
- struct vmbus_bufring*ring_buffer;
- struct mtx ring_lock;
- uint32_tring_data_size; /* ring_size */
-} hv_vmbus_ring_buffer_info;
+#include
struct vmbus_channel {
/*
___
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: r303285 - in head: contrib/libdivsufsort contrib/libdivsufsort/CMakeModules contrib/libdivsufsort/examples contrib/libdivsufsort/include contrib/libdivsufsort/lib contrib/libdivsufsort/...
Author: delphij
Date: Mon Jul 25 03:58:19 2016
New Revision: 303285
URL: https://svnweb.freebsd.org/changeset/base/303285
Log:
Change bsdiff to use divsufsort suffix sort library instead of qsufsort,
which is more efficient.
Note that for now we do not create a separate library for libdivsufsort
because it's not used anywhere else.
Obtained from:Chromium
MFC after:2 months
Added:
head/contrib/libdivsufsort/
- copied from r303279, vendor/libdivsufsort/dist/
head/usr.bin/bsdiff/bsdiff/config.h (contents, props changed)
head/usr.bin/bsdiff/bsdiff/divsufsort64.h (contents, props changed)
Deleted:
head/contrib/libdivsufsort/.gitignore
head/contrib/libdivsufsort/CMakeLists.txt
head/contrib/libdivsufsort/CMakeModules/
head/contrib/libdivsufsort/VERSION.cmake
head/contrib/libdivsufsort/examples/
head/contrib/libdivsufsort/include/CMakeLists.txt
head/contrib/libdivsufsort/include/lfs.h.cmake
head/contrib/libdivsufsort/lib/CMakeLists.txt
head/contrib/libdivsufsort/pkgconfig/
Modified:
head/usr.bin/bsdiff/bsdiff/Makefile
head/usr.bin/bsdiff/bsdiff/bsdiff.c
Modified: head/usr.bin/bsdiff/bsdiff/Makefile
==
--- head/usr.bin/bsdiff/bsdiff/Makefile Mon Jul 25 03:30:26 2016
(r303284)
+++ head/usr.bin/bsdiff/bsdiff/Makefile Mon Jul 25 03:58:19 2016
(r303285)
@@ -1,6 +1,17 @@
# $FreeBSD$
-PROG= bsdiff
+PROG= bsdiff
+
+# libdivsufsort configured with:
+# cmake -DCMAKE_BUILD_TYPE="Release" -DBUILD_DIVSUFSORT64=ON
+.PATH: ${.CURDIR}/../../../contrib/libdivsufsort/lib
+CFLAGS+= -DHAVE_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
+CFLAGS+= -D_LARGE_FILES -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
+CFLAGS+= -D__STDC_LIMIT_MACROS -DBUILD_DIVSUFSORT64
+CFLAGS+= -I${.CURDIR}/../../../contrib/libdivsufsort/include -I${.CURDIR}
+SRCS= divsufsort.c sssort.c trsort.c utils.c
+
+SRCS+= bsdiff.c
LIBADD=bz2
Modified: head/usr.bin/bsdiff/bsdiff/bsdiff.c
==
--- head/usr.bin/bsdiff/bsdiff/bsdiff.c Mon Jul 25 03:30:26 2016
(r303284)
+++ head/usr.bin/bsdiff/bsdiff/bsdiff.c Mon Jul 25 03:58:19 2016
(r303285)
@@ -44,106 +44,11 @@ __FBSDID("$FreeBSD$");
#define O_BINARY 0
#endif
-#define MIN(x,y) (((x)<(y)) ? (x) : (y))
-
-static void split(off_t *I,off_t *V,off_t start,off_t len,off_t h)
-{
- off_t i,j,k,x,tmp,jj,kk;
-
- if(len<16) {
- for(k=start;kstart) split(I,V,start,jj-start,h);
-
- for(i=0;ikk) split(I,V,kk,start+len-kk,h);
-}
-
-static void qsufsort(off_t *I,off_t *V,u_char *old,off_t oldsize)
-{
- off_t buckets[256];
- off_t i,h,len;
-
- for(i=0;i<256;i++) buckets[i]=0;
- for(i=0;i0;i--) buckets[i]=buckets[i-1];
- buckets[0]=0;
-
- for(i=0;i
+
+#ifndef DIVSUFSORT_API
+# ifdef DIVSUFSORT_BUILD_DLL
+# define DIVSUFSORT_API
+# else
+# define DIVSUFSORT_API
+# endif
+#endif
+
+/*- Datatypes -*/
+#ifndef SAUCHAR_T
+#define SAUCHAR_T
+typedef uint8_t sauchar_t;
+#endif /* SAUCHAR_T */
+#ifndef SAINT_T
+#define SAINT_T
+typedef int32_t saint_t;
+#endif /* SAINT_T */
+#ifndef SAIDX64_T
+#define SAIDX64_T
+typedef int64_t saidx64_t;
+#endif /* SAIDX64_T */
+#ifndef PRIdSAINT_T
+#define PRIdSAINT_T PRId32
+#endif /* PRIdSAINT_T */
+#ifndef PRIdSAIDX64_T
+#define PRIdSAIDX64_T PRId64
+#endif /* PRIdSAIDX64_T */
+
+
+/*- Prototypes -*/
+
+/**
+ * Constructs the suffix array of a given string.
+ * @param T[0..n-1] The input string.
+ * @param SA[0..n-1] The output array of suffixes.
+ * @param n The length of the given string.
+ * @return 0 if no error occurred, -1 or -2 otherwise.
+ */
+DIVSUFSORT_API
+saint_t
+divsufsort64(const sauchar_t *T, saidx64_t *SA, saidx64_t n);
+
+/**
+ * Constructs the burrows-wheeler transformed string of a given string.
+ * @param T[0..n-1] The input string.
+ * @param U[0..n-1] The output string. (can be T)
+ * @param A[0..n-1] The temporary array. (can be NULL)
+ * @param n The length of the given string.
+ * @return The primary index if no error occurred, -1 or -2 otherwise.
+ */
+DIVSUFSORT_API
+saidx64_t
+divbwt64(const sauchar_t *T, sauchar_t *U, saidx64_t *A, saidx64_t n);
+
+/**
+ * Returns the version of the divsufsort library.
+ * @return The version number string.
+ */
+DIVSUFSORT_API
+const char *
+divsufsort64_version(void);
+
+
+/**
+ * Constructs the burrows-wheeler transformed string of a given string and
suffix array.
+ * @param T[0..n-1] The input string.
+ * @param U[0..n-1] The output string. (can be T)
+ * @param SA[0..n-1] The suffix array. (can be NULL)
+ * @param n The length of the given string.
+ * @param idx The output primary index.
+ * @return 0 if no error occurred, -1 or -2 otherwise.
+ */
+DIVSUFSORT_API
+saint_t
+bw_transform64(const sauchar_t *T, sauchar_t *U,
+
