Re: backport lld version string change
> Date: Thu, 23 Mar 2017 14:34:48 +1100 > From: Jonathan Gray > > Backport a change to add "(compatible with GNU linkers)" to the lld > version output to avoid having to regenerate a large number of configure > scripts. > > https://reviews.llvm.org/D31199?id= > http://llvm.org/viewvc/llvm-project?view=revision&revision=298532 > > The output is now > > LLD 4.0.0 (compatible with GNU linkers) > > Among other things this is required to build xenocara on arm64 without > patching libtool and regenerating the configure script for Mesa. Go for it. > Index: ELF/Driver.cpp > === > RCS file: /cvs/src/gnu/llvm/tools/lld/ELF/Driver.cpp,v > retrieving revision 1.5 > diff -u -p -r1.5 Driver.cpp > --- ELF/Driver.cpp18 Mar 2017 16:36:56 - 1.5 > +++ ELF/Driver.cpp23 Mar 2017 00:34:19 - > @@ -281,11 +281,27 @@ void LinkerDriver::main(ArrayRef return; >} > > - // GNU linkers disagree here. Though both -version and -v are mentioned > - // in help to print the version information, GNU ld just normally exits, > - // while gold can continue linking. We are compatible with ld.bfd here. > + // Handle -v or -version. > + // > + // A note about "compatible with GNU linkers" message: this is a hack for > + // scripts generated by GNU Libtool 2.4.6 (released in February 2014 and > + // still the newest version in March 2017) or earlier to recognize LLD as > + // a GNU compatible linker. As long as an output for the -v option > + // contains "GNU" or "with BFD", they recognize us as GNU-compatible. > + // > + // This is somewhat ugly hack, but in reality, we had no choice other > + // than doing this. Considering the very long release cycle of Libtool, > + // it is not easy to improve it to recognize LLD as a GNU compatible > + // linker in a timely manner. Even if we can make it, there are still a > + // lot of "configure" scripts out there that are generated by old version > + // of Libtool. We cannot convince every software developer to migrate to > + // the latest version and re-generate scripts. So we have this hack. >if (Args.hasArg(OPT_version) || Args.hasArg(OPT_v)) > -outs() << getLLDVersion() << "\n"; > +outs() << getLLDVersion() << " (compatible with GNU linkers)\n"; > + > + // ld.bfd always exits after printing out the version string. > + // ld.gold proceeds if a given option is -v. Because gold's behavior > + // is more permissive than ld.bfd, we chose what gold does here. >if (Args.hasArg(OPT_version)) > return; > > >
acme-client(1): move root check up
... the parser will bomb out anyway OK? diff --git main.c main.c index dde8e8b638e..4f977451bbc 100644 --- main.c +++ main.c @@ -85,6 +85,9 @@ main(int argc, char *argv[]) goto usage; } + if (getuid() != 0) + errx(EXIT_FAILURE, "must be run as root"); + /* parse config file */ if ((conf = parse_config(conffile, popts)) == NULL) exit(EXIT_FAILURE); @@ -100,9 +103,6 @@ main(int argc, char *argv[]) argc--; argv++; - if (getuid() != 0) - errx(EXIT_FAILURE, "must be run as root"); - if (domain->cert != NULL) { if ((certdir = dirname(domain->cert)) != NULL) { if ((certdir = strdup(certdir)) == NULL) -- I'm not entirely sure you are real.
acme-client(1): remove useless owner check
Prosody starts up as _prosody so key and cert are owned by that user, which is perfectly valid. Also "current user" will always be root anyway. OK? diff --git parse.y parse.y index 1595b52a752..6ee026c2427 100644 --- parse.y +++ parse.y @@ -1034,10 +1034,6 @@ conf_check_file(char *s, int dontstat) warn("cannot stat %s", s); return (0); } - if (st.st_uid != 0 && st.st_uid != getuid()) { - warnx("%s: owner not root or current user", s); - return (0); - } if (st.st_mode & (S_IRWXG | S_IRWXO)) { warnx("%s: group read/writable or world read/writable", s); return (0); -- I'm not entirely sure you are real.
Re: acme-client(1): move root check up
ok Florian Obser(flor...@openbsd.org) on 2017.03.23 12:02:52 +: > ... the parser will bomb out anyway > > OK? > > diff --git main.c main.c > index dde8e8b638e..4f977451bbc 100644 > --- main.c > +++ main.c > @@ -85,6 +85,9 @@ main(int argc, char *argv[]) > goto usage; > } > > + if (getuid() != 0) > + errx(EXIT_FAILURE, "must be run as root"); > + > /* parse config file */ > if ((conf = parse_config(conffile, popts)) == NULL) > exit(EXIT_FAILURE); > @@ -100,9 +103,6 @@ main(int argc, char *argv[]) > argc--; > argv++; > > - if (getuid() != 0) > - errx(EXIT_FAILURE, "must be run as root"); > - > if (domain->cert != NULL) { > if ((certdir = dirname(domain->cert)) != NULL) { > if ((certdir = strdup(certdir)) == NULL) > > > -- > I'm not entirely sure you are real. >
Re: acme-client(1): remove useless owner check
i never was happy with that anyway. ok Florian Obser(flor...@openbsd.org) on 2017.03.23 12:04:56 +: > > Prosody starts up as _prosody so key and cert are owned by > that user, which is perfectly valid. > Also "current user" will always be root anyway. > > OK? > > diff --git parse.y parse.y > index 1595b52a752..6ee026c2427 100644 > --- parse.y > +++ parse.y > @@ -1034,10 +1034,6 @@ conf_check_file(char *s, int dontstat) > warn("cannot stat %s", s); > return (0); > } > - if (st.st_uid != 0 && st.st_uid != getuid()) { > - warnx("%s: owner not root or current user", s); > - return (0); > - } > if (st.st_mode & (S_IRWXG | S_IRWXO)) { > warnx("%s: group read/writable or world read/writable", s); > return (0); > > > -- > I'm not entirely sure you are real. >
[PATCH] pcidump - Enhanced Capabilities
Hi, on some machines i saw some unknown enhanced capabilities. After looking into it i saw that on some intel chipsets there actually is a capability with id 0x0. This capability contains some registers of the Advanced Error Reporting Capability but not all of them. I guess intel choose 0x0 instead of 0x1 because there implementation contains not all of the minimal Advanced Error Reporting registers. Anyway, i think it makes sense to print the enhanced capability id, even if it is not in the list. This way one does not have to look at the hexdump of pcidump -xxx to figure out which capability id the unknown capability has. Index: usr.sbin/pcidump/pcidump.c === --- pcidump.c 16 Mar 2017 22:05:46 - 1.42 +++ pcidump.c 23 Mar 2017 15:12:07 - @@ -392,6 +392,7 @@ void dump_pcie_enhanced_caplist(int bus, int dev, int func) { u_int32_t reg; + u_int32_t capidx; u_int16_t ptr; u_int16_t ecap; @@ -407,10 +408,12 @@ dump_pcie_enhanced_caplist(int bus, int ecap = PCI_PCIE_ECAP_ID(reg); if (ecap >= nitems(pci_enhanced_capnames)) - ecap = 0; + capidx = 0; + else + capidx = ecap; printf("\t0x%04x: Enhanced Capability 0x%02x: ", ptr, ecap); - printf("%s\n", pci_enhanced_capnames[ecap]); + printf("%s\n", pci_enhanced_capnames[capidx]); ptr = PCI_PCIE_ECAP_NEXT(reg); According to Rev. 3.0 of the PCIe spec, the last two bits are reserved for future use. I do not have access to the spec > Rev. 3.0. Index: dev/pci/pcireg.h === --- dev/pci/pcireg.h22 Mar 2017 07:21:39 - 1.52 +++ dev/pci/pcireg.h23 Mar 2017 13:36:09 - @@ -606,7 +606,7 @@ typedef u_int8_t pci_revision_t; #define PCI_PCIE_ECAP 0x100 #definePCI_PCIE_ECAP_ID(x) (((x) & 0x)) #define PCI_PCIE_ECAP_VER(x) (((x) >> 16) & 0x0f) -#definePCI_PCIE_ECAP_NEXT(x) ((x) >> 20) +#definePCI_PCIE_ECAP_NEXT(x) (((x) >> 20) & 0xffc) #define PCI_PCIE_ECAP_LAST 0x0 /*
mkdir(2): document EACCESS when no write permission
>From FreeBSD, POSIX has identical wording. Alternately, we could add an extra EACCESS entry similar to what exists in open(2). I'm happy with either approach. - todd Index: lib/libc/sys/mkdir.2 === RCS file: /cvs/src/lib/libc/sys/mkdir.2,v retrieving revision 1.17 diff -u -p -u -r1.17 mkdir.2 --- lib/libc/sys/mkdir.210 Sep 2015 17:55:21 - 1.17 +++ lib/libc/sys/mkdir.223 Mar 2017 16:05:00 - @@ -101,7 +101,9 @@ bytes. .It Bq Er ENOENT A component of the path prefix does not exist. .It Bq Er EACCES -Search permission is denied for a component of the path prefix. +Search permission is denied for a component of the path prefix, +or write permission is denied +on the parent directory of the directory to be created. .It Bq Er ELOOP Too many symbolic links were encountered in translating the pathname. .It Bq Er EROFS
regarding OpenSSL License change
Lots of people have been receiving emails like the one below. They have never asked the community of authors what they want. I think OpenSSL are using a github "garbage-in / garbage-out" style of process. Feel free to dig into what they think I am author of, and why. The start suggests they want to privately collect sufficient consensus to pass their agenda. They appear to be considering all actions in the tree (including mine) on equal grounds. The last sentence suggests they don't care at all about the rights of the authors. Date: Wed, 22 Mar 2017 16:48:10 -0400 From: lice...@openssl.org To: dera...@cvs.openbsd.org Subject: OpenSSL License change Message-ID: <20170322204810.ra49wtmwn%lice...@openssl.org> User-Agent: s-nail v14.8.6 Status: O Hello! This mail is coming from the OpenSSL development team. This is a pre-release email before we "go public." In particular, the most recent blog entry, listed below, is not yet available. But we thought, as an important downstream fork, that we'd give you the courtesy of participating early. We are working to change the license for OpenSSL. We want to move from the current license (which is custom-written and has some uncommon requirements on end-users), to the widely-accepted and common Apache License (version 2). You can find some explanation in our blog entries: https://www.openssl.org/blog/blog/2017/03/20/license/ https://www.openssl.org/blog/blog/2015/08/01/cla/ We wrote some tools to look through every version of our files, and our scripts found your email address. You can see what we found: https://license.openssl.org/cgi-bin/lookup.py?uid=619 We are asking for your permission to change the licence for your contribution. Please visit this link to respond; you will have a chance to accept or decline, and enter a brief comment (you can use the comment to give the names of other people we should contact, for example): https://license.openssl.org/cgi-bin/reply.py?uid=619&p=pCUKaKssFLWJztCE8FHe If you have any questions or concerns, send email to lice...@openssl.org; please be patient for a response. You can also post to the public mailing list, openssl-...@openssl.org; details about that list can be found at this site: https://mta.openssl.org/mailman/listinfo/openssl-dev If we do not hear from you, we will assume that you have no objection. Thank you! -The OpenSSL Development Team
Ralink (MediaTek) MT7650 / MT7610 usb stick problem with run(4) driver
Having trouble with TP-LINK AC600 Archer T2UH based on Ralink's MT7650 chipset with run driver on OpenBSD 6.0-stable with all the latest source tree patches installed. Just after I've added MT7650 by patching files listed below and recompiled the kernel the USB stick shows its identities as: run0 at uhub0 port 2 configuration 1 interface 0 "MediaTek WiFi" rev 2.01/1.00 addr 2 run0: MAC/BBP RT7650 (rev 0x2000), RF RT3053 (MIMO 1T1R), address "MAC" During boot It configured to associate with AP in BSS mode and having IP address from DHCP. $ cat hostname.run0 dhcp media autoselect mode 11g nwid NAME wpa wpakey KEY chan 11 while issuing # sh /etc/netstart run0 command I have error message: run0: timeout waiting for MCU to initialize run0: could not load 8051 microcode To test it out I've downloaded win7 driver and extract the firmware files from it mt7650.bin , mt7610.bin. Renamed them to run-mt7650 and run-mt7610 respectively and put into /etc/firmware When I added firmware in the source (as shown below) and rebuild the kernel afterwards. While boot when DHCP requests are sent by network adapters I have the same meessage "run0: could not load 8051 microcode" --- /usr/src/sys/dev/usb/usbdevs.h.oldThu Mar 23 19:00:27 2017 +++ /usr/src/sys/dev/usb/usbdevs.hThu Mar 23 16:33:07 2017 @@ -3550,6 +3550,7 @@ #defineUSB_PRODUCT_RALINK_RT35730x3573/* RT3573 */ #defineUSB_PRODUCT_RALINK_RT55720x5572/* RT5572 */ #defineUSB_PRODUCT_RALINK_MT76010x7601/* MT7601 */ +#defineUSB_PRODUCT_RALINK_MT76500x761A/* MT7650 */ #defineUSB_PRODUCT_RALINK_RT80700x8070/* RT8070 */ #defineUSB_PRODUCT_RALINK_RT2570_30x9020/* RT2570 */ #defineUSB_PRODUCT_RALINK_RT2573_20x9021/* RT2573 */ --- /usr/src/sys/dev/usb/if_run.c.oldThu Mar 23 18:59:36 2017 +++ /usr/src/sys/dev/usb/if_run.cThu Mar 23 19:02:46 2017 @@ -257,6 +257,7 @@ USB_ID(RALINK,RT3573), USB_ID(RALINK,RT5370), USB_ID(RALINK,RT5572), +USB_ID(RALINK,MT7650), USB_ID(RALINK,RT8070), USB_ID(SAMSUNG,WIS09ABGN), USB_ID(SAMSUNG2,RT2870_1), @@ -830,7 +831,7 @@ if (sc->mac_ver != 0x2860 && sc->mac_ver != 0x2872 && sc->mac_ver != 0x3070) -fwname = "run-rt3071"; +fwname = "run-mt7610"; else fwname = "run-rt2870"; @@ -839,13 +840,13 @@ sc->sc_dev.dv_xname, fwname, error); return error; } -if (size != 4096) { +/*if (size != 4096) { printf("%s: invalid firmware size (should be 4KB)\n", sc->sc_dev.dv_xname); free(ucode, M_DEVBUF, 0); return EINVAL; } - +*/ run_read(sc, RT2860_ASIC_VER_ID, &tmp); /* write microcode image */ run_write_region_1(sc, RT2870_FW_BASE, ucode, size); --
Re: regarding OpenSSL License change
Hi Theo, Theo de Raadt wrote on Thu, Mar 23, 2017 at 10:18:26AM -0600: > Lots of people have been receiving emails like the one below. > > They have never asked the community of authors what they want. > > I think OpenSSL are using a github "garbage-in / garbage-out" style of > process. Feel free to dig into what they think I am author of, and > why. > > We wrote some tools to look through every version of our files, and > our scripts found your email address. You can see what we found: > > https://license.openssl.org/cgi-bin/lookup.py?uid=619 ROFL... :-D Maybe they should just revert https://github.com/openssl/openssl/commit/58964a492275ca9a59a0cd9c8155cb2491b4b909 and be done with it. :-D > The start suggests they want to privately collect sufficient consensus > to pass their agenda. They appear to be considering all actions in > the tree (including mine) on equal grounds. I already sent them a clear "NO, i explicitly object to relicensing any of my contributions." If any of you care about the possibility of merging future OpenSSL improvements to LibreSSL and OpenBSD, i suggest you do the same. Similarly, if any of you dislike publishing their own code under Apache 2. > The last sentence suggests they don't care at all about the rights of > the authors. I also sent them a separate mail stating that i strongly suspect that last sentence to be grossly illegal in almost any jurisdiction. Yours, Ingo
Re: regarding OpenSSL License change
> > The last sentence suggests they don't care at all about the rights of > > the authors. > > I also sent them a separate mail stating that i strongly suspect > that last sentence to be grossly illegal in almost any jurisdiction. Of course: Lack of consent is not equal to consent.
Atheros AR9280+AR7010 USB stick don't work in BSS mode but Host AP
Have Atheros AR9280+AR7010 USB stick athn(4). Long ago I tested it with OpenBSD 5.6 in Host AP mode 5GHz band, it does not work as AP but successful in BSS in both supported bands. On OpenBSD 6.0 situation is different. It is relatively stable in AP mode, but don't work BSS in 2.4GHz band. On OpenBSD 5.6 it works fine in BSS mode. I don't know what happened, but it will be great to have BSS in 5GHz and 2.4GHz working as before. I can test all the code modification if necessary. Denis
Re: regarding OpenSSL License change
> > The start suggests they want to privately collect sufficient consensus > > to pass their agenda. They appear to be considering all actions in > > the tree (including mine) on equal grounds. > > I already sent them a clear "NO, i explicitly object to relicensing > any of my contributions." > > If any of you care about the possibility of merging future OpenSSL > improvements to LibreSSL and OpenBSD, i suggest you do the same. > > Similarly, if any of you dislike publishing their own code under Apache 2. There has been no discussion amongst the greater community of developers as to which license to take. Apache 2 has come as an edict from Rich Salz. There has also been no statement from the original authorship that this is the way to go. I suspect there is a lack of approval from some, and manufacturing consent in volume is the approach being taken. Apparently lawyers are being paid to help them push this through. Is that being paid for by donations people gave after Heartbleed? Is this why people donated?
Re: makefs: fix msdos create size
On Wed, Mar 22, 2017 at 01:32:09PM +0100, Patrick Wildt wrote: > > apparently the "create_size" option does currently not work. This is > because the strsuftoll() function uses "long long" compares which limits > the positive maximum to LLONG_MAX. Unfortunately the maximum is always > set to ULLONG_MAX, which is treated as -1 and cannot be a reasonable > maximum value. This diff basically changes the maximum to LLONG_MAX. > > Opinions? ok? The two affected options (create_size and offset) are off_t, so your diff makes sense. Go ahead. > > Patrick > > diff --git a/usr.sbin/makefs/msdos.c b/usr.sbin/makefs/msdos.c > index a60af9adaa5..863349c09e4 100644 > --- a/usr.sbin/makefs/msdos.c > +++ b/usr.sbin/makefs/msdos.c > @@ -63,7 +63,7 @@ msdos_prep_opts(fsinfo_t *fsopts) > .minimum = _min,\ > .maximum = sizeof(_type) == 1 ? 0xff : \ > (sizeof(_type) == 2 ? 0x : \ > - (sizeof(_type) == 4 ? 0x : 0xLL)), \ > + (sizeof(_type) == 4 ? 0x : 0x7fffLL)), \ > }, > ALLOPTS > #undef AOPT >
Re: mkdir(2): document EACCESS when no write permission
On Thu, Mar 23, 2017 at 10:07:43AM -0600, Todd C. Miller wrote: > From FreeBSD, POSIX has identical wording. > > Alternately, we could add an extra EACCESS entry similar to what > exists in open(2). I'm happy with either approach. OK natano@. I think using one entry is fine in this case as both conditions are related to path resolution. > > - todd > > Index: lib/libc/sys/mkdir.2 > === > RCS file: /cvs/src/lib/libc/sys/mkdir.2,v > retrieving revision 1.17 > diff -u -p -u -r1.17 mkdir.2 > --- lib/libc/sys/mkdir.2 10 Sep 2015 17:55:21 - 1.17 > +++ lib/libc/sys/mkdir.2 23 Mar 2017 16:05:00 - > @@ -101,7 +101,9 @@ bytes. > .It Bq Er ENOENT > A component of the path prefix does not exist. > .It Bq Er EACCES > -Search permission is denied for a component of the path prefix. > +Search permission is denied for a component of the path prefix, > +or write permission is denied > +on the parent directory of the directory to be created. > .It Bq Er ELOOP > Too many symbolic links were encountered in translating the pathname. > .It Bq Er EROFS >
arm64 pmap asid handling
So the diff below is my take on improving the arm64 pmap. It assumes we'll only ever run on CPUs that implement the full 16-bit ASID size. In that case we have 64k of ASIDs available, hich is way larger than the number of processes, and therefore pmaps, that can exist on an OpenBSD system. Our amd64 GENERIC.MP kernel has a maximum of 1310! So we can simply allocate an ASID when we create a pmap, and free it when we destroy it. Allocation can be done by simply picking one at random and check wether it is free. If it isn't just try again. This is basically what we do for process ID. This diff integrates Dale's diff that allocates an empty page table for the lower half of the address space of the kernel pmap. It implements the changes I suggested when reviewing his diff. We reserve ASID 0 for the kernel pmap. This way there is no reason to special-case the kernel pmap when switching contexts. Any remaining cached TLB entries are flushed just before an ASID is made available for reallocation. The ASIDs that are in use are tracked in a large bitmap. I think this will help SMP a great deal. We just have to use an atomic operation to set/clear the relevant bits. All in all the code becomes a lot simpler. Some further optimizations are possible. Thoughts? Index: arch/arm64/arm64/cpufunc_asm.S === RCS file: /cvs/src/sys/arch/arm64/arm64/cpufunc_asm.S,v retrieving revision 1.2 diff -u -p -r1.2 cpufunc_asm.S --- arch/arm64/arm64/cpufunc_asm.S 12 Mar 2017 21:05:25 - 1.2 +++ arch/arm64/arm64/cpufunc_asm.S 23 Mar 2017 18:47:55 - @@ -110,6 +110,14 @@ ENTRY(cpu_tlb_flush_all_asid) ret END(cpu_tlb_flush_all_asid) +ENTRY(cpu_tlb_flush_asid_all) + dsb ishst + tlbiaside1is, x0 + dsb ish + isb + ret +END(cpu_tlb_flush_asid_all) + /* * void cpu_dcache_wb_range(vaddr_t, vsize_t) */ Index: arch/arm64/arm64/cpuswitch.S === RCS file: /cvs/src/sys/arch/arm64/arm64/cpuswitch.S,v retrieving revision 1.1 diff -u -p -r1.1 cpuswitch.S --- arch/arm64/arm64/cpuswitch.S17 Dec 2016 23:38:33 - 1.1 +++ arch/arm64/arm64/cpuswitch.S23 Mar 2017 18:47:55 - @@ -65,17 +65,13 @@ ENTRY(cpu_switchto) strbw5, [x1, #(P_STAT) ]// Mark new on cpu ldr x5, [x1, #(P_ADDR) ]// load new pcb str x5, [x2, #(CI_CURPCB)] - ldr x20, [x5, #(PCB_PAGEDIR)] str x1, [x2, #(CI_CURPROC)] ldr x4, [x5, #(PCB_TCB)] msr tpidr_el0, x4 // load user tls ldr x19, [x5, #(PCB_SP) ] // load new stack pointer -//msr ttbr0_el1, x20 mov x0, x1 - mov x1, x20 - mov x2, x5 bl pmap_setttb mov x3, x19 Index: arch/arm64/arm64/genassym.cf === RCS file: /cvs/src/sys/arch/arm64/arm64/genassym.cf,v retrieving revision 1.2 diff -u -p -r1.2 genassym.cf --- arch/arm64/arm64/genassym.cf19 Feb 2017 19:42:40 - 1.2 +++ arch/arm64/arm64/genassym.cf23 Mar 2017 18:47:55 - @@ -63,7 +63,6 @@ struct pcb member PCB_ONFAULT pcb_onfault member PCB_FLAGS pcb_flags member PCB_SP pcb_sp -member PCB_PAGEDIR pcb_pagedir member PCB_TCB pcb_tcb struct trapframe Index: arch/arm64/arm64/pmap.c === RCS file: /cvs/src/sys/arch/arm64/arm64/pmap.c,v retrieving revision 1.27 diff -u -p -r1.27 pmap.c --- arch/arm64/arm64/pmap.c 22 Mar 2017 10:47:29 - 1.27 +++ arch/arm64/arm64/pmap.c 23 Mar 2017 18:47:55 - @@ -43,7 +43,7 @@ #endif -void pmap_setttb(struct proc *p, paddr_t pcb_pagedir, struct pcb *); +void pmap_setttb(struct proc *p); void arm64_tlbi_asid(vaddr_t va, int asid); void pmap_free_asid(pmap_t pm); @@ -907,8 +907,7 @@ pmap_pinit(pmap_t pm) } - //pmap_allocate_asid(pm); // by default global (allocate asid later!?!) - pm->pm_asid = -1; + pmap_allocate_asid(pm); pmap_extract(pmap_kernel(), l0va, (paddr_t *)&pm->pm_pt0pa); @@ -921,7 +920,7 @@ int pmap_vp_poolcache = 0; // force vp p * Create and return a physical map. */ pmap_t -pmap_create() +pmap_create(void) { pmap_t pmap; @@ -960,9 +959,8 @@ pmap_destroy(pmap_t pm) if (refs > 0) return; - if (pm->pm_asid != -1) { - pmap_free_asid(pm); - } + pmap_free_asid(pm); + /* * reference count is zero, free pmap resources and free pmap. */ @@ -1139,7 +1137,7 @@ pmap_bootstrap(long kvo, paddr_t lpt1, long ram_start, long ram_end) { void *va; - paddr_t pa; + paddr_t pa, pt1pa; struct pmapvp1 *vp1; struct pmapvp2 *vp2; struct pmapvp3
Re: regarding OpenSSL License change
Honestly, anyone who gets one of these should say no what would you all think if people quietly took derived works of software licensed under one license and took silence as assent to relicense Does this mean that with an unanswered email i can now release my re licensed as ISC version of gcc? or the linux kernel? This sort of action just means that any software you write can be plagiarized against your will if you did not find out about it in time. thats really not cool If you write software this is not a world you want to live in. Even if it does mean a anyone who can fork a github repo could get rid of the GPL after a period of non response from an author (dont go on vacation). As much as I might not agree with the GPL personally, I respect someones right to release thier work under a license and have it respected. without having to constantly answer emails and click web links telling people no On Thu, Mar 23, 2017 at 10:58 Theo de Raadt wrote: > > > The start suggests they want to privately collect sufficient consensus > > > to pass their agenda. They appear to be considering all actions in > > > the tree (including mine) on equal grounds. > > > > I already sent them a clear "NO, i explicitly object to relicensing > > any of my contributions." > > > > If any of you care about the possibility of merging future OpenSSL > > improvements to LibreSSL and OpenBSD, i suggest you do the same. > > > > Similarly, if any of you dislike publishing their own code under Apache > 2. > > There has been no discussion amongst the greater community of > developers as to which license to take. Apache 2 has come as an edict > from Rich Salz. > > There has also been no statement from the original authorship that this > is the way to go. > > I suspect there is a lack of approval from some, and manufacturing > consent in volume is the approach being taken. > > > Apparently lawyers are being paid to help them push this through. Is > that being paid for by donations people gave after Heartbleed? Is > this why people donated? > >
Re: regarding OpenSSL License change
On Thu, Mar 23, 2017 at 17:48 Bob Beck wrote: > Honestly, anyone who gets one of these should say no > > what would you all think if people quietly took derived works of software > licensed under one license and took silence as assent to relicense > > Does this mean that with an unanswered email i can now release my re > licensed as ISC version of gcc? or the linux kernel? > > This sort of action just means that any software you write can be > plagiarized against your will if you did not find out about it in time. > > thats really not cool > > If you write software this is not a world you want to live in. Even if > it does mean a anyone who can fork a github repo could get rid of the GPL > after a period of non response from an author (dont go on vacation). As > much as I might not agree with the GPL personally, I respect someones right > to release thier work under a license and have it respected. without having > to constantly answer emails and click web links telling people no > > > > On Thu, Mar 23, 2017 at 10:58 Theo de Raadt wrote: > > > > The start suggests they want to privately collect sufficient consensus > > > to pass their agenda. They appear to be considering all actions in > > > the tree (including mine) on equal grounds. > > > > I already sent them a clear "NO, i explicitly object to relicensing > > any of my contributions." > > > > If any of you care about the possibility of merging future OpenSSL > > improvements to LibreSSL and OpenBSD, i suggest you do the same. > > > > Similarly, if any of you dislike publishing their own code under Apache > 2. > > There has been no discussion amongst the greater community of > developers as to which license to take. Apache 2 has come as an edict > from Rich Salz. > > There has also been no statement from the original authorship that this > is the way to go. > > I suspect there is a lack of approval from some, and manufacturing > consent in volume is the approach being taken. > > > Apparently lawyers are being paid to help them push this through. Is > that being paid for by donations people gave after Heartbleed? Is > this why people donated? > >
Re: regarding OpenSSL License change
... > If we do not hear from you, we will assume that you have no objection. So, they will claim that, by not responding, the recipient agreed. Some jurisdictions I am aware of accept verbal contracts or this kind of written contracts, since civil proceedings will not be held up to a high standard of proof. Even then, there must have been evidence of a contractual agreement, ie. no response = no agreement. I say the lawyers are now working to prove that no response means the potential recipient agreed. If this email has been caught by enough spam filters, they will claim the majority agreed.
GCC licence change
I am mailing tech@openbsd.org (and thereby, the greater community who's email addresses may have changed) to inquire whether it is OK to change the version of gcc 4.2.1 in our source tree to from GPL to the ISC license. This licence improvement will remove the last bits of ambiguity about access to C compiler technology in a world where clang/llvm is permissive licensed. Everyone deserves access to C technology without restriction, especially as rust makes inroads. To push this change through we are going to follow the re-licensing procedure recently proposed by OpenSSL, which has been signed off by their lawyers at the SFLC. This process has significant signoff from Linux Foundation, Intel, and others. Therefore, I am asking all authors to respond to this thread if they object. Should probably provide special attention to the original author as the starting point for all future work as 'derivative' authors who could be authors on their own. He is the Eric Young of gcc, so we respect his opinion. In case he doesn't read this let him know; if he is concerned he will reply. Richard schooled SFLC when yacc got turned into bison. OpenSSL and SFLC are suggesting lack of consent towards an action, indicates consent towards that action. According to that: If we do not hear from you, we will assume that you have no objection. We are providing a full week notice to the community to consider this, then we will continue with this innocuous procedure. ps. If the bcc to reach you bounced, sorry.
Re: regarding OpenSSL License change
So did anyone who replied with "NO" get a followup to "reconsider"? I only "contributed" some doc fixes, so my "vote" doesn't really mean much.
Re: regarding OpenSSL License change
> So did anyone who replied with "NO" get a followup to "reconsider"? So far, everyone who says no is getting a mail from Rich Salz.
Re: regarding OpenSSL License change
> > If we do not hear from you, we will assume that you have no objection. > > So, they will claim that, by not responding, the recipient agreed. > > Some jurisdictions I am aware of accept verbal contracts or this kind > of written contracts, since civil proceedings will not be held up to a > high standard of proof. Even then, there must have been evidence of a > contractual agreement, ie. no response = no agreement. > > I say the lawyers are now working to prove that no response means the > potential recipient agreed. > > If this email has been caught by enough spam filters, they will claim > the majority agreed. > Dude, you are being melodramatic it is great that someone found a way to convert between licenses. AGPL -> GPL -> ISC -> PD thumbs up to the people who found a shortcut