On Thu, Feb 26, 2009 at 5:10 AM, Tim Kientzle kient...@freebsd.org wrote:
Siddharth Prakash Singh wrote:
I am a student from India. I am willing to contribute to FreeBSD
as a google soc participant this year. I would like to suggest an
idea.
Title: Multicore Aware Process Scheduler.
I have
On Thu, 26 Feb 2009 17:53:48 +0530
Siddharth Prakash Singh sps...@gmail.com wrote:
Do you use FreeBSD? __How long have you used it?
What do you do with it?
No, I haven't really used FreeBSD much. I have been using Linux since long!
Have you read Kirk McKusick's book on FreeBSD internals?
On Wed, 25 Feb 2009, Tim Kientzle wrote:
I have not gone through the process scheduler code of Free BSD. Hence, I am
not yet aware about the current support for Multicore Architectures.
Since you posted to a lot of different lists, I think you probably don't
already use FreeBSD. (If you did,
Robert Watson wrote:
On Wed, 25 Feb 2009, Tim Kientzle wrote:
I have not gone through the process scheduler code of Free BSD.
Hence, I am not yet aware about the current support for Multicore
Architectures.
Since you posted to a lot of different lists, I think you probably
don't already
On Thu, Feb 26, 2009 at 9:19 AM, Tim Kientzle kient...@freebsd.org wrote:
Robert Watson wrote:
On Wed, 25 Feb 2009, Tim Kientzle wrote:
I have not gone through the process scheduler code of Free BSD. Hence, I
am not yet aware about the current support for Multicore Architectures.
Since you
Hello all,
As you may have read some days ago, work has started to make the FreeBSD
base system compile better with clang, the BSD licensed C compiler from
the LLVM project.
One of the reasons why we can't compile the base system yet, is because
some applications in the base system (keyserv,
On 2009-Feb-25 07:53:08 +0100, Ed Schouten e...@80386.nl wrote:
The XFree86 project has been dying ever since almost all the active
development moved to the Xorg-project. Xorg has many new features that
XFree86 doesn't have, like hardware compositing and improved device
detection.
And along the
On Thu, 26 Feb 2009, Ed Schouten wrote:
Hello all,
As you may have read some days ago, work has started to make the FreeBSD
base system compile better with clang, the BSD licensed C compiler from
the LLVM project.
One of the reasons why we can't compile the base system yet, is because
some
* Daniel Eischen deisc...@freebsd.org wrote:
Why don't you add symbol versioning to libmp, so that old
binaries will still work, but new ones will get the new
symbols by default. Hmm, will that work without bumping
SHLIB_MAJOR? You might want to play around with it and
see.
Well, even
On Thu, 26 Feb 2009, Ed Schouten wrote:
* Daniel Eischen deisc...@freebsd.org wrote:
Why don't you add symbol versioning to libmp, so that old
binaries will still work, but new ones will get the new
symbols by default. Hmm, will that work without bumping
SHLIB_MAJOR? You might want to play
* Daniel Eischen deisc...@freebsd.org wrote:
Well, as long as you're in there, maybe you should add
symbol versioning anyway, even after a library version
bump. Seems like it would be easy since there aren't
that many symbols.
I assume I should just mark all symbols with version FBSD_1.1? If
,--- You/Peter (Fri, 27 Feb 2009 05:12:25 +1100) *
| And along the way, they've dropped things like integration testing,
| avoiding regressions and avoiding POLA violations.
Since I don't care about the new X anymore, I can afford to express my
opinion bluntly: the Xorg we have in ports now
On Thu, Feb 26, 2009, Ed Schouten wrote:
One of the reasons why we can't compile the base system yet, is because
some applications in the base system (keyserv, newkey, chkey, libtelnet)
won't compile, because a library they depend (libmp)on has a function
called pow(). By default, LLVM has a
David Schultz schrieb:
On Thu, Feb 26, 2009, Ed Schouten wrote:
One of the reasons why we can't compile the base system yet, is because
some applications in the base system (keyserv, newkey, chkey, libtelnet)
won't compile, because a library they depend (libmp)on has a function
called pow(). By
Christoph Mallon schrieb:
David Schultz schrieb:
On Thu, Feb 26, 2009, Ed Schouten wrote:
One of the reasons why we can't compile the base system yet, is because
some applications in the base system (keyserv, newkey, chkey, libtelnet)
won't compile, because a library they depend (libmp)on has
On Thu, 26 Feb 2009, Ed Schouten wrote:
* Daniel Eischen deisc...@freebsd.org wrote:
Well, as long as you're in there, maybe you should add
symbol versioning anyway, even after a library version
bump. Seems like it would be easy since there aren't
that many symbols.
I assume I should just
On Thu, Feb 26, 2009, Christoph Mallon wrote:
David Schultz schrieb:
On Thu, Feb 26, 2009, Ed Schouten wrote:
One of the reasons why we can't compile the base system yet, is because
some applications in the base system (keyserv, newkey, chkey, libtelnet)
won't compile, because a library they
David Schultz schrieb:
On Thu, Feb 26, 2009, Christoph Mallon wrote:
David Schultz schrieb:
On Thu, Feb 26, 2009, Ed Schouten wrote:
One of the reasons why we can't compile the base system yet, is because
some applications in the base system (keyserv, newkey, chkey, libtelnet)
won't compile,
Hi folks,
In the past few months I've noticed a bug in portupgrade. When I update
my ports tree and do `portupgrade -a', often a few ports will be skipped,
supposedly because another port on which they depend failed to install.
However, the apparently failed port actually did not fail, and
On Thu, Feb 26, 2009, Christoph Mallon wrote:
David Schultz schrieb:
As for gcc's math builtins, most of them are buggy. They fail to
respect the dynamic rounding mode, fail to generate exceptions
where appropriate, fail to respect FENV_ACCESS and other pragmas,
etc. Also, the complex
In the last episode (Feb 26), Nate Eldredge said:
In the past few months I've noticed a bug in portupgrade. When I update
my ports tree and do `portupgrade -a', often a few ports will be skipped,
supposedly because another port on which they depend failed to install.
However, the apparently
David Schultz schrieb:
On Thu, Feb 26, 2009, Christoph Mallon wrote:
David Schultz schrieb:
As for gcc's math builtins, most of them are buggy. They fail to
respect the dynamic rounding mode, fail to generate exceptions
where appropriate, fail to respect FENV_ACCESS and other pragmas,
etc.
22 matches
Mail list logo
