On Thursday, March 13, 2014 6:46:13 pm Bruno Lauzé wrote:
> I suggesting this because it is used more ahead in the same file, but the
> other way around is fine for me
No need to move them around:
Index: vm_map.h
===
--- vm
I suggesting this because it is used more ahead in the same file, but the other
way around is fine for me
> From: j...@freebsd.org
> To: freebsd-current@freebsd.org
> Subject: Re: vm_map.h
> Date: Thu, 13 Mar 2014 14:00:59 -0400
> CC: bru
On Wednesday, March 12, 2014 5:13:28 pm Bruno Lauzé wrote:
> The two defines in vm/vm_map.h
>
> #define min_offset header.start/* (c) */
> #define max_offset header.end /* (c) */
>
>
> are really getting in the way because those words are most likely to be use
The two defines in vm/vm_map.h
#define min_offset header.start /* (c) */
#define max_offset header.end /* (c) */
are really getting in the way because those words are most likely to be used
downstream.
I would suggest renaming those defines to:
#define vm_min_offset
Thus spake Garrett Wollman <[EMAIL PROTECTED]>:
> < said:
>
> > A real problem is that a swapped out process' uarea has to be
> > paged back in, even when no memory is available. I don't think
> > there's an easy way around that, given that you need the uarea and
> > kernel stack to handle the si
< said:
> A real problem is that a swapped out process' uarea has to be
> paged back in, even when no memory is available. I don't think
> there's an easy way around that, given that you need the uarea and
> kernel stack to handle the signal.
But you don't, actually -- at least not to ``handle''
Matthew Dillon <[EMAIL PROTECTED]> wrote:
>
> :
> :Hi,
> :
> :Sorry to unwantedly butt in, but the patch supplied by Seigo actually
> :solved the vm_map.c locking problems which used to come up on my system.
> :Just some info. :)
> :
> :Regards,
> :
> : -- Hiten Pandya
> : -- <[EMAIL PROTECTED]
:Hmm. Ok, so right now the code that has been branched for DP1 makes use
:of Brian's recent locking commits. My original thought was we'd simply
:back it out of that branch to make sure that the DP is reliable. How hard
:would it be for us to switch to what you propose (just convert all slocks
On Sun, 17 Mar 2002, Matthew Dillon wrote:
> It fixed some things, it broke some things. Pretty much standard
> fare for anyone who has ever done work on the vm_map lock, including
> yours truely. John Dyson couldn't get it right, David Greenman couldn't
> get it right, I could
:
:Hi,
:
:Sorry to unwantedly butt in, but the patch supplied by Seigo actually
:solved the vm_map.c locking problems which used to come up on my system.
:Just some info. :)
:
:Regards,
:
: -- Hiten Pandya
: -- <[EMAIL PROTECTED]>
It fixed some things, it broke some things. Pretty much st
Hi,
Sorry to unwantedly butt in, but the patch supplied by Seigo actually
solved the vm_map.c locking problems which used to come up on my system.
Just some info. :)
Regards,
-- Hiten Pandya
-- <[EMAIL PROTECTED]>
--- Matthew Dillon <[EMAIL PROTECTED]> wrote:
> I have no idea what the
I have no idea what the frig you guys are doing in vm_map.c. I would
recommend that all the changes be backed out. Then I would recommend
that the following be done:
* change the lockmgr vm_map lock to be exclusive-only
* test & commit
* change the lockmgr vm
On Sat, 16 Mar 2002 19:08:53 +0900,
Seigo Tanimura <[EMAIL PROTECTED]> said:
Seigo> Attached patch implements sx_upgrade() which should work as you said
Seigo> above. This compiles fine, but is not tested yet.
The last patch breaks INVARIANTS. This one compiles and seems to work.
sx_upgrad
[Add jhb and move to -current]
On Fri, 15 Mar 2002 10:53:20 -0800,
Alfred Perlstein <[EMAIL PROTECTED]> said:
Alfred> * Brian F. Feldman <[EMAIL PROTECTED]> [020315 03:22] wrote:
>> Alfred Perlstein <[EMAIL PROTECTED]> wrote:
>> >
>> > What is the problem?
>>
>> Damn good question. Are the
14 matches
Mail list logo
