Garrett Cooper wrote:
Hi,
While trying to determine how to print out routes via kvm for
net-snmp, I noticed that there's a chunk of code from the 4.4 BSD Lite
days that isn't executed in netstat as NewTree is always 0. The
following patch removes that dead code and gets the FreeBSD source
On Mon, Jul 11, 2011 at 11:16 PM, Alexander V. Chernikov
melif...@ipfw.ru wrote:
Garrett Cooper wrote:
Hi,
While trying to determine how to print out routes via kvm for
net-snmp, I noticed that there's a chunk of code from the 4.4 BSD Lite
days that isn't executed in netstat as NewTree is
Seems this interface be acceptable ?
Looks good to me.
The proposed code changes are in the attached patch.
Proposed wording of addition into RFORK(2):
DESCRIPTION:
RFTSIGZMB If set, the kernel will return selected signal number instead
of SIGCHILD upon thread exit
On Tue, Jul 12, 2011 at 11:16:28AM +0200, Petr Salinger wrote:
Seems this interface be acceptable ?
Looks good to me.
The proposed code changes are in the attached patch.
Proposed wording of addition into RFORK(2):
Below is the patch I intend to commit after you retest it.
I added the
No it cannot be r222802.
Actually, I found a bug fixed in r222802 about a month ago
(kern/157657) and I've patched source code
of my FreeBSD-8.2 (this is the only difference between my tree and
stock FreeBSD-8.2).
I thought that build with KERNFAST=1 could be a problem, but I've done
clean build
On 12.07.2011 11:10, Garrett Cooper wrote:
On Mon, Jul 11, 2011 at 11:16 PM, Alexander V. Chernikov
melif...@ipfw.ru wrote:
Garrett Cooper wrote:
Hi,
While trying to determine how to print out routes via kvm for
net-snmp, I noticed that there's a chunk of code from the 4.4 BSD Lite
days
Below is the patch I intend to commit after you retest it.
I applied it against our 8.2 based package,
altered our clone to use this new
interface and run eglibc testsuite. No regression.
Our runtime detection of this new interface will be based
on sysctl kern.osreldate.
some rewording to
When building kernel code on a non-FreeBSD system, kernel source still
expects pre-processor macros to be those of a FreeBSD system. If
__linux__ is defined, build will break. If __FreeBSD__ isn't defined,
build will break too.
This small patch fakes the pre-processor macros of FreeBSD so that
2011/7/12 Oliver Pinter oliver.p...@gmail.com:
+.if ${OPSYS} != FreeBSD
and what's the status example on NetBSD?
I didn't think of it. There are some instances of __NetBSD__ and also
__OpenBSD__ in the kernel tree, and the same problem can be fixed for
these two systems with minimal effort.
On Tue, 12 Jul 2011 22:00:56 +0200
Robert Millan r...@debian.org wrote:
2011/7/12 Oliver Pinter oliver.p...@gmail.com:
+.if ${OPSYS} != FreeBSD
and what's the status example on NetBSD?
I didn't think of it. There are some instances of __NetBSD__ and also
__OpenBSD__ in the kernel
On Tue, Jul 12, 2011 at 04:36:24PM +0200, Petr Salinger wrote:
Below is the patch I intend to commit after you retest it.
I applied it against our 8.2 based package,
altered our clone to use this new
interface and run eglibc testsuite. No regression.
Our runtime detection of this new
2011/7/12 Alexander Kabaev kab...@gmail.com:
Whatever happened to using a proper cross-tool to do the job?
Why would one need to build a cross-compiler in order to compile
userland-agnostic code for the same CPU architecture? This would be
like requiring a cross-compiler in order to build
2011/7/12 Kostik Belousov kostik...@gmail.com:
I just committed this to HEAD. Will MFC in a week, unless some problems
arise.
Thanks!
I will bump revision for stable/8 when merging, but I do not see much
reason to bump on HEAD right now.
Uhm I think we can survive without a bump in HEAD.
On Tue, 12 Jul 2011 23:06:12 +0200
Robert Millan r...@debian.org wrote:
2011/7/12 Alexander Kabaev kab...@gmail.com:
Whatever happened to using a proper cross-tool to do the job?
Why would one need to build a cross-compiler in order to compile
userland-agnostic code for the same CPU
I will bump revision for stable/8 when merging, but I do not see much
reason to bump on HEAD right now.
Many thanks.
Uhm I think we can survive without a bump in HEAD. For now we will
need to keep our backward-compatibility patch anyway, and when the
bump happens on stable/8 our sysctl
On Tue, Jul 12, 2011 at 11:53:05PM +0200, Petr Salinger wrote:
I will bump revision for stable/8 when merging, but I do not see much
reason to bump on HEAD right now.
Many thanks.
Uhm I think we can survive without a bump in HEAD. For now we will
need to keep our backward-compatibility
2011/7/12 Alexander Kabaev kab...@gmail.com:
The fact that Linux compiler with manually undefined and re-defined
platform macros can compile is a coincidence and is not guaranteed to
work and certainly is not a goal of FreeBSD project so this can be
broken at any moment.
There must be some
On 7/12/11, Robert Millan r...@debian.org wrote:
2011/7/12 Oliver Pinter oliver.p...@gmail.com:
+.if ${OPSYS} != FreeBSD
and what's the status example on NetBSD?
I didn't think of it. There are some instances of __NetBSD__ and also
__OpenBSD__ in the kernel tree, and the same problem can
On 07/12/11 16:06, Robert Millan wrote:
2011/7/12 Alexander Kabaevkab...@gmail.com:
Whatever happened to using a proper cross-tool to do the job?
Why would one need to build a cross-compiler in order to compile
userland-agnostic code for the same CPU architecture? This would be
like requiring
Hello,
My machine somehow fails to boot into FreeBSD (off the cd, since it
fails to boot, I can't install it in the first place). It goes through
and ends up stopping deadlock style. No printouts of errors (besides a
ppc problem, which is not fatal) and no crash/oops/panic. It just...
stops
2011/7/12 Nathan Whitehorn nwhiteh...@freebsd.org:
On 07/12/11 16:06, Robert Millan wrote:
Why would one need to build a cross-compiler in order to compile
userland-agnostic code for the same CPU architecture? This would be
like requiring a cross-compiler in order to build things like GRUB or
On 07/12/11 17:33, Robert Millan wrote:
2011/7/12 Nathan Whitehornnwhiteh...@freebsd.org:
On 07/12/11 16:06, Robert Millan wrote:
Why would one need to build a cross-compiler in order to compile
userland-agnostic code for the same CPU architecture? This would be
like requiring a
On Tue, 12 Jul 2011 23:59:05 +0200
Robert Millan r...@debian.org wrote:
2011/7/12 Alexander Kabaev kab...@gmail.com:
The fact that Linux compiler with manually undefined and re-defined
platform macros can compile is a coincidence and is not guaranteed
to work and certainly is not a goal of
23 matches
Mail list logo
