On Mon, Jul 11, 2016 at 07:37:00AM +, Ryota Ozaki wrote:
> Module Name: src
> Committed By: ozaki-r
> Date: Mon Jul 11 07:37:00 UTC 2016
>
> Modified Files:
> src/sys/net: route.c
> src/sys/netinet: ip_flow.c
> src/sys/netinet6: ip6_flow.c nd6.c
>
> Log Message:
>
On Tue, Aug 25, 2015 at 03:59:00PM +0300, Andreas Gustafsson wrote:
Martin Husemann wrote:
I have another evbarm machine now hanging as well, so it is not just alpha.
The sparc test runs on babylon5 are affected, too. I just committed a
fix, let's see if it works.
Alpha worked, will
Martin Husemann wrote:
I have another evbarm machine now hanging as well, so it is not just alpha.
The sparc test runs on babylon5 are affected, too. I just committed a
fix, let's see if it works.
--
Andreas Gustafsson, g...@netbsd.org
On Wed, Aug 19, 2015 at 12:02:55PM +, Andreas Gustafsson wrote:
Module Name: src
Committed By: gson
Date: Wed Aug 19 12:02:55 UTC 2015
Modified Files:
src/sys/kern: tty.c
Log Message:
When closing a tty, limit the amount of time spent waiting for the
output to drain
(moved to tech-kern, becuase source-changes-d is too buried and this is
only happening there because it's post-commit discussion rather than
pre-commit review)
Michael van Elst mlel...@serpens.de writes:
On Tue, May 05, 2015 at 07:47:09PM -0400, Greg Troxel wrote:
Michael van Elst
On Feb 17, 7:16pm, msai...@execsw.org (Masanobu SAITOH) wrote:
-- Subject: Re: PR/49328 CVS commit: src/sys/dev/pci/ixgbe
| On 2015/02/17 19:06, 6b...@6bone.informatik.uni-leipzig.de wrote:
| On Wed, 4 Feb 2015, Christos Zoulas wrote:
| ...
| christos
|
| I have tested NetBSD 7.99.x
On 2015/02/17 19:06, 6b...@6bone.informatik.uni-leipzig.de wrote:
On Wed, 4 Feb 2015, Christos Zoulas wrote:
...
christos
I have tested NetBSD 7.99.x
The problem is now solved. The PR can be closed.
Regards
Uwe
Thanks. I'll send the pullup requet to netbsd-7.
--
On Wed, 4 Feb 2015, Christos Zoulas wrote:
...
christos
I have tested NetBSD 7.99.x
The problem is now solved. The PR can be closed.
Regards
Uwe
On Feb 4, 2:16pm, msai...@execsw.org (Masanobu SAITOH) wrote:
-- Subject: Re: PR/49328 CVS commit: src/sys/dev/pci/ixgbe
| Yes, it works with LOCKDEBUG.
|
| ifconfig up works
| ifconfig down works
| ifconfig up - down repeatedly works while forwarding works
| reboot
Hi, all.
I fixed and committed some smallproblem to -current.
The rest is:
- Revert ixgbe_netbsd.c rev. 1.2
- make CORE_LOCK adaptive
- Release spin lock while reinitializing the jumb buffer structure.
Is it OK to commit?
Index: ixgbe.c
On 2015/02/04 14:08, Christos Zoulas wrote:
On Feb 4, 1:49pm, msai...@execsw.org (Masanobu SAITOH) wrote:
-- Subject: Re: PR/49328 CVS commit: src/sys/dev/pci/ixgbe
| Hi, all.
|
| I fixed and committed some smallproblem to -current.
|
| The rest is:
|
| - Revert ixgbe_netbsd.c
On Feb 4, 1:49pm, msai...@execsw.org (Masanobu SAITOH) wrote:
-- Subject: Re: PR/49328 CVS commit: src/sys/dev/pci/ixgbe
| Hi, all.
|
| I fixed and committed some smallproblem to -current.
|
| The rest is:
|
| - Revert ixgbe_netbsd.c rev. 1.2
| - make CORE_LOCK adaptive
On Feb 1, 10:53am, c...@chuq.com (Chuck Silvers) wrote:
-- Subject: Re: PR/49328 CVS commit: src/sys/dev/pci/ixgbe
| sure, adding an DIAGNOSTIC assertion somewhere to catch this would be
| an improvement. I'm not sure how you'd actually make the check though.
| outside LOCKDEBUG we don't track
(moving this discussion from gnats mail to tech-kern...)
On Sun, Feb 01, 2015 at 12:56:51PM -0500, Christos Zoulas wrote:
On Feb 1, 9:33am, c...@chuq.com (Chuck Silvers) wrote:
-- Subject: Re: PR/49328 CVS commit: src/sys/dev/pci/ixgbe
| that is not legal. pmap_growkernel() is not optional
In article 20140725195305.55fbb14a...@mail.netbsd.org,
Mindaugas Rasiukevicius rm...@netbsd.org wrote:
chris...@astron.com (Christos Zoulas) wrote:
In article 53d288c7.5000...@m00nbsd.net,
Maxime Villard m...@m00nbsd.net wrote:
Well, if only these architectures are running with DIAGNOSTIC,
On Sun, Jul 27, 2014 at 07:37:14PM +, Christos Zoulas wrote:
to wrap all the KMEM_ related diagnostic options in one, can separate
them from DIAGNOSTIC, so that low memory machines can choose not to turn
them on, but still have DIAGNOSTIC turned on.
I am not convinced this will be used
On Jul 27, 9:46pm, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| On Sun, Jul 27, 2014 at 07:37:14PM +, Christos Zoulas wrote:
| to wrap all the KMEM_ related diagnostic options in one, can separate
| them from DIAGNOSTIC, so that low memory machines
In article 53d22353.9090...@m00nbsd.net,
Maxime Villard m...@m00nbsd.net wrote:
Le 23/07/2014 21:51, Greg Troxel a écrit :
I realized that two things can be separated. One is whether DIAGNOSTIC
turns on features that increase the size of memory allocations, which is
my real concern. The
Le 25/07/2014 16:51, Christos Zoulas a écrit :
In article 53d22353.9090...@m00nbsd.net,
Maxime Villard m...@m00nbsd.net wrote:
Le 23/07/2014 21:51, Greg Troxel a écrit :
I realized that two things can be separated. One is whether DIAGNOSTIC
turns on features that increase the size of
In article 53d288c7.5000...@m00nbsd.net,
Maxime Villard m...@m00nbsd.net wrote:
Well, if only these architectures are running with DIAGNOSTIC, that's not a
big deal. Anyway, let's put KMEM_DIAGNOSTIC.
I like KMEM_DIAGNOSTIC, can you add it, or should I?
christos
chris...@astron.com (Christos Zoulas) wrote:
In article 53d288c7.5000...@m00nbsd.net,
Maxime Villard m...@m00nbsd.net wrote:
Well, if only these architectures are running with DIAGNOSTIC, that's
not a big deal. Anyway, let's put KMEM_DIAGNOSTIC.
I like KMEM_DIAGNOSTIC, can you add it, or
I realized that two things can be separated. One is whether DIAGNOSTIC
turns on features that increase the size of memory allocations, which is
my real concern. The other is whether the KMEM_SIZE and KMEM_REDZONE
should be on by default in -current on various architectures, which is I
think
Maxime Villard m...@netbsd.org writes:
Module Name: src
Committed By: maxv
Date: Tue Jul 22 07:38:41 UTC 2014
Modified Files:
src/sys/kern: subr_kmem.c
Log Message:
Enable KMEM_REDZONE on DIAGNOSTIC. It will try to catch overflows.
No comment on tech-kern@
I didn't see
Nick Hudson sk...@netbsd.org writes:
On 07/22/14 12:49, Greg Troxel wrote:
Maxime Villard m...@netbsd.org writes:
Module Name:src
Committed By: maxv
Date: Tue Jul 22 07:38:41 UTC 2014
Modified Files:
src/sys/kern: subr_kmem.c
Log Message:
Enable
On 07/22/14 12:49, Greg Troxel wrote:
Maxime Villard m...@netbsd.org writes:
Module Name:src
Committed By: maxv
Date: Tue Jul 22 07:38:41 UTC 2014
Modified Files:
src/sys/kern: subr_kmem.c
Log Message:
Enable KMEM_REDZONE on DIAGNOSTIC. It will try to catch overflows.
On Tue, Jul 22, 2014 at 12:54:15PM +0100, Nick Hudson wrote:
I'd guess that KMEM_REDZONE add much less than 15%.
Even if 15% were a value we'd be willing to tolerate (which I doubt),
that's 15% total, not 15% each.
Anyway, rather than shouting, can someone check what it really does
cost?
--
Indeed rebooting with an updated kernel will give active NFS clients
problems, but I am not sure we should realy care nor how we could
possibly avoid this one time issue. We have changed encoding of
filehandles before (at least once).
it's a bad thing and worth mentioning in release notes.
Hi
David Holland:
I'm not entirely clear on how this structure is actually used, which
is why I hadn't yet made this change myself after the issue came up. :-/
My observation in sys/fs/cd9660 is probably the initial cause for
this change. PR kern/48799.
I could produce a problem by exporting
On Fri, May 16, 2014 at 12:12:00AM +0200, Joerg Sonnenberger wrote:
I don't think it is a problem by itself as the file handle is opaque,
but it is certainly wasteful to not put ufid_ino first.
That is not possible, the first few bytes of the structure must match
struct fid from fstypes.h.
The
On Fri, May 16, 2014 at 03:54:44PM +, David Holland wrote:
Indeed rebooting with an updated kernel will give active NFS clients
problems, but I am not sure we should realy care nor how we could
possibly avoid this one time issue. We have changed encoding of
filehandles before (at
On Fri, May 16, 2014 at 03:54:44PM +, David Holland wrote:
The problem is that the tokens are memcmp'd, so if they include struct
padding this may not work.
All filesystems I've seen init the struct with a full memset to 0, so
all padding fields should be initialized as well.
However, we
On Fri, May 16, 2014 at 06:48:06PM +, Martin Husemann wrote:
The problem is that the tokens are memcmp'd, so if they include struct
padding this may not work.
All filesystems I've seen init the struct with a full memset to 0, so
all padding fields should be initialized as well.
On Wed, May 14, 2014 at 01:46:19PM +, Martin Husemann wrote:
Modified Files:
src/sys/ufs/ufs: inode.h
Log Message:
Make filehandles on UFS based filesystems use proper 64bit inodes.
32bit restriction noticed by Taylor R Campbell.
I suspect this isn't going to work:
On Thu, May 15, 2014 at 10:06:18PM +, David Holland wrote:
On Wed, May 14, 2014 at 01:46:19PM +, Martin Husemann wrote:
Modified Files:
src/sys/ufs/ufs: inode.h
Log Message:
Make filehandles on UFS based filesystems use proper 64bit inodes.
32bit restriction noticed
On Fri, May 16, 2014 at 12:12:00AM +0200, Joerg Sonnenberger wrote:
Modified Files:
src/sys/ufs/ufs: inode.h
Log Message:
Make filehandles on UFS based filesystems use proper 64bit inodes.
32bit restriction noticed by Taylor R Campbell.
I suspect this
On Wed, Mar 05, 2014 at 06:04:02PM +0200, Andreas Gustafsson wrote:
2. I also object to the change of kern_syctl.c 1.247.
This change attempts to work around the problems caused by the changes
to the variable types by making sysctl() return different types
depending on the value of the
Joerg, I still think this import was a bad engineering decision and should
be backed out, followed by a proposal, discussion and then re-import in
modified form.
First: it is all fine for /usr/src/lib/*, if you need it in userland for
clang, it could live there (unmodified) for now.
But for
On Thu, Oct 17, 2013 at 09:17:38AM +0200, Martin Husemann wrote:
But for kernel, I think a better design is needed.
I completely disagree that any of this provides an actual improvement.
Joerg
joerg@ wrote:
On Wed, Oct 16, 2013 at 11:36:18AM +, Martin Husemann wrote:
On Mon, Oct 14, 2013 at 01:14:58AM +, Joerg Sonnenberger wrote:
Module Name: src
Committed By: joerg
Date: Mon Oct 14 01:14:58 UTC 2013
Added Files:
On Thu, Oct 17, 2013 at 08:57:23PM +0900, Izumi Tsutsui wrote:
Anyway, our commit guidelines explicitly require Core's approval
before adding a new package into base. You violate the rule.
I didn't.
Joerg
On Oct 17, 2013, at 4:57 AM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:
Anyway, our commit guidelines explicitly require Core's approval
before adding a new package into base. You violate the rule.
That's the enough reason to revert your commit without discussion.
He did get core's
On Oct 17, 2013, at 4:57 AM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:
Anyway, our commit guidelines explicitly require Core's approval
before adding a new package into base. You violate the rule.
That's the enough reason to revert your commit without discussion.
He did get core's
On Mon, Oct 14, 2013 at 01:14:58AM +, Joerg Sonnenberger wrote:
Module Name: src
Committed By: joerg
Date: Mon Oct 14 01:14:58 UTC 2013
Added Files:
src/sys/lib/libunwind: AddressSpace.hpp CREDITS.TXT
DwarfInstructions.hpp DwarfParser.hpp LICENSE.TXT
On Wed, Oct 16, 2013 at 11:36:18AM +, Martin Husemann wrote:
On Mon, Oct 14, 2013 at 01:14:58AM +, Joerg Sonnenberger wrote:
Module Name:src
Committed By: joerg
Date: Mon Oct 14 01:14:58 UTC 2013
Added Files:
src/sys/lib/libunwind:
On Wed, Oct 16, 2013 at 05:09:25PM +0200, Joerg Sonnenberger wrote:
The need was mentioned a number of times in various threads about libc++
and clang.
But for the kernel? And the details?
Like where to place it and what to use it for?
- why is it placed in src/sys/lib instead of
On Wed, Oct 16, 2013 at 05:22:15PM +0200, Martin Husemann wrote:
On Wed, Oct 16, 2013 at 05:09:25PM +0200, Joerg Sonnenberger wrote:
The need was mentioned a number of times in various threads about libc++
and clang.
But for the kernel? And the details?
Like where to place it and what to
On Wed, Oct 16, 2013 at 05:35:54PM +0200, Joerg Sonnenberger wrote:
Look at lib/libc/Makefile?
Ok, I see it is build into libc on some archs with clang, but where is it
called?
The user interface is plain C, the rest is just an implementation
detail. The C interface creates instances of the
On Wed, Oct 16, 2013 at 06:00:56PM +0200, Martin Husemann wrote:
On Wed, Oct 16, 2013 at 05:35:54PM +0200, Joerg Sonnenberger wrote:
Look at lib/libc/Makefile?
Ok, I see it is build into libc on some archs with clang, but where is it
called?
libexecinfo, libc++, otherwise libraries that do
On Wed, Oct 16, 2013 at 06:03:57PM +0200, Joerg Sonnenberger wrote:
See link at the beginning of libunwind.cxx.
The documentation should in the source tree and should be manual pages.
Thor
On Tue, Aug 27, 2013 at 02:01:36PM +, Taylor R Campbell wrote:
This is a stop-gap on a stop-gap on a stop-gap; we really ought to
back out all of these stop-gaps, make bcm2835_rng call rnd_add_data
asynchronously to work around the original symptom, and design a real
solution when we
On Sun, Aug 25, 2013 at 09:12:56PM +, Thor Lancelot Simon wrote:
Module Name: src
Committed By: tls
Date: Sun Aug 25 21:12:56 UTC 2013
Modified Files:
src/sys/dev: rnd_private.h
src/sys/kern: init_main.c kern_rndq.c kern_rndsink.c
Log Message:
Attempt to
On Mon, Aug 26, 2013 at 11:57:28AM +0200, Martin Husemann wrote:
On Sun, Aug 25, 2013 at 09:12:56PM +, Thor Lancelot Simon wrote:
Module Name:src
Committed By: tls
Date: Sun Aug 25 21:12:56 UTC 2013
Modified Files:
src/sys/dev: rnd_private.h
Date: Mon, 26 Aug 2013 11:57:28 +0200
From: Martin Husemann mar...@duskware.de
Unfortunately this change prevents my system from booting - nothing happens
after mounting root:
root on sd0a dumps on sd0b
root file system type: ffs
and that's it - sits there idle.
Also
On Mon, 26 Aug 2013, Thor Lancelot Simon wrote:
On Mon, Aug 26, 2013 at 11:57:28AM +0200, Martin Husemann wrote:
On Sun, Aug 25, 2013 at 09:12:56PM +, Thor Lancelot Simon wrote:
Module Name:src
Committed By: tls
Date: Sun Aug 25 21:12:56 UTC 2013
Modified Files:
On Mon, Aug 26, 2013 at 04:09:52PM +, Taylor R Campbell wrote:
Can you enter ddb and get a stack trace?
It is in the idle loop, nothing interesting.
Martin
On Mon, Aug 26, 2013 at 04:09:52PM +, Taylor R Campbell wrote:
Date: Mon, 26 Aug 2013 11:57:28 +0200
From: Martin Husemann mar...@duskware.de
Unfortunately this change prevents my system from booting - nothing happens
after mounting root:
root on sd0a dumps on sd0b
On Mon, Aug 26, 2013 at 04:04:24PM -0400, Thor Lancelot Simon wrote:
On Mon, Aug 26, 2013 at 04:09:52PM +, Taylor R Campbell wrote:
Date: Mon, 26 Aug 2013 11:57:28 +0200
From: Martin Husemann mar...@duskware.de
Unfortunately this change prevents my system from booting -
On Jul 19, 2012, at 7:03 PM, Valeriy E. Ushakov wrote:
On Fri, Jul 20, 2012 at 01:26:19 +, Valeriy E. Ushakov wrote:
Module Name: src
Committed By:uwe
Date:Fri Jul 20 01:26:19 UTC 2012
Modified Files:
src/sys/dev/pci: ehci_pci.c
Log Message:
On Fri, Apr 20, 2012 at 10:58:19AM +0200, Martin Husemann wrote:
Just to be sure I understand this correctly:
- old binaries do not set the flag and continue to work
Yes.
- new binaries compiled against current sources need to be aware of this
behaviour and explicitly enable/disable it
Martin Husemann mar...@duskware.de wrote:
This (or the accompanying lib commit) breaks the
fs/puffs/t_fuzz:mountfuzz8 test case, see for example:
Here is a fix. Is it acceptable?
Index: t_fuzz.c
===
RCS file:
On Wed, Apr 18, 2012 at 12:42:50AM +, Emmanuel Dreyfus wrote:
Module Name: src
Committed By: manu
Date: Wed Apr 18 00:42:50 UTC 2012
Modified Files:
src/sys/fs/puffs: puffs_vnops.c
Log Message:
- Makesure update_va does not change vnode size when it should not. For
lars.heidie...@googlemail.com said:
we should fix the inconsistent use then, the problem ist malloc(9)
does not return page aligned memory as kmem does now, for allocations
= PAGE_SIZE and that break drm mmap
So I've tried to get DRM working again, both with your original
patch (modifying
t...@panix.com said:
This is on i386, or amd64?
i386, with i945 graphics.
best regards
Matthias
---
---
Forschungszentrum Juelich GmbH
On 01/31/2012 07:43 PM, Matthias Drochner wrote:
t...@panix.com said:
This is on i386, or amd64?
i386, with i945 graphics.
best regards
Matthias
Hi,
you can change the amount of memory allocated to the kmem_arena in
uvm_km.c currently it's 2/3 of kva-space, probably it needs to be a
On 01/31/2012 09:33 PM, Thor Lancelot Simon wrote:
On Tue, Jan 31, 2012 at 09:30:15PM +0100, Lars Heidieker wrote:
On 01/31/2012 07:43 PM, Matthias Drochner wrote:
t...@panix.com said:
This is on i386, or amd64?
i386, with i945 graphics.
best regards Matthias
Hi,
you can change
lars.heidie...@googlemail.com said:
the problem ist malloc(9) does not return page aligned memory as kmem
does now, for allocations = PAGE_SIZE and that break drm mmap
I see. drm wants both alignment semantics and a realloc().
Since it is 3rd party stuff, it sucks to add NetBSD specific
We could use the reference counter in struct cfdriver to keep driver
modules busy, but I'm not sure if the system can figure out what's
unneeded if a needed driver might be one for a hotpluggable device.
Would you treat those drivers differently? What about drivers (if_ath_pci
comes to mind)
On Tue, Oct 18, 2011 at 11:28:22AM -0400, Jared McNeill wrote:
I played around with driver module autoloading a while back, and it
worked pretty well but the implementation I came up with required
duplicating match data in module.plist.
This sounds like a step in the right direction (recording
I think you'd just need to find a way to supply that data for built-in
modules too.
On Tue, 18 Oct 2011, David Young wrote:
On Tue, Oct 18, 2011 at 11:28:22AM -0400, Jared McNeill wrote:
I played around with driver module autoloading a while back, and it
worked pretty well but the
# David Young 2011-10-18:
On Tue, Oct 18, 2011 at 11:28:22AM -0400, Jared McNeill wrote:
I played around with driver module autoloading a while back, and it
worked pretty well but the implementation I came up with required
duplicating match data in module.plist.
This sounds like a step
On Tue, Oct 18, 2011 at 12:50:58PM -0400, Jachym Holecek wrote:
# David Young 2011-10-18:
On Tue, Oct 18, 2011 at 11:28:22AM -0400, Jared McNeill wrote:
I played around with driver module autoloading a while back, and it
worked pretty well but the implementation I came up with required
Cc:ing tech-kern, to get wider feedback.
Thread started here:
http://mail-index.netbsd.org/source-changes-d/2011/08/21/msg003897.html
JM == Jean-Yves Migeon jeanyves.mig...@free.fr writes:
JM On Mon, 22 Aug 2011 12:47:40 +0200, Manuel Bouyer wrote:
This is slightly more complicated
On Mon, Aug 29, 2011 at 12:07:05PM +0200, Cherry G. Mathew wrote:
JM On Mon, 22 Aug 2011 12:47:40 +0200, Manuel Bouyer wrote:
This is slightly more complicated than it appears. Some of the
ops in a per-cpu queue may have ordering dependencies with
other cpu queues, and I
On Mon, Aug 29, 2011 at 03:03:37PM +0200, Cherry G. Mathew wrote:
Hi Manuel,
Manuel == Manuel Bouyer bou...@antioche.eu.org writes:
[...]
Xen's TLB_FLUSH operation is synchronous, and doesn't require an
IPI (within the domain), which makes the queue ordering even
On 29.08.2011 15:03, Cherry G. Mathew wrote:
I'm a bit confused now - are we assuming that the pmap lock protects the
(pte update op queue-push(es) + pmap_pte_flush()) as a single atomic
operation (ie; no invlpg/tlbflush or out-of-band-read can occur between
the update(s) and the
Date:Sun, 28 Aug 2011 08:27:57 +
From:Juergen Hannken-Illjes hann...@netbsd.org
Message-ID: 20110828082757.e02f917...@cvs.netbsd.org
| Should fix PR #42795 (patch to make mounting union filesystems less
obnoxious)
Yes, that fix looks fine, thanks.I'd
[ moving to tech-kern ]
hi,
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
Here is the updated patch after your changes:
http://www.netbsd.org/~rmind/uvm_anon_freelst2.diff
As you noted, uvm_anfree() can temporarily release the amap lock - that
can happen in amap_copy().
[ moved from source-changes-d@ ]
hi,
On Fri, May 27, 2011 at 1:30 AM, David Laight da...@l8s.co.uk wrote:
On Thu, May 26, 2011 at 07:12:57AM +, David Holland wrote:
On Wed, May 25, 2011 at 04:33:38PM +, Masao Uebayashi wrote:
Modified Files:
src/sys/dev/bluetooth: bcsp.c
On Jun 2, 2011, at 11:36 PM, YAMAMOTO Takashi wrote:
sys/device.h has CFDRIVER_DECL, which defines (not declares) a
cfdriver struct. So something like
#ifndef _MODULE
#define CFDRIVER_DECL(x) extern struct cfdriver __CONCAT(x,_cd)
#else
#define CFDRIVER_DECL(x) \
struct cfdriver
On Fri, Jun 3, 2011 at 5:17 PM, Matt Thomas m...@3am-software.com wrote:
On Jun 2, 2011, at 11:36 PM, YAMAMOTO Takashi wrote:
sys/device.h has CFDRIVER_DECL, which defines (not declares) a
cfdriver struct. So something like
#ifndef _MODULE
#define CFDRIVER_DECL(x) extern struct cfdriver
On Fri, Feb 18, 2011 at 5:57 PM, Matt Thomas m...@3am-software.com wrote:
On Feb 17, 2011, at 11:24 PM, Lars Heidieker wrote:
On Thu, Feb 17, 2011 at 8:27 PM, Matt Thomas m...@netbsd.org wrote:
Module Name: src
Committed By: matt
Date: Thu Feb 17 19:27:13 UTC 2011
Modified
On Thu, Feb 17, 2011 at 8:27 PM, Matt Thomas m...@netbsd.org wrote:
Module Name: src
Committed By: matt
Date: Thu Feb 17 19:27:13 UTC 2011
Modified Files:
src/sys/kern: kern_kthread.c
src/sys/uvm: uvm_extern.h uvm_glue.c
Log Message:
Add support for
On Wed, Jan 05, 2011 at 05:58:34AM +, YAMAMOTO Takashi wrote:
hi,
I take silence as no objection.
the silence in this case means was-busy-for-other-things-and-forgot.
sorry.
I have no real code for this big picture at this moment. Making
vm_physseg available as reference is the
hi,
I take silence as no objection.
the silence in this case means was-busy-for-other-things-and-forgot.
sorry.
I have no real code for this big picture at this moment. Making
vm_physseg available as reference is the first step. This only
changes uvm_page_physload() to return a pointer:
Do you have any questions yet?
On Wed, Dec 22, 2010 at 12:52:21PM +0900, Masao Uebayashi wrote:
On Tue, Dec 21, 2010 at 06:33:53PM -0800, Matt Thomas wrote:
On Dec 21, 2010, at 6:13 PM, Masao Uebayashi wrote:
On Tue, Dec 21, 2010 at 11:29:01AM -0800, Matt Thomas wrote:
On Dec
I take silence as no objection.
On Thu, Dec 23, 2010 at 12:48:04PM +0900, Masao Uebayashi wrote:
On Wed, Dec 22, 2010 at 05:37:57AM +, YAMAMOTO Takashi wrote:
hi,
Could you ack this discussion?
sorry for dropping a ball.
On Tue, Dec 07, 2010 at 01:19:46AM +0900, Masao
On Jan 3, 2011, at 9:01 PM, Masao Uebayashi wrote:
I take silence as no objection.
Not so safe.
On Thu, Dec 23, 2010 at 12:48:04PM +0900, Masao Uebayashi wrote:
On Wed, Dec 22, 2010 at 05:37:57AM +, YAMAMOTO Takashi wrote:
hi,
Could you ack this discussion?
sorry for dropping a
On Wed, Dec 22, 2010 at 05:37:57AM +, YAMAMOTO Takashi wrote:
hi,
Could you ack this discussion?
sorry for dropping a ball.
On Tue, Dec 07, 2010 at 01:19:46AM +0900, Masao Uebayashi wrote:
On Thu, Nov 25, 2010 at 11:32:39PM +, YAMAMOTO Takashi wrote:
[ adding cc:
On Tue, Dec 21, 2010 at 11:29:01AM -0800, Matt Thomas wrote:
On Dec 6, 2010, at 8:19 AM, Masao Uebayashi wrote:
On Thu, Nov 25, 2010 at 11:32:39PM +, YAMAMOTO Takashi wrote:
[ adding cc: tech-kern@ ]
The basic idea is straightforward; always allocate vm_physseg for
On Dec 21, 2010, at 6:13 PM, Masao Uebayashi wrote:
On Tue, Dec 21, 2010 at 11:29:01AM -0800, Matt Thomas wrote:
On Dec 6, 2010, at 8:19 AM, Masao Uebayashi wrote:
On Thu, Nov 25, 2010 at 11:32:39PM +, YAMAMOTO Takashi wrote:
[ adding cc: tech-kern@ ]
The basic idea is
On Tue, Dec 21, 2010 at 06:33:53PM -0800, Matt Thomas wrote:
On Dec 21, 2010, at 6:13 PM, Masao Uebayashi wrote:
On Tue, Dec 21, 2010 at 11:29:01AM -0800, Matt Thomas wrote:
On Dec 6, 2010, at 8:19 AM, Masao Uebayashi wrote:
On Thu, Nov 25, 2010 at 11:32:39PM +, YAMAMOTO
On Thu, Nov 25, 2010 at 11:32:39PM +, YAMAMOTO Takashi wrote:
[ adding cc: tech-kern@ ]
hi,
On Wed, Nov 24, 2010 at 11:26:39PM -0800, Matt Thomas wrote:
On Nov 24, 2010, at 10:47 PM, Masao Uebayashi wrote:
On Thu, Nov 25, 2010 at 05:44:21AM +, YAMAMOTO Takashi wrote:
(moving this to tech-kern because it's the right place and per request)
On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote:
Every header file should include the things it requires to compile.
Therefore, there should in principle be no cases where a header file
(or source
Every header file should include the things it requires to compile.
I've long felt this way: that, except for a very few examples like
assert.h that are defined to depend on context, the order of
#includes should not matter. In particular, if multiple files must be
included, any of them may
On Mon, Nov 15, 2010 at 03:47:32PM -0500, der Mouse wrote:
Every header file should include the things it requires to compile.
I've long felt this way: that, except for a very few examples like
assert.h that are defined to depend on context, the order of
#includes should not matter. In
I've long felt this way: that, except for a very few examples like
assert.h that are defined to depend on context, the order of
#includes should not matter. In particular, if multiple files must
be included, any of them may come first - so any file that generates
errors if it's included
On Mon, Nov 15, 2010 at 08:34:40PM +, David Holland wrote:
(moving this to tech-kern because it's the right place and per request)
On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote:
Every header file should include the things it requires to compile.
Therefore, there
On Mon, Nov 15, 2010 at 10:41:55PM +, David Laight wrote:
Indeed. Properly speaking though, headers that are exported to
userland should define only the precise symbols that userland needs;
kernel-only material should be kept elsewhere.
One start would be to add a
On Mon, Nov 15, 2010 at 03:47:32PM -0500, der Mouse wrote:
[...] just forward declarations of the structs.
(this is, btw, one of the reasons to avoid silly typedefs)
I'm not sure what typedefs have to do with it. typedeffing a name to
an incomplete (forward) struct type works just
On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote:
On Sun, Nov 14, 2010 at 05:52:51AM +, David Holland wrote:
On Sun, Nov 14, 2010 at 03:32:44AM +, Masao Uebayashi wrote:
XXX What is the conclusion about direct vs. indirect #include from
headers?
Every header
101 - 200 of 206 matches
Mail list logo
