Apparently, On Fri, Feb 22, 2002 at 11:38:07PM -0500,
John Baldwin said words to the effect of;
> I'm currently testing the following patch whcih is a subset of the td_ucred
> changes. It involves no API changes, but only contains 2 basic changes:
>
> 1) We still need Giant when doing t
MIND MEDIA REVIEW No.43
Introductory Edition Edited by Mead Rose
Copy Editor: Will Penna
**
When you think about self-improvement, think Mind Media! To visit our
site, tune your favorite web browser to: http:/
Mike Smith <[EMAIL PROTECTED]> writes:
> I've finally updated the ACPI CA codebase with Intel's 20020214 drop
> (yes, I tagged it 0217, my bad).
...so just retag it. Add the correct tag on top of the incorrect one,
then remove the incorrect tag.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
On Fri, Feb 22, 2002 at 10:25:03PM -0500, John Baldwin wrote:
>
> On 23-Feb-02 Dag-Erling Smorgrav wrote:
> > David Wolfskill <[EMAIL PROTECTED]> writes:
> >> Sounds like a botched (or not run) "mergemaster" execution:
> >
> > No - mergemaster will croak because it runs mtree to build its temp
>
Trying to "make buildworld" for today's -CURRENT, I get:
>>> stage 4: building libraries
--
...
===> doc
cc -fpic -DPIC -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c
/usr/src/lib/libkvm/kvm_file.c -o kvm_file.So
In file included from
Yeah, I'm chasing that one right now.
I'm not yet quite sure which commit has broken this, nor what the right
fix is...
Poul-Henning
In message <[EMAIL PROTECTED]>, David Wolfskill w
rites:
>Trying to "make buildworld" for today's -CURRENT, I get:
>
stage 4: building libraries
>--
On 23-Feb-02 Jake Burkholder wrote:
> Apparently, On Fri, Feb 22, 2002 at 11:38:07PM -0500,
> John Baldwin said words to the effect of;
>
>> I'm currently testing the following patch whcih is a subset of the td_ucred
>> changes. It involves no API changes, but only contains 2 basic change
Ok, found it:
This is the culprit:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/file.h.diff?r1=1.39&r2=1.40
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp writes:
>
>Yeah, I'm chasing that one right now.
>
>I'm not yet quite sure which commit has broken this, nor what the right
>fix i
Thumbs up and big cheers to all of you (well, us) guys working on
-CURRENT. It's pretty stable and has been for a while now - and even
on my poor old 350 MHz K6-2, it performs well enough to make a kickass
desktop & development platform. Let's hope it'll only get better from
here on out :)
DES
On Sat, Feb 23, 2002 at 06:24:39PM +0100, Dag-Erling Smorgrav wrote:
> Thumbs up and big cheers to all of you (well, us) guys working on
> -CURRENT. It's pretty stable and has been for a while now - and even
> on my poor old 350 MHz K6-2, it performs well enough to make a kickass
> desktop & dev
that could change real soon!
On Sat, 23 Feb 2002, Bosko Milekic wrote:
>
> On Sat, Feb 23, 2002 at 06:24:39PM +0100, Dag-Erling Smorgrav wrote:
> > Thumbs up and big cheers to all of you (well, us) guys working on
> > -CURRENT. It's pretty stable and has been for a while now - and even
> > on
On Sat, Feb 23, 2002 at 10:35:44AM -0800, Julian Elischer wrote:
> that could change real soon!
I certainly *hope* not. If you plan to break it, you plan to break it,
but I hope you don't plan to render it unstable. There is a difference
between breaking the build, breaking -CURRENT because of
On Fri, 22 Feb 2002, John Baldwin wrote:
> http://www.FreeBSD.org/~jhb/patches/ucred.patch
>
The following diff removes the capacity to cope with the case when td is
NULL. I presume it is there because it CAN be NULL. (Though I have not
checked further.)
--- //depot/vendor/freebsd/sys/fs/smbf
I forgot the :-)
On Sat, 23 Feb 2002, Bosko Milekic wrote:
>
> On Sat, Feb 23, 2002 at 10:35:44AM -0800, Julian Elischer wrote:
> > that could change real soon!
>
> I certainly *hope* not. If you plan to break it, you plan to break it,
> but I hope you don't plan to render it unstable. There
On Fri, 22 Feb 2002, John Baldwin wrote:
>
> http://www.FreeBSD.org/~jhb/patches/ucred.patch
the structural rewriting in kern_proc.c should be done as a separate
commit. (though I agree it should be done)
the structural rewriting in kern/sysv_*.c
could be done as a separate commit as well.
On 23-Feb-2002 (19:23:17/GMT) Julian Elischer wrote:
> I forgot the :-)
[...]
>> On Sat, Feb 23, 2002 at 10:35:44AM -0800, Julian Elischer wrote:
>> > that could change real soon!
>>
>> I certainly *hope* not. If you plan to break it, you plan to break it,
>> but I hope you don't plan to ren
:Here is the most up-to-date version of pgrp/session lock (at Change 6700):
:
:http://people.FreeBSD.org/~tanimura/patches/pgrp10.diff.gz
:
:I would like to commit this on the next Sunday. Otherwise, my patch
:would conflict with other patches, especially tty.
:
:--
:Seigo Tanimura <[EMAIL PROTE
Riccardo Torrini <[EMAIL PROTECTED]> writes:
> Anyway, any plan to fix build breakage?
Sure:
Index: file.h
===
RCS file: /home/ncvs/src/sys/sys/file.h,v
retrieving revision 1.40
diff -u -r1.40 file.h
--- file.h 23 Feb 2002 11:1
* Matthew Dillon <[EMAIL PROTECTED]> [020223 12:51] wrote:
>
> :Here is the most up-to-date version of pgrp/session lock (at Change 6700):
> :
> :http://people.FreeBSD.org/~tanimura/patches/pgrp10.diff.gz
> :
> :I would like to commit this on the next Sunday. Otherwise, my patch
> :would conflict
In the past week, a number of comments have been made both for and against
additional version control mechanisms being used to supplement the FreeBSD
Project official CVS server. Proponents of additional mechanisms, such as
Perforce, have pointed out that CVS doesn't provide the necessary tools
On 23-Feb-2002 (21:12:12/GMT) Dag-Erling Smorgrav wrote:
> Riccardo Torrini <[EMAIL PROTECTED]> writes:
>> Anyway, any plan to fix build breakage?
> Sure:
[...]
This works. Thanks.
>> I really need build to (try to?) locate missing /dev/speaker :(
># kldload atspeaker
This doesn't work.
In message <[EMAIL PROTECTED]>, Robe
rt Watson writes:
>Question 1: How should the presence of on-going work in an external
>repository be announced to the broader community?
On the project.freebsd.org web-page and the regular status emails
generated from the contents of that web-page.
>Questio
Alfred Perlstein wrote:
> All these per-subsystem free-lists are making me nervous in both
> complexity and wasted code...
Me too.
> Ok, instead of keeping all these per-subsystem free-lists here's what
> we do:
>
> In kern_malloc:free() right at the point of
> if (size > MAXALLOCSAVE) we che
Riccardo Torrini <[EMAIL PROTECTED]> writes:
> On 23-Feb-2002 (21:12:12/GMT) Dag-Erling Smorgrav wrote:
> > # kldload atspeaker
> This doesn't work. I'm missing something obvious?
Not that I can see... works for me
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [E
:All these per-subsystem free-lists are making me nervous in both
:complexity and wasted code...
:
:Ok, instead of keeping all these per-subsystem free-lists here's what
:we do:
:
:In kern_malloc:free() right at the point of
: if (size > MAXALLOCSAVE) we check if we have Giant or not.
:if we
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> des 2002/02/23 13:14:43 PST
>
> Modified files:
> sys/sys file.h
> Log:
> Fix namespace pollution introduced in previous commit.
>
> Revision ChangesPath
> 1.41 +1 -4 src/sys/sys/file.h
>
Thi
This is approximately what I am thinking. Note that this gives us the
flexibility to create a larger infrastructure around the bucket cache,
such as implement per-cpu caches and so on and so forth. What I have
here is the minimal implementation.
Matthew Dillon wrote:
> This is approximately what I am thinking. Note that this gives us the
> flexibility to create a larger infrastructure around the bucket cache,
> such as implement per-cpu caches and so on and so forth. What I have
> here is the minimal implementation.
Uh,
:OTOH, A per CPU bucket list means no bucket mtx would be necessary;
:without that, it's just replacing one type of contention for another,
:I think, until you start making mutex selection indeterminate. 8^(.
:
:Really, this delayed freeing idea is starting to get uglier than
:just going to per
Apparently, On Sat, Feb 23, 2002 at 02:43:35PM -0800,
Matthew Dillon said words to the effect of;
> This is approximately what I am thinking. Note that this gives us the
> flexibility to create a larger infrastructure around the bucket cache,
> such as implement per-cpu cache
On Sat, 23 Feb 2002, Matthew Dillon wrote:
> critical_enter() isn't much better then a mutex. It can
> be optimized to get rid of the inline cli & sti however. Actually, it
> can be optimized trivially for i386, all we have to do is check the
> critical nesting count from the in
:My version of it does less than this. I only use it to help implement
:spinlocks.
You put together infrastructure to deal with pending pci interrupts?
If so, then why not commit it (or at least commit a version #ifdef'd
for the i386 architecture).
Tone your Abs, Thighs, Arms, and more with NO EFFORT !
Don't have time to workout? Tired of all those products that have you get down on
the floor? Tired of backaches caused by sit-ups!? NO MORE... READ ON!
*TRIM AND TONE YOUR TUMMY IN TIME FOR THE SUMMER!
*WORKOUT WHILE WATCHING TV, AT THE
>Date: Fri, 22 Feb 2002 21:56:47 -0800
>From: Mike Smith <[EMAIL PROTECTED]>
>I've finally updated the ACPI CA codebase with Intel's 20020214 drop
Yay...!
>There aren't many changes in the FreeBSD-specific code, this is just
>catching up with major improvements in the interpreter.
>As usual, p
* Matthew Dillon <[EMAIL PROTECTED]> [020223 14:43] wrote:
> This is approximately what I am thinking. Note that this gives us the
> flexibility to create a larger infrastructure around the bucket cache,
> such as implement per-cpu caches and so on and so forth. What I have
> her
:
:* Matthew Dillon <[EMAIL PROTECTED]> [020223 14:43] wrote:
:> This is approximately what I am thinking. Note that this gives us the
:> flexibility to create a larger infrastructure around the bucket cache,
:> such as implement per-cpu caches and so on and so forth. What I have
:>
* Matthew Dillon <[EMAIL PROTECTED]> [020223 16:41] wrote:
>
> :
> :* Matthew Dillon <[EMAIL PROTECTED]> [020223 14:43] wrote:
> :> This is approximately what I am thinking. Note that this gives us the
> :> flexibility to create a larger infrastructure around the bucket cache,
> :> s
On Sat, 23 Feb 2002, Matthew Dillon wrote:
> :My version of it does less than this. I only use it to help implement
> :spinlocks.
>
> You put together infrastructure to deal with pending pci interrupts?
> If so, then why not commit it (or at least commit a version #ifdef'd
> for the
Bruce, I've looked at the vector assembly and it looks like cleaning
up critical_enter() and critical_exit() for i386 ought to be simple.
If you have a complete patch set I would like to see it posted for
review or comitted, or if you don't want to deal with the commit I
woul
:
:On Sat, 23 Feb 2002, Matthew Dillon wrote:
:
:> :My version of it does less than this. I only use it to help implement
:> :spinlocks.
:>
:> You put together infrastructure to deal with pending pci interrupts?
:> If so, then why not commit it (or at least commit a version #ifdef'd
:>
:It's too messy and unfinished (doesn't work right for SMP or irqs >= 16),
:and dificult to untangle from my other patches. I posted these partial
:ones to attempt to inhibit() recomplication of the current critical*
:functions in directions that I don't want to go :-).
:...
:
:ipending here work
On Sat, 23 Feb 2002, Matthew Dillon wrote:
> Bruce, I've looked at the vector assembly and it looks like cleaning
> up critical_enter() and critical_exit() for i386 ought to be simple.
>
> If you have a complete patch set I would like to see it posted for
> review or comitted, or
On Sat, 23 Feb 2002, Matthew Dillon wrote:
> :It's too messy and unfinished (doesn't work right for SMP or irqs >= 16),
> :and dificult to untangle from my other patches. I posted these partial
> :ones to attempt to inhibit() recomplication of the current critical*
> :functions in directions tha
:
:On Sat, 23 Feb 2002, Matthew Dillon wrote:
:
:> :It's too messy and unfinished (doesn't work right for SMP or irqs >= 16),
:> :and dificult to untangle from my other patches. I posted these partial
:> :ones to attempt to inhibit() recomplication of the current critical*
:> :functions in direc
On Sat, 23 Feb 2002, Matthew Dillon wrote:
> :ipending here works much as in RELENG_4. It is ORed into by sched_ithd()
> :if curthread->td_critnest != 0. Nothing special is needed for pci
> :(the ICU masks pending interrupts).
> :
> :Bruce
>
> Ok, I have most of it coded up. Could you expl
:> :(the ICU masks pending interrupts).
:> :
:> :Bruce
:>
:> Ok, I have most of it coded up. Could you explain what 'spending'
:> was for?
:
:Like the SWI bits in ipending in RELENG_4. In RELENG_4, we have to pass
:around all the bits to spl*(), so we had to pack them in at least some
:
At 6:24 PM +0100 2/23/02, Dag-Erling Smorgrav wrote:
>Thumbs up and big cheers to all of you (well, us) guys working on
>-CURRENT. It's pretty stable and has been for a while now - and
>even on my poor old 350 MHz K6-2, it performs well enough to make
>a kickass desktop & development platform. L
So how do I add NewCard project to this TWiki?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
> So how do I add NewCard project to this TWiki?
>
Go into the CurrentProjects area and edit the page.
Add a WikiWord that's something like NewCard. You'll see that
when you're done editing the new word shows up as an incomplete
link (It has a ? at the end). Click on the ? and then you get a
Would you mind changing the description of the twiki to something else
than "where all FreeBSD collaboration happens"? It might give people
the wrong impression.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in
> Would you mind changing the description of the twiki to something else
> than "where all FreeBSD collaboration happens"? It might give people
> the wrong impression.
Sure. Suggestions? I don't mind what people put into this, that's much of
the point.
It's just a place holder. Remember, any
"George V. Neville-Neil" <[EMAIL PROTECTED]> writes:
> Anyways, what would people like?
"Information and discussions about various FreeBSD subprojects"?
BTW, why don't you want a FreeBSD WikiTerm?
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
wi
> "Information and discussions about various FreeBSD subprojects"?
Sounds good. Check that in there.
> BTW, why don't you want a FreeBSD WikiTerm?
>
Well it's a bit odd. Anywhere you put the word FreeBSD lights up as a link.
I guess we could put a generic page under it or something but it's
"George V. Neville-Neil" <[EMAIL PROTECTED]> writes:
> > BTW, why don't you want a FreeBSD WikiTerm?
> Well it's a bit odd. Anywhere you put the word FreeBSD lights up as a link.
> I guess we could put a generic page under it or something but it's
> annoying (to me at least) to see FreeBSD as a l
Dag-Erling Smorgrav wrote:
>
> David Wolfskill <[EMAIL PROTECTED]> writes:
> > Sounds like a botched (or not run) "mergemaster" execution:
>
> No - mergemaster will croak because it runs mtree to build its temp
> directory, so if you're trying to update a pre-smmsp system you have
> to add the s
On Sat, Feb 23, 2002 at 03:12:36PM -0800, Matthew Dillon wrote:
>
> :OTOH, A per CPU bucket list means no bucket mtx would be necessary;
> :without that, it's just replacing one type of contention for another,
> :I think, until you start making mutex selection indeterminate. 8^(.
> :
> :Really,
56 matches
Mail list logo
