Re: Cross compilling kernel i386/amd64 is failed
On 16 Apr 2010, at 10:29, Andriy Gapon wrote: on 16/04/2010 04:19 Arseny Nasokin said the following: On 16 Apr 2010, at 03:03, Andriy Gapon wrote: on 16/04/2010 01:27 Arseny Nasokin said the following: I get error in same point when I try compile amd64 current GENERIC on i386 machine. Svn revision is 206597 Error at src/sys/amd64/amd64/genassym.c:1: code model 'kernel' not supported in the 32 bit mode. how to cross compile it? PS: I build only kernel at this point. Should I rebuild whole world to build kernel? kernel-toolchain See build(7) Thanks, I'll create bug with patch Please don't create any new bugs, bug reports are welcome though :-) Yeah, you're right, sorry. BTW, what do you want to report? kernel-toolchain target must be called on cross-compilling, even you making cross-world (where toolchain is called) -- Andriy Gapon -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cross compilling kernel i386/amd64 is failed
on 16/04/2010 10:38 Arseny Nasokin said the following: > > kernel-toolchain target must be called on cross-compilling, even you > making cross-world (where toolchain is called) Still not sure what is the problem. Before cross-compiling a kernel you have to cross-build either the corresponding world or the kernel toolchain. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
Quoting Navdeep Parhar (from Wed, 14 Apr 2010
11:35:40 -0700):
Have you or anyone else ever used buildkernel successfully with
"makeoptions WITH_CTF=yes" in the conf file? Something as simple as
this does not work for me:
Copy&paste patch, tabs probbly mangled:
---snip---
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 206700)
+++ Makefile.inc1 (working copy)
@@ -314,7 +314,7 @@
.endif
# kernel stage
-KMAKEENV= ${WMAKEENV}
+KMAKEENV= ${WMAKEENV:NNO_CTF=1}
KMAKE= ${KMAKEENV} ${MAKE} KERNEL=${INSTKERNNAME}
#
@@ -780,7 +780,7 @@
@echo "--"
cd ${KRNLOBJDIR}/${_kernel}; \
MAKESRCPATH=${KERNSRCDIR}/dev/aic7xxx/aicasm \
- ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF \
+ ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS \
-f ${KERNSRCDIR}/dev/aic7xxx/aicasm/Makefile
# XXX - Gratuitously builds aicasm in the ``makeoptions NO_MODULES'' case.
.if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) &&
exists(${KERNSRCDIR}/modules)
---snip---
This lets the buildkernel generate ctf info in the object files (the
build is not finished yet, so I still have to verify that the final
kernel contains them too, but I do not see a reason ATM why this
should not be the case).
If your build environment is faster (here: about an hour for the
buildkernel), can you please help testing? A buildworld with and
without WITH_CTF in src.conf, and for buildkernel the same (with and
without WITH_CTF in src.conf, and for each with and without
makeoptions WITH_CTF=yes in the kernel). The expected outcome is no
CTF when no WITH_CTF is in src.conf (except for the buildkernel with
the makeoptions), and always with CTF when WITH_CTF is in src.conf
(alternatively only CTF if makeoptions is used, but this would be
surprising for me).
And then... NO_CTF=yes defined in src.conf and WITH_CTF too... for the
world this should not produce CTF data, but for the kernel I'm not
sure what will or should happen for the makeoptions case...
Bye,
Alexander.
--
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
See, these two penguins walked into a bar, which was really stupid, 'cause
the second one should have seen it.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[CFT]: ClangBSD is selfhosting, we need testers now
Hi, ClangBSD is a branch of FreeBSD that aims at integrating clang (clang.llvm.org) into FreeBSD, replacing GCC as a system compiler. Recently, we've achieved the state when clang can compile all of FreeBSD world on i386/amd64 platforms (including all the C++ apps we have and itself) and a bootable kernel. Thus we feel that the time has come to ask the FreeBSD community for wider testing on i386/amd64 (you sure can help with other platforms too :)). How to setup ClangBSD: The default configuration of ClangBSD requires clang installed so you can either install fresh llvm-devel port (portinstall devel/llvm-devel) or change CC to "gcc" and CXX to "g++" in share/mk/sys.mk. I recommend the former. svn co http://svn.freebsd.org/base/projects/clangbsd/ clangbsd cd clangbsd && make buildworld echo NO_WERROR= >> /etc/make.conf echo WERROR=>> /etc/make.conf make DESTDIR=/clangbsd-chroot/ installworld now you have ClangBSD world installed and you can chroot into it. I don't recommend installing ClangBSD into real root as it is not tested enough. You can also start using clang compiled kernel - either build the kernel in the ClangBSD chroot (set NO_WERROR=yo and WERROR=yo in /etc/src.conf) or set CC to clang and build kernel the normal way. This information (and more) is also provided on: http://wiki.freebsd.org/BuildingFreeBSDWithClang We kindly ask you to setup ClangBSD chroot and/or use clang compiled kernel and use it as you would normally use FreeBSD. Please report back Thank you, Roman Divacky on behalf of the ClangBSD team pgpez6WiCHP8k.pgp Description: PGP signature
Re: [CFT]: ClangBSD is selfhosting, we need testers now
On Fri, Apr 16, 2010 at 9:08 AM, Roman Divacky wrote: > Hi, > > ClangBSD is a branch of FreeBSD that aims at integrating clang > (clang.llvm.org) > into FreeBSD, replacing GCC as a system compiler. > > Recently, we've achieved the state when clang can compile all of FreeBSD world > on i386/amd64 platforms (including all the C++ apps we have and itself) > and a bootable kernel. Thus we feel that the time has come to ask the FreeBSD > community for wider testing on i386/amd64 (you sure can help with other > platforms too :)). Good job, and thank you! Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
> Recently, we've achieved the state when clang can compile all of FreeBSD world > on i386/amd64 platforms (including all the C++ apps we have and itself) > and a bootable kernel. Thus we feel that the time has come to ask the FreeBSD > community for wider testing on i386/amd64 (you sure can help with other > platforms too :)). This is great news, compiling right now! Thank you! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HP, IBM and Supermicro Servers Compatibility.
Miroslav Lachman wrote: Juanito Cassemiro wrote: Hi. I want to know if the IBM, HP or Supermicro Servers are compatible with FreeBSD OS. Could you send me a hardware compatibility list with compatible servers? It depends on server model, not on manufacturer in general. I have some IBM, HP, Supermicro and Sun servers in production. But it does not mean all IBM / HP / SM servers will work. I'd agree but would also add that "most will work ok" - especially from the eariler Xeon 5000/5100/5200/5300/5400 series. These systems have hardware which is well tested and developed through the years - it would be an anomaly to find a configuration that doesn't work. I have systems with all of the above CPUs on versions of FreeBSD from 6.x to 8.x, with all of the above vendors (well, not all CPU+Vendor combinations :) ) and not a single unsolvable problem. I had the most problems with blade servers. I'm writing this on a 2x 54xx system from SuperMicro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
On Fri, Apr 16, 2010 at 12:08 PM, Roman Divacky wrote: > Hi, > > ClangBSD is a branch of FreeBSD that aims at integrating clang ( > clang.llvm.org) > into FreeBSD, replacing GCC as a system compiler. > > Recently, we've achieved the state when clang can compile all of FreeBSD > world > on i386/amd64 platforms (including all the C++ apps we have and itself) > and a bootable kernel. Thus we feel that the time has come to ask the > FreeBSD > community for wider testing on i386/amd64 (you sure can help with other > platforms too :)). > > How to setup ClangBSD: > > The default configuration of ClangBSD requires clang installed so you can > either install fresh llvm-devel port (portinstall devel/llvm-devel) or > change > CC to "gcc" and CXX to "g++" in share/mk/sys.mk. I recommend the former. > > >svn co http://svn.freebsd.org/base/projects/clangbsd/ clangbsd > >cd clangbsd && make buildworld > >echo NO_WERROR= >> /etc/make.conf >echo WERROR=>> /etc/make.conf > >make DESTDIR=/clangbsd-chroot/ installworld > > > now you have ClangBSD world installed and you can chroot into it. I don't > recommend installing ClangBSD into real root as it is not tested enough. > > You can also start using clang compiled kernel - either build the kernel in > the ClangBSD chroot (set NO_WERROR=yo and WERROR=yo in /etc/src.conf) or > set > CC to clang and build kernel the normal way. > > This information (and more) is also provided on: > >http://wiki.freebsd.org/BuildingFreeBSDWithClang > > We kindly ask you to setup ClangBSD chroot and/or use clang compiled kernel > and > use it as you would normally use FreeBSD. Please report back > > Thank you, > > Roman Divacky on behalf of the ClangBSD team > can someone explain the benefit other then not relying on gcc now ? performance ? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
Hi-- On Apr 16, 2010, at 1:53 PM, Outback Dingo wrote: > can someone explain the benefit other then not relying on gcc now ? > performance ? http://clang.llvm.org/comparison.html http://clang-analyzer.llvm.org/ Regards, -- -Chuck ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
Roman Divacky wrote: We kindly ask you to setup ClangBSD chroot and/or use clang compiled kernel and use it as you would normally use FreeBSD. Please report back I have a buildworld error here: clang -isystem /usr/obj/mt/clangbsd/tmp/usr/include/clang/1.5 -isystem /usr/obj/mt/clangbsd/tmp/usr/include -B/usr/obj/mt/clangbsd/tmp/usr/lib/ -L/usr/obj/mt/clangbsd/tmp/usr/lib/ -fpic -DPIC -O2 -pipe -mtune=generic -I/mt/clangbsd/lib/libc/include -I/mt/clangbsd/lib/libc/../../include -I/mt/clangbsd/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/mt/clangbsd/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/mt/clangbsd/lib/libc -I/mt/clangbsd/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/mt/clangbsd/lib/libc/../../contrib/tzcode/stdtime -I/mt/clangbsd/lib/libc/stdtime -I/mt/clangbsd/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/mt/clangbsd/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /mt/clangbsd/lib/libc/sys/__error.c -o __error.So /mt/clangbsd/lib/libc/sys/stack_protector.c:88:19: error: format string is not a string literal (potentially insecure) [-Wformat-security] syslog(LOG_CRIT, msg); ^~~ 1 diagnostic generated. *** Error code 1 /mt/clangbsd/lib/libc/sys/stack_protector.c:88:19: error: format string is not a string literal (potentially insecure) [-Wformat-security] syslog(LOG_CRIT, msg); ^~~ 1 diagnostic generated. *** Error code 1 2 errors *** Error code 2 1 error The context is... I think a bit overprotective here :) At least this particular warning knob should probably be turned off. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
Ivan Voras wrote: Roman Divacky wrote: We kindly ask you to setup ClangBSD chroot and/or use clang compiled kernel and use it as you would normally use FreeBSD. Please report back I have a buildworld error here: clang -isystem /usr/obj/mt/clangbsd/tmp/usr/include/clang/1.5 -isystem /usr/obj/mt/clangbsd/tmp/usr/include -B/usr/obj/mt/clangbsd/tmp/usr/lib/ -L/usr/obj/mt/clangbsd/tmp/usr/lib/ -fpic -DPIC -O2 -pipe -mtune=generic -I/mt/clangbsd/lib/libc/include -I/mt/clangbsd/lib/libc/../../include -I/mt/clangbsd/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/mt/clangbsd/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/mt/clangbsd/lib/libc -I/mt/clangbsd/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/mt/clangbsd/lib/libc/../../contrib/tzcode/stdtime -I/mt/clangbsd/lib/libc/stdtime -I/mt/clangbsd/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/mt/clangbsd/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /mt/clangbsd/lib/libc/sys/__error.c -o __error.So /mt/clangbsd/lib/libc/sys/stack_protector.c:88:19: error: format string is not a string literal (potentially insecure) [-Wformat-security] syslog(LOG_CRIT, msg); ^~~ 1 diagnostic generated. *** Error code 1 /mt/clangbsd/lib/libc/sys/stack_protector.c:88:19: error: format string is not a string literal (potentially insecure) [-Wformat-security] syslog(LOG_CRIT, msg); ^~~ 1 diagnostic generated. *** Error code 1 2 errors *** Error code 2 1 error Actually the above error message was garbled by -j#, here's a more informative one: ===> lib/libc (obj,depend,all,install) clang -isystem /usr/obj/mt/clangbsd/tmp/usr/include/clang/1.5 -isystem /usr/obj/mt/clangbsd/tmp/usr/include -B/usr/obj/mt/clangbsd/tmp/usr/lib/ -L/usr/obj/mt/clangbsd/tmp/usr/lib/ -O2 -pipe -mtune=generic -I/mt/clangbsd/lib/libc/include -I/mt/clangbsd/lib/libc/../../include -I/mt/clangbsd/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/mt/clangbsd/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/mt/clangbsd/lib/libc -I/mt/clangbsd/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/mt/clangbsd/lib/libc/../../contrib/tzcode/stdtime -I/mt/clangbsd/lib/libc/stdtime -I/mt/clangbsd/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/mt/clangbsd/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /mt/clangbsd/lib/libc/sys/stack_protector.c /mt/clangbsd/lib/libc/sys/stack_protector.c:88:19: error: format string is not a string literal (potentially insecure) [-Wformat-security] syslog(LOG_CRIT, msg); ^~~ 1 diagnostic generated. *** Error code 1 Stop in /mt/clangbsd/lib/libc. *** Error code 1 It looks like one of the first steps in building libc. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
On Sat, Apr 17, 2010 at 12:21:29AM +0200, Ivan Voras wrote: > > /mt/clangbsd/lib/libc/sys/stack_protector.c:88:19: error: format string > > is not a string literal (potentially insecure) [-Wformat-security] > > syslog(LOG_CRIT, msg); > > ^~~ > > 1 diagnostic generated. > > *** Error code 1 > > 2 errors > > *** Error code 2 > > 1 error > > Actually the above error message was garbled by -j#, here's a more > informative one: Maybe this is why you have to place NO_WERROR and WERROR into make.conf before building? Regards, -- Rink P.W. Springer- http://rink.nu "Beauty often seduces us on the road to truth." - Dr. Wilson ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
Rink Springer wrote: On Sat, Apr 17, 2010 at 12:21:29AM +0200, Ivan Voras wrote: /mt/clangbsd/lib/libc/sys/stack_protector.c:88:19: error: format string is not a string literal (potentially insecure) [-Wformat-security] syslog(LOG_CRIT, msg); ^~~ 1 diagnostic generated. *** Error code 1 2 errors *** Error code 2 1 error Actually the above error message was garbled by -j#, here's a more informative one: Maybe this is why you have to place NO_WERROR and WERROR into make.conf before building? Ahh yes, I thought something was nagging me about the order of setting make.conf vars and buildworld in Roman's message :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]: ClangBSD is selfhosting, we need testers now
On Fri, Apr 16, 2010 at 3:45 PM, Ivan Voras wrote: > Rink Springer wrote: >> >> On Sat, Apr 17, 2010 at 12:21:29AM +0200, Ivan Voras wrote: /mt/clangbsd/lib/libc/sys/stack_protector.c:88:19: error: format string is not a string literal (potentially insecure) [-Wformat-security] syslog(LOG_CRIT, msg); ^~~ 1 diagnostic generated. *** Error code 1 2 errors *** Error code 2 1 error >>> >>> Actually the above error message was garbled by -j#, here's a more >>> informative one: >> >> Maybe this is why you have to place NO_WERROR and WERROR into make.conf >> before building? > > Ahh yes, I thought something was nagging me about the order of setting > make.conf vars and buildworld in Roman's message :) Is there a -Wno-security with clang? Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ISO9660 4GB directory structures boundary limit and growisofs
Hi, It is apparently not possible to make use of -use-the-force-luke=4gms on FreeBSD when appending new session after 4GB. Mounted disk afterwards show nothing. Should we allow it like linux does? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r206408 - in head: etc etc/defaults etc/rc.d share/man/man5
On 4/16/2010 3:27 PM, Bjoern A. Zeeb wrote: > On Fri, 9 Apr 2010, Doug Barton wrote: > > Hi, > > first off all it would have been easier to figure a few things out, if > the several different things had been individual commits I considered that but given that the changes had to happen at the same time because they were interrelated, this seemed impractical. Of course if there are any questions about the changes that I can answer for you, I will be happy to do so. Given that the various functions in network.subr are highly interrelated I found that the easiest way to review it was to have several windows open at the same time so that I could trace the interactions. It took me quite some time to unravel it all. The diff itself is nearly unintelligible, I suggest that you review the actual code in its current form. > or if the > commit hadn't happed in the middle of a discussion that died with > this. I took from the discussion the few things that we had achieved some form of consensus on, and chose to drop the rest of the topics that I had severe disagreements about. I also followed up to the list regarding this, and my reasons for dropping out. > The comments below are on the first four things I could figure > out easily. > >> Author: dougb >> Date: Fri Apr 9 01:35:09 2010 >> New Revision: 206408 >> URL: http://svn.freebsd.org/changeset/base/206408 >> >> Log: > ... >> 6. Add support for the [NO]RTADV options in ifconfig_getargs() and >> ipv6_autoconfif(). In the latter, include support for the explicit >> addition of [-]accept_rtadv in ifconfig__ipv6 as is done >> in the current code. > > So usually we seem to use the upper case pseudo arguments like DHCP, > SYNCDHCP, WPA, .. in combination with an actual command to start apart > from ifconfig. Now RTADV does not do that but it passes accept_rtadv or > -accept_rtadv to ifconfig. So if you need a command alias for that it > should probably be in ifconfig and discussed separately. I understand your argument, but I don't agree with it. The one thing that there was actually strong consensus on was that the IPv6 configuration should have feature-parity with IPv4. Given that we have easy to use knobs to enable things like DHCP and WPA that users are already familiar with it made sense to me to introduce the same types of knobs for RA. This is in anticipation of also adding support for DHCPV6 at some point in the future. From a user interface standpoint it does not make sense to have one form of IPv6 configuration to require an ifconfig statement, and another to have a knob. Furthermore: 1. I explicitly included support for the existence of [-]accept_rtadv in ifconfig_IF_ipv6 so if you or anyone else prefers that method of configuration it's available to you. 2. Just because RTADV doesn't start something "apart from ifconfig" now doesn't mean it won't or can't in the future. Specifically I'd like to see this knob turn on rtsold as well. (Even if I thought your argument above was valid, which I do not.) > Please revert this part. As I not only do not believe that you've proved your case but I also strongly disagree with your perspective on what I believe to be valid grounds, I must politely decline your request. OTOH, I would be supportive of any efforts you wanted to make in regards to documenting the ability to specify [-]accept_rtadv with ifconfig in rc.conf.5 and/or etc/defaults/rc.conf if you so desire. >> Switch ipv6_prefer to YES. If ipv6_enable is not set this will have >> no effect. > > This changed the default. It did not. Previous to the introduction (and overloading) of the ipv6_prefer knob if you enabled IPv6 support with ipv6_enable it was preferred. With the code just prior to my change in order to configure IPv6 for an interface at all it was necessary to set ipv6_prefer to on, which meant that there was no way to have IPv6 configured but not have it be preferred. With my changes to the user interface I've completely decoupled the 3 features that were previously overloaded into ipv6_enable: ability to configure IPv6, acceptance of RA, and preference of v6 over v4. Furthermore, one could easily deduce from the act of configuring IPv6 that the user would wish it to be preferred. However just in case that isn't true I purposely moved the ipv6_prefer knob up to just after ipv6_network_interfaces in defaults/rc.conf and up the list in rc.conf.5 as well to be sure that the user had a chance to see it and change it if necessary. > I have no idea where in the commit message it was but I must have > missed it. Anyway, with this change the link-local addresses are > there by default If INET6 is in the kernel, the loopback and link-local addresses for lo0 are always configured. My understanding is that this is a requirement, and Bad Things will happen if it's not done. However, in the absence of an ifconfig_IF_ipv6 line of some sort for an interface other than lo0 no IPv6 configuration should be happening for it at all, including
fix for compressed coredumps, please review
Can I get a review for this?
summary:
If doing compressed cores and there is an error, we leak
resources unless this is fixed.
Index: imgact_elf.c
===
--- imgact_elf.c(revision 206498)
+++ imgact_elf.c(working copy)
@@ -29,7 +29,7 @@
*/
#include
-__FBSDID("$FreeBSD$");
+__FBSDID("$FreeBSD: head/sys/kern/imgact_elf.c 205643 2010-03-25 14:31:26Z
nwhitehorn $");
#include "opt_compat.h"
#include "opt_core.h"
@@ -1088,8 +1088,10 @@
hdrsize = 0;
__elfN(puthdr)(td, (void *)NULL, &hdrsize, seginfo.count);
- if (hdrsize + seginfo.size >= limit)
- return (EFAULT);
+ if (hdrsize + seginfo.size >= limit) {
+ error = EFAULT;
+ goto done;
+ }
/*
* Allocate memory for building the header, fill it up,
@@ -1097,7 +1099,8 @@
*/
hdr = malloc(hdrsize, M_TEMP, M_WAITOK);
if (hdr == NULL) {
- return (EINVAL);
+ error = EINVAL;
+ goto done;
}
error = __elfN(corehdr)(td, vp, cred, seginfo.count, hdr, hdrsize,
gzfile);
@@ -1125,8 +1128,8 @@
curproc->p_comm, error);
}
+done:
#ifdef COMPRESS_USER_CORES
-done:
if (core_buf)
free(core_buf, M_TEMP);
if (gzfile)
--
- Alfred Perlstein
.- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250
.- FreeBSD committer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
