> 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
>
> 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
> 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
>
> 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
> 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
> 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:
> 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
> 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
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.
>
> 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.
> 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.
> 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
> 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
> 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
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
>
>
> 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
> 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.
> 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
> 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
>>
> 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
> 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.
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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:
> 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
> 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
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
>
> 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
> On Dec 24, 2018, at 9:51 PM, m...@netbsd.org wrote:
>
> Heavily contended whitespace
Cage match material.
-- thorpej
> 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
> 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
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:
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
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);
>> -
> 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
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:
>
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:
> 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
> 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
> 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
> 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.
>
>
> 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
> 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
> 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:
>
> 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
> 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
> 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
> 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
> 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
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
> 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
> On May 24, 2018, at 10:45 PM, Kamil Rytarowski wrote:
>
> Fixed!
Confirmed! Thanks!
-- thorpej
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
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
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
>
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
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
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
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
> 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
>
> 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
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
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
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
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
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
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
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
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.
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
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
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:
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
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);
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
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
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
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
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:
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
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
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
101 - 192 of 192 matches
Mail list logo