Re: CVS commit: src/etc/rc.d

On Aug 3, 2009, at 10:45 AM, Perry E. Metzger wrote: Module Name:src Committed By: perry Date: Mon Aug 3 17:45:48 UTC 2009 Modified Files: src/etc/rc.d: named ntpdate Log Message: ntpdate can't work without named because a modern ntp.conf has dns names in it. We

Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/include

On Aug 21, 2009, at 10:29 AM, Matt Thomas wrote: Module Name:src Committed By: matt Date: Fri Aug 21 17:29:42 UTC 2009 Modified Files: src/sys/arch/mips/include [matt-nb5-mips64]: types.h Log Message: Adapt to ABI variations. Make sure mips_reg_t == register_t. Add

Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/include

On Aug 22, 2009, at 4:30 PM, Matt Thomas wrote: On Aug 22, 2009, at 4:25 PM, Jason Thorpe wrote: On Aug 21, 2009, at 10:29 AM, Matt Thomas wrote: Module Name:src Committed By: matt Date: Fri Aug 21 17:29:42 UTC 2009 Modified Files: src/sys/arch/mips/include [matt

Re: CVS commit: [matt-nb5-mips64] src/sys/conf

On Sep 4, 2009, at 9:19 PM, Matt Thomas wrote: On Sep 4, 2009, at 8:59 PM, Izumi Tsutsui wrote: Modified Files: src/sys/conf [matt-nb5-mips64]: Makefile.kern.inc Log Message: Don't abort if DBSYM fails. It was intentionally changed to fatal:

Re: CVS commit: src/usr.sbin/puffs/rump_smbfs

On Sep 18, 2009, at 9:10 AM, David Laight wrote: It is all rather similar to the proliferation of memory pools - for things where 'malloc' would be fine. The old-school kernel malloc was almost never fine ... but pools have another advantage -- use of a direct-mapped segment on

Re: CVS commit: src/sys

On Oct 2, 2009, at 8:48 AM, Antti Kantee wrote: Module Name:src Committed By: pooka Date: Fri Oct 2 15:48:42 UTC 2009 Modified Files: src/sys/conf: files src/sys/kern: kern_subr.c Added Files: src/sys/kern: subr_humanize.c Log Message: Give

Re: CVS commit: src/lib/libc/arch/m68k/sys

On Oct 3, 2009, at 3:28 PM, Frank Wille wrote: Module Name:src Committed By: phx Date: Sat Oct 3 22:28:33 UTC 2009 Modified Files: src/lib/libc/arch/m68k/sys: cerror.S Log Message: SystemV-R4 ABI for M68k returns pointers in %a0, so we have to make sure that CERROR

Re: CVS commit: src/etc/rc.d

On Oct 6, 2009, at 1:22 AM, Adam Hamsik wrote: Hi, On Oct,Tuesday 6 2009, at 9:03 AM, Alan Barrett wrote: On Mon, 05 Oct 2009, Adam Hamsik wrote: Modified Files: src/etc/rc.d: mountall Log Message: Add support for mounting zfs filesystems to mountall script. ZFS configuration

Re: panic? - Re: CVS commit: src

Surprising, since I specifically try to avoid an xcall in that case. I'll look later today. -- thor...@iphone On Oct 17, 2009, at 3:41 AM, Frank Kardel kar...@netbsd.org wrote: Hi Jason ! I now get a KASSERT() assertion failure during boot in subr_xcall.c:199: KASSERT(xc_tailp xc_headp);

Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs

On Oct 29, 2009, at 4:25 PM, Bill Stouder-Studenmund wrote: Where you able to look at the repository at macosforge.org before it shut down? I think that would show a take at solving similar issues. Note that the XNU vnode lifecycle, referencing, and locking implementation is significantly

Re: CVS commit: src

On Nov 2, 2009, at 9:08 PM, David Young wrote: Module Name: src Committed By: dyoung Date: Tue Nov 3 05:08:19 UTC 2009 Modified Files: src/sys/arch/i386/i386: copy.S Added Files: src/share/man/man9/man9.i386: return_address.9 src/sys/arch/i386/include:

Re: CVS commit: src

On Nov 18, 2009, at 2:28 PM, Thomas E. Spanjaard wrote: Jason Thorpe wrote: On Nov 18, 2009, at 12:40 PM, David Young wrote: I see. I will describe spllower(9) and splraise(9) in an i386 page, instead. They should not be documented at all. They are not interfaces that are meant

Re: CVS commit: src/sys/dev/acpi

On Dec 3, 2009, at 1:04 PM, Christoph Egger wrote: Module Name: src Committed By: cegger Date: Thu Dec 3 21:04:29 UTC 2009 Modified Files: src/sys/dev/acpi: acpi.c files.acpi Added Files: src/sys/dev/acpi: acpi_pci.c acpi_pci.h Log Message: Enumerate ACPI PCI

Re: CVS commit: src/usr.sbin/powerd

On Jan 26, 2010, at 12:37 PM, Jukka Ruohonen wrote: * Apparently there is only a single location for the scripts. Thus, remove the references to /etc/powerd/scripts/apm and /etc/powerd/scripts/acpi. This is incorrect. apm vs. acpi vs. whatever else.. the code still has support for them.

Re: CVS commit: src/usr.sbin/powerd

On Jan 28, 2010, at 12:19 AM, Martin Husemann wrote: - it is unclear how scripts could make use of the fact which subsystem triggered the pmf event they are dealing with When I wrote that code, I did hot have a concrete example usage scenario for power-type-specific scripts, but since

Re: CVS commit: src

On Feb 3, 2010, at 12:56 PM, Roy Marples wrote: Module Name: src Committed By: roy Date: Wed Feb 3 20:56:54 UTC 2010 Modified Files: src/lib/libterminfo: Makefile genhash genman genthash src/tools: Makefile Added Files: src/lib/libterminfo: hash.c

Re: CVS commit: src/sys/dev/pci

On Feb 4, 2010, at 1:13 AM, SAITOH Masanobu wrote: Module Name: src Committed By: msaitoh Date: Thu Feb 4 09:13:23 UTC 2010 Modified Files: src/sys/dev/pci: if_wm.c if_wmreg.h Log Message: - Count Receive error, CRC error, Alignment error, Symbol error, Sequence

Re: CVS commit: src/sys/uvm

On Feb 12, 2010, at 6:36 AM, Hubert Feyrer wrote: Replacing common code with a function sounds ok, but I've never seen either size or importance as justification of a goto. goto is a useful construct, and there is nothing wrong with using it in the way it is being used here. -- thorpej

Re: CVS commit: src/external/cddl/osnet/lib/libnvpair

On Feb 17, 2010, at 11:10 AM, Nick Hudson wrote: On Wednesday 17 February 2010 17:36:32 Christos Zoulas wrote: Module Name: src Committed By:christos Date:Wed Feb 17 17:36:32 UTC 2010 Modified Files: src/external/cddl/osnet/lib/libnvpair: Makefile Log

Re: CVS commit: src/sys/dev/cardbus

On Mar 4, 2010, at 10:49 AM, David Young wrote: Use %zu and %zx for printf'ing bus_size_t. These aren't quite right. We should probably define PRIxxx macros for the bus.h scalar types. -- thorpej

Re: CVS commit: src/sys

On Apr 12, 2010, at 3:15 PM, Antti Kantee wrote: Module Name: src Committed By: pooka Date: Mon Apr 12 22:15:32 UTC 2010 Modified Files: src/sys/conf: files src/sys/kern: kern_lwp.c src/sys/sys: lwp.h Added Files: src/sys/kern: subr_lwp_specificdata.c

Re: CVS commit: src/sys/arch/alpha/conf

They would have conflicted already in the old stuff. This would be a great application for using direct configuration of i2c on this platform. -- thorpej Sent from my iPhone. > On May 14, 2018, at 6:11 PM, Jonathan A. Kollasch wrote: > > Module Name:src > Committed

Re: CVS commit: src/sys/arch/alpha/conf

to be able to handle “foo0” being specified at multiple parents (but it would only attach one of them). Has that changed? -- thorpej Sent from my iPhone. > On May 14, 2018, at 6:24 PM, Jason Thorpe <thor...@me.com> wrote: > > They would have conflicted already in the old stuff. This w

Re: CVS commit: src/sys/dev

> On May 11, 2018, at 12:41 AM, Maya Rashish wrote: > > Module Name: src > Committed By: maya > Date: Fri May 11 07:41:11 UTC 2018 > > Modified Files: > src/sys/dev/ic: bwfm.c bwfmreg.h bwfmvar.h > src/sys/dev/sdmmc: if_bwfm_sdio.c >

Re: CVS commit: src/sys/dev

Still, it’ll make it easier if we ever need to consult the foreign driver again. A starting point to start looking at their diffs. -- thorpej Sent from my iPhone. > On May 11, 2018, at 9:56 AM, m...@netbsd.org wrote: > > initially I picked up the revisions one by one, but found out some > of

Re: CVS commit: src/sys

I can make the Alpha pmap changes if someone’s willing to test them (I no longer have Alpha hardware). -- thorpej Sent from my iPhone. > On May 19, 2018, at 8:03 AM, Jaromir Dolecek wrote: > > implement the new interface for amd64; I hear alpha and mips might be >

Re: CVS commit: src/sys

Sent from my iPhone. > On May 19, 2018, at 8:16 AM, Jason Thorpe <thor...@me.com> wrote: > > I can make the Alpha pmap changes if someone’s willing to test them (I no > longer have Alpha hardware). > > -- thorpej > Sent from my iPhone. > >> On May 19, 2018

Re: CVS commit: src/sys/arch/alpha/conf

Can you send me dmesg from this machine? We should be using direct-config if we can. -- thorpej Sent from my iPhone. > On May 15, 2018, at 11:25 AM, Julian Coleman wrote: > > Hi, > >> Oh, but to be clear, the iic instances themselves would not be in conflict, >> because

Re: CVS commit: src/tests/lib/libc/sys

This change seems to have broken building on 32-bit platforms (certainly at least for 32-bit ARM): # compile sys/t_ptrace_wait.o /nbsd/tools/bin/armv6--netbsdelf-eabihf-gcc -O2 -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers

Re: CVS commit: src/tests/lib/libc/sys

> On May 24, 2018, at 10:45 PM, Kamil Rytarowski wrote: > > Fixed! Confirmed! Thanks! -- thorpej

Re: CVS commit: src/sys

> On May 25, 2018, at 11:23 AM, Jaromír Doleček > wrote: > > 2018-05-22 12:18 GMT+02:00 Martin Husemann : >> Here are timing results: > > While 37% speedup is nice, I see there isn't nearly as huge difference > as for my machine. Could you

Re: CVS commit: src/sys/arch/x86/x86

> On Jun 7, 2018, at 7:59 AM, m...@netbsd.org wrote: > > You've changed a default and selectively fixed the one driver that > people noticed breaks from it. How do you know the rest aren't broken? As you know, there is very little certainty in this world. For example, how can I be certain

Re: CVS commit: src/sys/arch/arm/broadcom

> On Jun 7, 2018, at 5:14 AM, Jonathan A. Kollasch > wrote: > > I don't disagree. That said, making use of this hardware design did not > seem the most straightforward to me. If you can find a better way to do > it, that'd be great. Yah, it’s definitely awkward to use, although one

Re: CVS commit: src

> On May 27, 2018, at 5:15 AM, Jared McNeill wrote: > > Where did you get the compat strings used in tsllux_compats? Linux uses > "amstaos" as vendor prefix, and always exact chip IDs (never anything like > tsl256x). Thin air. I’ll update them. > > > On Sun, 27

Re: CVS commit: src/sys/dev/sysmon

Unknown of course -- thorpej Sent from my iPhone. > On May 26, 2018, at 2:15 PM, Jason R Thorpe wrote: > > Module Name:src > Committed By:thorpej > Date:Sat May 26 21:15:46 UTC 2018 > > Modified Files: >src/sys/dev/sysmon: sysmon_envsys.c > > Log

Re: CVS commit: src/sys/dev/fdt

> On Jun 20, 2018, at 2:06 AM, Jared McNeill wrote: > > Not a fan of this, some of these paths can get fairly long (boot the > VEXPRESS_A15 kernel to see for yourself) and the path is only really useful > if you are debugging something. Sigh. > If you want to see the debugging information

Re: CVS commit: src/sys/dev/fdt

> On Jun 20, 2018, at 9:56 AM, Jared McNeill wrote: > > On Wed, 20 Jun 2018, Jason Thorpe wrote: > >> ofctl(8) is pretty useless for this purpose because it doesn't show you >> which driver instance has attached to a given device tree node. As for >> p

Re: CVS commit: src/sys/dev/fdt

> On Jun 20, 2018, at 12:29 PM, Jared McNeill wrote: >> Sure, but where is the code for the brcm2835 platform that *processes* it? >> I see stuff for parsing console / fb options, but not for standard boot >> flags. > > Firmware puts the string in /chosen/bootargs and we pick it up here: >

Re: CVS commit: src/sys/dev/i2c

> On Jun 30, 2018, at 10:50 AM, Frank Kardel wrote: > > Hi Jason ! > > It is not so odd as your comment suggests. The I2C address is stored in the > device EEPROM and perfectly survives a power off. Ah! If the data sheet mentions this fact, I completely missed it. I'm afraid I probably

Re: CVS commit: src/sys/arch/aarch64

> On Aug 4, 2018, at 2:09 AM, Maxime Villard wrote: > > Regarding the DDB ifndef, probably there must be > a bit in ARM64 saying "disable page protection", so it could be set when > we enter DDB, and we could remove the ifndef. It only matters when setting / removing breakpoints, so it seems

Re: CVS commit: src/sys/arch/aarch64

> On Aug 5, 2018, at 1:55 AM, Martin Husemann wrote: > > On Sat, Aug 04, 2018 at 06:33:20AM -0700, Jason Thorpe wrote: >> It only matters when setting / removing breakpoints, so it seems like >> you want to defer changing page protection right until then. > >

Re: Merge majors.{arm32,aarch64} into single file (Re: CVS commit: src/sys/arch/evbarm/conf)

> On Aug 18, 2018, at 5:02 PM, Rin Okuyama wrote: > > (1) rename majors.arm32 to majors.arm > (2) remove majors.aarch64 > (3) make everyone include majors.arm > > I will commit if there's no objection. Correct. Thank you for making this change. -- thorpej

Re: CVS commit: src/sys/arch/evbarm/conf

> On Aug 18, 2018, at 7:59 AM, Rin Okuyama wrote: > > On 2018/08/18 20:08, Rin Okuyama wrote: >> Ah, then it should be "if ARM32". It was "if arm32" in rev. 1.31. > > Sorry, not 1.31 but 1.30. That's because all options are normalized to lower-case. -- thorpej

Re: CVS commit: src/sys/arch/evbarm/conf

> On Aug 18, 2018, at 8:49 AM, Rin Okuyama wrote: > > On 2018/08/19 0:06, Jason Thorpe wrote: >>> On 2018/08/18 20:08, Rin Okuyama wrote: >>>> Ah, then it should be "if ARM32". It was "if arm32" in rev. 1.31. >>> >>> So

Re: CVS commit: src/sys/kern

> On Apr 13, 2018, at 12:24 PM, matthew green wrote: > > we could also make this only relevant on ports with cpus that > have faster cpus, leaving older systems with smaller logs. > (the seconds part shouldn't change, i think, as there is no > reason to believe any port has

Re: CVS commit: src

> On Jan 1, 2019, at 8:02 AM, Robert Swindells wrote: > > How does the usage of libLLVM from MesaLib make use of the LLVM headers > at *runtime* ? > > If they are not needed at runtime then why do they need to be installed > on a target machine ? What's needed on the target machine are the

Re: CVS commit: src

> On Jan 1, 2019, at 6:34 AM, Martin Husemann wrote: > > Can you explain how the MesaLib build uses llvm? > > This kinda sounds like you need a special build time binary that would > live in $TOOLDIR and it is not exactly clear how installing some headers > helps building this tool (as you

Re: CVS commit: src

> On Jan 1, 2019, at 11:23 AM, Martin Husemann wrote: > > Yeah (and to waste more than an additional hour in a full build of > NetBSD) - but then we need a working plan how to provide libllvm as > part of the installed system, not only headers for building libmesa. I'm not arguing the merits

Re: CVS commit: src

> On Jan 1, 2019, at 8:26 PM, m...@netbsd.org wrote: > > Having two versions of LLVM in use by a binary is going to fail in > surprising ways. > > Base can be several years old at some point, increasing the odds of the > LLVM non-compatibility biting us. > And libGL is very widely used.

Re: CVS commit: src

> On Jan 1, 2019, at 9:23 PM, m...@netbsd.org wrote: > > I'll note I don't know of a single package using LLVM and a library as > well as libGL, even though it looks like it should be a likely scenario. > > The closest example was Octave that uses 3D graphs (with acceleration) > and at some

Re: CVS commit: src

> On Jan 1, 2019, at 9:53 PM, m...@netbsd.org wrote: > >> You're conflating two things that aren't related. Mesa's use of LLVM is >> conceptually similar to the "Canadian cross", and at no point should the >> compiler run-times of the "build", "host", or "target" systems ever >>

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

> On Jan 6, 2019, at 5:36 AM, Martin Husemann wrote: > > On Sun, Jan 06, 2019 at 08:31:53AM -0500, Greg Troxel wrote: >> Why do we generate code with unaligned access in user space? That seems >> surprising, if the processor isn't happy about it. > > The processor is happy with it, both in

Re: CVS commit: src/sys/net

Panic seems not optimal. A rate limited log message at LOG_ERROR seems better. -- thorpej Sent from my iPhone. > On Dec 13, 2018, at 12:54 PM, Rin Okuyama wrote: > > Module Name:src > Committed By:rin > Date:Thu Dec 13 20:54:50 UTC 2018 > > Modified Files: >src/sys/net:

Re: CVS commit: src

> On Dec 26, 2018, at 4:11 PM, Taylor R Campbell > wrote: > > Caveat: Need to > take care of the lwp name in threadpool_job_done so that we never > point at the job_name of a job in oblivion. Something like this. Index: kern_threadpool.c

Re: CVS commit: src

I think this the way to go. I’ll look at it a little later tonight. -- thorpej Sent from my iPhone. > On Dec 26, 2018, at 4:11 PM, Taylor R Campbell > wrote: > > 2. Chuck the job reference count altogether. Just use job_thread as a > proxy for whether it's in use. User must not call >

Re: CVS commit: src

> On Dec 26, 2018, at 7:52 PM, Taylor R Campbell > wrote: > > Probably wanna dereference job->job_thread _before_ setting it to > NULL! Picky, picky :-) Index: kern_threadpool.c === RCS file:

Re: CVS commit: src

> On Dec 26, 2018, at 10:04 AM, Taylor R Campbell > wrote: > > Can you use a module initialization routine for this, or call it in > main if you don't want to deal with modules, instead of sprinkling > RUN_ONCE in various places? I thought about using a module initializer, the timing of

Re: CVS commit: src

> On Dec 26, 2018, at 5:25 PM, Jason Thorpe wrote: > > I think this the way to go. I’ll look at it a little later tonight. > > -- thorpej > Sent from my iPhone. > >> On Dec 26, 2018, at 4:11 PM, Taylor R Campbell >> wrote: >> >> 2. Chuck

Re: CVS commit: src

> On Dec 26, 2018, at 8:32 PM, Taylor R Campbell > wrote: > > LGTM if it works! Doesn't trip any asserts in the unit tests... I'm going to push this in and then do the ref counting change as a separate commit. -- thorpej

Re: CVS commit: src

> On Dec 27, 2018, at 6:04 AM, Jason Thorpe wrote: > > -- job_hold remains lockless, but job_rele can only be called **without** the > job_lock held, because it needs to acquire the lock in the unlikely case it > performs a cv_broadcast (see below). Also need a job_rele_lock

Re: CVS commit: src/sys/kern

> On Dec 24, 2018, at 9:51 PM, m...@netbsd.org wrote: > > Heavily contended whitespace Cage match material. -- thorpej

Re: CVS commit: src/sys/dev/i2c

> On Dec 14, 2018, at 2:05 PM, Michael Lorenz wrote: > > Module Name: src > Committed By: macallan > Date: Fri Dec 14 22:05:36 UTC 2018 > > Modified Files: > src/sys/dev/i2c: ds1307.c files.i2c > > Log Message: > add options DSRTC_YEAR_START_2K for machines which use 2000 and

Re: CVS commit: src/sys/dev/usb

> On Dec 15, 2018, at 2:30 AM, SAITOH Masanobu wrote: > > Module Name: src > Committed By: msaitoh > Date: Sat Dec 15 10:30:58 UTC 2018 > > Modified Files: > src/sys/dev/usb: if_urtwn.c > > Log Message: > Make IODATA WN-G150UMW work: > - Increase delay to prevent "could not

Re: CVS commit: src/sys/kern

> On Dec 3, 2018, at 11:27 AM, Christos Zoulas wrote: > > I don't think that the things that KASLR randomizes by default are useful > to debugging. I.e. you can't depend on two successive kernel crashes to > have identical PTE addresses; OTOH you can depend that the text addresses > are the

Re: CVS commit: src/sys

Fixed. > On Dec 9, 2018, at 7:50 AM, Jason Thorpe wrote: > > Investigating now... > >> On Dec 9, 2018, at 7:39 AM, m...@netbsd.org wrote: >> >> On Sat, Dec 08, 2018 at 05:46:15PM +, Jason R Thorpe wrote: >>> @@ -2508,13 +2525,7 @@ c

Re: CVS commit: src/sys

Investigating now... > On Dec 9, 2018, at 7:39 AM, m...@netbsd.org wrote: > > On Sat, Dec 08, 2018 at 05:46:15PM +, Jason R Thorpe wrote: >> @@ -2508,13 +2525,7 @@ comcnattach(bus_space_tag_t iot, bus_add >> { >> struct com_regs regs; >> >> -memset(, 0, sizeof regs); >> -

Re: CVS commit: src/external/apache2/mDNSResponder/dist/mDNSPosix

Thanks! This has been bothering me for a while, but I hadn’t had a chance to look at it. -- thorpej Sent from my iPhone. > On Nov 19, 2018, at 8:14 AM, Christos Zoulas wrote: > > Module Name:src > Committed By:christos > Date:Mon Nov 19 08:14:28 UTC 2018 > > Modified Files:

Re: CVS commit: src/sys/dev

Shouldn't this be instead? IMO, pulling in implicitly is generally harmful (there is a lot of namespace pollution there...) > On Nov 19, 2018, at 9:23 AM, Maya Rashish wrote: > > Module Name: src > Committed By: maya > Date: Mon Nov 19 09:23:05 UTC 2018 > > Modified Files: >

Re: CVS commit: src/etc

> On Jan 13, 2019, at 5:08 PM, David Holland > wrote: > > Is there a way we could, for example, leverage the current hacks for > chowning console devices to grant access to wpa_supplicant? Some of this could be achieved with ttyaction(5), certainly. -- thorpej

Re: CVS commit: src/etc

> On Jan 13, 2019, at 5:21 AM, Greg Troxel wrote: > > Even if you have to be root, these changes are still hugely useful. > "sudo wpa_cli" is not that hard, even if it seems like it should not be > necessary. ...but made slightly more annoying seeing as how sudo is not part of the base OS.

Re: Weak x86 aliases

> On Dec 28, 2018, at 6:06 AM, Cherry G.Mathew wrote: > > I don't like the imperative in your tone. NVMM is the user of modloader, > not PVHVM. So if you feel like your usecase needs fixing, I'd say it's > your problem - or don't use modules, but see below. ...but as the person who committed

Re: CVS commit: src

> On Dec 26, 2018, at 4:11 PM, Taylor R Campbell > wrote: > > Job reference counting is currently slightly busted -- my draft for > threadpool_schedule_job didn't increment it correctly, and your > threadpool_schedule_job doesn't handle failure in threadpool_job_hold. Ok, I looked at this

Re: Weak x86 aliases

> On Dec 28, 2018, at 10:14 AM, Mathew, Cherry G. wrote: > > ic, this probably explains why it's used sparingly so far. Thanks for the > explanation. I'll try to educate myself on this wrt enabling this for modload. We use weak symbols all over the place in user space. It's just that the

Re: CVS commit: src/sys/arch/evbmips/conf

> On Dec 30, 2018, at 6:51 AM, Sevan Janiyan wrote: > > Modified Files: > src/sys/arch/evbmips/conf: ADM5120 ADM5120-NB ADM5120-USB ALCHEMY AP30 > CI20 CPMBR1400 DB120 ERLITE GDIUM LINKITSMART7688 LOONGSON MALTA > MERAKI RB153 RB433UAH SBMIPS WGT624V3 XLSATX ZYXELKX

Re: Weak x86 aliases

> On Dec 28, 2018, at 6:44 PM, John Nemeth wrote: > > However, having said that, I suspect that your work with PVHVM > (and presumably PVH after that) will make the idea of having seperate > modules for Xen obsolete. I.e. it appears to me that we're headed > to a world where a single

Re: CVS commit: src/sys/arch/evbmips/conf

> On Dec 30, 2018, at 4:34 PM, Sevan Janiyan wrote: > > On 30/12/2018 16:16, Jason Thorpe wrote: >> Maybe create a std.evmips that the various std. files can >> include to get options that you want for everything? > > Noted, I was thinking about the pull up

Re: Weak x86 aliases

> On Dec 28, 2018, at 1:32 PM, Paul Goyette wrote: > > The in-kernel linker doesn't deal with weak symbols at all. It would > need a lot of thought to get it right. For example, if module A > (containing a weak reference) gets loaded, its weak references don't > resolve. Then module B gets

Re: CVS commit: src/sys/dev/pci

> On Jan 28, 2019, at 8:11 AM, Masanobu SAITOH wrote: > > On 2019/01/28 15:07, Jason Thorpe wrote: >> Doesn’t it seem a little dangerous to just blindly enable? > > You mean it should be enable only when the secondary bridge is configured > correctly? > > Bo

Re: CVS commit: src/sys/dev/pci

Doesn’t it seem a little dangerous to just blindly enable? -- thorpej Sent from my iPhone. > On Jan 28, 2019, at 6:09 AM, SAITOH Masanobu wrote: > > Module Name:src > Committed By:msaitoh > Date:Mon Jan 28 04:09:51 UTC 2019 > > Modified Files: >src/sys/dev/pci: ppb.c > >

Re: CVS commit: src/sys/compat/freebsd

> On Apr 6, 2019, at 10:45 AM, Robert Elz wrote: > > Actually, fetching & storing registers (register_t) is a common enough > thing that it might be worth having ufetch_reg (and ustore_reg), probably > as MD #defines that map into one of the other calls. The only situation I know of where

Re: CVS commit: src/sys/arch/x86/acpi

> On Mar 3, 2019, at 10:31 AM, m...@netbsd.org wrote: > > Maybe we can use the longer name to avoid the confusion? PG_WIRED > > (PG_W as writable exists in other archs, and there's precedence for > PG_WIRED too) Agreed, PG_WIRED is a better name for this. -- thorpej

Re: CVS commit: src/sys/arch/x86/x86

> On May 15, 2019, at 9:19 PM, Maxime Villard wrote: > > Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit : >> Module Name: src >> Committed By:msaitoh >> Date:Thu May 16 02:36:30 UTC 2019 >> Modified Files: >> src/sys/arch/x86/x86: procfs_machdep.c >> Log Message:

Re: CVS commit: src/sys

> On May 13, 2019, at 7:17 AM, Greg Troxel wrote: > > 2) Your option 2 seems to involve two things at once: > > - migration to lwp_specificadata > - using DEBUG instead of DIAGNOSTIC to control the leak check feature > > I do not understand why changing the nature of the implementation is

Re: CVS commit: src/tools

> On May 7, 2019, at 3:17 AM, matthew green wrote: > >> Diff is NOT reversed. > > ah yes, i see. please commit. I bootstrapped the whole system 3 or 4 times without having this extra dependency and didn't see a build failure, so I'm a little confused, but whatever. Thanks for fixing it.

Re: CVS commit: src/tools

> On May 7, 2019, at 12:32 PM, matthew green wrote: > > did you start from a clean *tooldir*? that would be the bit > that matters. if one had an existing tooldir with nbpax in > it, then this problem wouldn't occur. > > that's my only guess to what happened... Yah, that's probably it.

Re: CVS commit: src/tools

I'll take a look at this this evening. > On May 7, 2019, at 3:52 PM, Herbert J. Skuhra wrote: > > On Tue, 07 May 2019 12:23:12 +0200, "J. Hannken-Illjes" wrote: >> >> >>> On 7. May 2019, at 12:17, matthew green wrote: >>> Diff is NOT reversed. >>> >>> ah yes, i see. please commit. >

Re: CVS commit: src/tools

> On May 7, 2019, at 3:52 PM, Herbert J. Skuhra wrote: > > On Tue, 07 May 2019 12:23:12 +0200, "J. Hannken-Illjes" wrote: >> >> >>> On 7. May 2019, at 12:17, matthew green wrote: >>> Diff is NOT reversed. >>> >>> ah yes, i see. please commit. > > Crossbuilding is still broken. I

Re: CVS commit: src/sys/compat/sys

> On Jun 26, 2019, at 7:10 PM, matthew green wrote: > >> Always include the 32 bit structure and definitions on _LP64 regardless >> of compat32 being on or off, because we want the headers to work when >> compiling modular kernels. Of course the 32 bit structs do not make sense >> on platforms

Re: CVS commit: src

> On Sep 2, 2019, at 10:36 PM, Robert Elz wrote: > > I doubt that any of them really are truly > case insensitive ... rather than are insenstive to the case of ascii > chars, and that's usually it. APFS on macOS is truly case-insensitive, not just for ASCII. FWIW. -- thorpej

Re: CVS commit: src

> On Sep 3, 2019, at 5:04 AM, Sevan Janiyan wrote: > > On 03/09/2019 12:59, Brad Spencer wrote: >> One possible alternative to that is to install OpenZFS on MacOS and >> create a ZFS filesystem inside of whatever... > > Or a disk image which is case sensitive (hfs/apfs) problem is then that >

Re: Leak Sanitizer - how to suppress leaks

> On Sep 12, 2019, at 11:09 AM, Robert Elz wrote: > > To me it seems apparent that the sanatiser is detecting the local variable > in main() go out of scope when main() returns, and so the value it contains > (the pointer to the allocated memory) is lost, and so it is determined that > there

Re: CVS commit: src/sys

> On Jul 23, 2019, at 9:14 AM, Rin Okuyama wrote: > > Ah, you are right. We leaks uninitialized memory via mmap. > > However, I'm not sure that it is safe to write DMA buffer > above sc->sc_vramsize after bus_dmamap_load? > > Thoughts, ARM experts? Since fundamental memory allocation is

Re: CVS commit: src/sys

> On Jul 23, 2019, at 10:07 AM, Jason Thorpe wrote: > > > >> On Jul 23, 2019, at 9:14 AM, Rin Okuyama wrote: >> >> Ah, you are right. We leaks uninitialized memory via mmap. >> >> However, I'm not sure that it is safe to write DMA buffer >

Re: CVS commit: src/sys/dev/ic

Should we make a PRIxxx macro for it? -- thorpej Sent from my iPhone. > On Sep 21, 2019, at 5:57 AM, Robert Elz wrote: > > Module Name:src > Committed By:kre > Date:Sat Sep 21 12:57:25 UTC 2019 > > Modified Files: >src/sys/dev/ic: mpt.c > > Log Message: > bus_addt_t is

Re: case-sensitive APFS volumes

> On Nov 13, 2019, at 1:57 AM, Christoph Badura wrote: > > Just HTF does one add the same cryptographic users that the / volume has? > TFM does not tell. It just says that "indeed, they should be added before > encryption". Hm, I'm not actually sure. I'll do a bit of research. > Maybe we

Re: CVS commit: src/sys/kern

> On Dec 9, 2019, at 1:08 PM, Paul Goyette wrote: > > On Mon, 9 Dec 2019, Andrew Doran wrote: > >> Module Name: src >> Committed By:ad >> Date:Mon Dec 9 21:05:23 UTC 2019 >> >> Modified Files: >> src/sys/kern: kern_mutex.c >> >> Log Message: >> - Add a

Re: CVS commit: src/sys/arch/arm/broadcom

> On Nov 28, 2019, at 2:21 AM, Jared McNeill wrote: > > I should have commented the code in gicv3 so that you would have realized it > was “unnecessarily complicated” for a reason :) Ok, I'll fix and add a comment. > > The interrupt_distribute(9) API makes an assumption that the return

Re: CVS commit: src/external/bsd/libarchive/dist/libarchive

I repled to you and gson off-list. > On Feb 25, 2020, at 8:24 AM, Kamil Rytarowski wrote: > > On 25.02.2020 16:24, Andreas Gustafsson wrote: >> Kamil Rytarowski wrote: >>> To generate a diff of this commit: >>> cvs rdiff -u -r1.1.1.4 -r1.2 \ >>>

Re: CVS commit: src/sys/arch/evbarm/conf

> On Jan 25, 2020, at 4:26 AM, Jared D. McNeill wrote: > > Module Name: src > Committed By: jmcneill > Date: Sat Jan 25 12:26:58 UTC 2020 > > Modified Files: > src/sys/arch/evbarm/conf: GENERIC GENERIC64 > > Log Message: > Follow amd64 and set AUDIO_BLK_MS=4 by default This

Re: CVS commit: src/sys/arch/evbarm/conf

> On Jan 25, 2020, at 6:31 AM, Christos Zoulas wrote: > >> This seems a little silly to have in the kernel configuration file. I >> think there's an argument to be made that there should be a header that >> sets these defaults that can be tuned per-platform (or even some >> functionality to

  1   2   >