Re: svn commit: r213248 - head/sys/kern
In message: Sergey Kandaurov writes: : On 2 October 2010 22:12, Antoine Brodin wrote: : > On Tue, Sep 28, 2010 at 5:33 PM, Warner Losh wrote: : >> Author: imp : >> Date: Tue Sep 28 15:33:30 2010 : >> New Revision: 213248 : >> URL: http://svn.freebsd.org/changeset/base/213248 : >> : >> Log: : >> This file has been unused for ages. Retire it. : >> : >> Submitted by: pluknet : >> : >> Deleted: : >> head/sys/kern/Makefile : > : > Hi, : > : > What is the correct way to "make sysent" now ? : > : : Hi. : : It seems I just dumbbroke the useful functionality. I'm sorry. : Obviously that was somehow overlooked last time I checked it. : So, removing sysent target is not something intentional. : : I think it should be simply reverted for now, or more preferably : restored with sysent target only. Please review the commit I just made to make sure that I didn't botch anything. I'm pretty sure I got it right, but you never know. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r213248 - head/sys/kern
In message: Antoine Brodin writes: : On Tue, Sep 28, 2010 at 5:33 PM, Warner Losh wrote: : > Author: imp : > Date: Tue Sep 28 15:33:30 2010 : > New Revision: 213248 : > URL: http://svn.freebsd.org/changeset/base/213248 : > : > Log: : > This file has been unused for ages. Retire it. : > : > Submitted by: pluknet : > : > Deleted: : > head/sys/kern/Makefile : : Hi, : : What is the correct way to "make sysent" now ? Hmmm It looks like the tags part was the only obsolete part... I'll add the other one back... Sorry... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r212964 - head/sys/kern
In message: Gavin Atkinson writes: : On Thu, 23 Sep 2010, Ken Smith wrote: : > The issues talked about so far all contribute to the reason for that. : > But one of the more basic gut reactions to it all is that the users : > want to be interested in helping with the debugging (even if just : > providing the requested info) for any sort of crash information : > to be useful. And at the point we shift something from -current : > to -stable the percentage of people actively interested in participating : > in that sort of stuff flip. The bulk of people using -current : > know it's risky and they do it out of some interest in debugging : > stuff. The *bulk* of people using -stable are less interested or : > flat out not interested. And have no clue what crash dumps are, : > may be challenged to notice partition-getting-full issues, etc. : : I'm not sure I buy this argument, I'm afraid. Part of the advantage of : having all this done automatically on the as-shipped release media is that : end users don't have to be interested in debugging - crashinfo(8) does : most of the work for them. There's no easy way to actually determine : figures, but even if say only 10-15% of crashes can be diagnosed and : corrected just from the output of crashinfo(8) then that's a huge win for : the project as a whole. I'm guessing 10-15% is not unrealistic. : : I appreciate the issue about filling partitions is a valid one. Would a : possible compromise be that on release media, crashinfo(8) or similar will : default to only keeping the most recent coredump or similar? Given /var : now defaults to 4GB, Defaulting to keeping a single core is probably : acceptable. Furthermore, if we aren't interested in crash dumps by default, why do we install the huge .symbols files? Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r209510 - head
In message: <20100920.230006.634347869592887498@bsdimp.com>
"M. Warner Losh" writes:
: In message:
: Andrew Thompson writes:
: : On 25 June 2010 04:32, Warner Losh wrote:
: : > Author: imp
: : > Date: Thu Jun 24 16:32:20 2010
: : > New Revision: 209510
: : > URL: http://svn.freebsd.org/changeset/base/209510
: : >
: : > Log:
: : > Merge from tbemd:
: : >
: : > change the name of the object tree from ${TARGET} to
: : > ${TARGET}.${TARGET_ARCH} so we can do both big and little endian
: : > builds in the same tree.
: :
: : This seems to have broken the VCS string in vers.c, does this look ok?
: :
: : Index: sys/conf/newvers.sh
: : ===
: : --- sys/conf/newvers.sh (revision 212945)
: : +++ sys/conf/newvers.sh (working copy)
: : @@ -91,7 +91,7 @@ case "$d" in
: : */sys/*)
: : SRCDIR=${d##*obj}
: : if [ -n "$MACHINE" ]; then
: : - SRCDIR=${SRCDIR##/$MACHINE}
: : + SRCDIR=${SRCDIR##/$MACHINE.$MACHINE_ARCH}
: : fi
: : SRCDIR=${SRCDIR%%/sys/*}
:
: Sure. 3 months to notice...
:
: I think this may be because I don't have these lines anymore in my
: newvers.sh...
I guess what I was trying to say was that this change shouldn't be a
problem.
However, I've completely gutted that section of newvers.sh, since it
isn't necessary, and have been running with it since before BSDcan.
Maybe I'll just commit it...
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r209510 - head
In message:
Andrew Thompson writes:
: On 25 June 2010 04:32, Warner Losh wrote:
: > Author: imp
: > Date: Thu Jun 24 16:32:20 2010
: > New Revision: 209510
: > URL: http://svn.freebsd.org/changeset/base/209510
: >
: > Log:
: > Merge from tbemd:
: >
: > change the name of the object tree from ${TARGET} to
: > ${TARGET}.${TARGET_ARCH} so we can do both big and little endian
: > builds in the same tree.
:
: This seems to have broken the VCS string in vers.c, does this look ok?
:
: Index: sys/conf/newvers.sh
: ===
: --- sys/conf/newvers.sh (revision 212945)
: +++ sys/conf/newvers.sh (working copy)
: @@ -91,7 +91,7 @@ case "$d" in
: */sys/*)
: SRCDIR=${d##*obj}
: if [ -n "$MACHINE" ]; then
: - SRCDIR=${SRCDIR##/$MACHINE}
: + SRCDIR=${SRCDIR##/$MACHINE.$MACHINE_ARCH}
: fi
: SRCDIR=${SRCDIR%%/sys/*}
Sure. 3 months to notice...
I think this may be because I don't have these lines anymore in my
newvers.sh...
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r212517 - head/lib/libz
In message: <4c95eb21.1030...@delphij.net> Xin LI writes: : -BEGIN PGP SIGNED MESSAGE- : Hash: SHA256 : : On 2010/09/12 18:44, Warner Losh wrote: : > Author: imp : > Date: Mon Sep 13 01:44:07 2010 : > New Revision: 212517 : > URL: http://svn.freebsd.org/changeset/base/212517 : > : > Log: : > Include FreeBSD svn tag : : The file was completely the same with libz vendor version now (except : your addition of $FreeBSD$ tag). Plus: : : [delp...@delta] /usr/src/lib/libz> svn pl minigzip.c : Properties on 'minigzip.c': : fbsd:nokeywords : : Or, do we require $FreeBSD$ tags for every files? Well, we usually do. However, this may have been a mistake on my part while cleaning up a tree before I deleted it. If the omission was intentional, then it was a mistake on my part, and should be backed out. Should I do the honors, or will that mess something else up? Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r212374 - head/usr.bin/printf
In message:
Juli Mallett writes:
: On Thu, Sep 16, 2010 at 04:36, Bruce Evans wrote:
: > WHat about the lesser burder on a character or two for putting -- in the
: > synopsis where it is more visible:
: >
: > printf [--] format [arguments ...]
:
: Right, that's what I've been thinking about. For that matter, does
: printf(1) need to use getopt(3) at all? It seems like simply checking
: for "--" could be sufficient. Does POSIX require that it exit with an
: error if it's given any options? At the very least, it seems like it
: would be more productive to have printf(1) give unusually-helpful
: error messages (perhaps merely changing its usage output to match that
: synopsis) if it encounters a string beginning with '-' other than
: "--".
if (getenv("POSIX_ME_HARDER") && arg[0] == '-' && arg[1] != '-')
errx(1, "Strict posix compliance says you lose.");
might be all that's needed.
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r212630 - in head/lib/libthr: . thread
In message: <20100914231728.33ca7...@kan.dnsalias.net>
Alexander Kabaev writes:
: On Wed, 15 Sep 2010 02:56:33 + (UTC)
: David Xu wrote:
:
: > Author: davidxu
: > Date: Wed Sep 15 02:56:32 2010
: > New Revision: 212630
: > URL: http://svn.freebsd.org/changeset/base/212630
: >
: > Log:
: > add code to support stack unwinding when thread exits. note that
: > only defer-mode cancellation works, asynchrnous mode does not work
: > because it lacks of libuwind's support. stack unwinding is not
: > enabled unless LIBTHR_UNWIND_STACK is defined in Makefile.
: >
: > Modified:
: > head/lib/libthr/Makefile
: > head/lib/libthr/thread/thr_clean.c
: > head/lib/libthr/thread/thr_create.c
: > head/lib/libthr/thread/thr_exit.c
: > head/lib/libthr/thread/thr_init.c
: > head/lib/libthr/thread/thr_private.h
: >
: > Modified: head/lib/libthr/Makefile
: >
==
: > --- head/lib/libthr/MakefileWed Sep 15 01:21:30 2010
: > (r212629) +++ head/lib/libthr/Makefile Wed Sep 15 02:56:32
: > 2010(r212630) @@ -25,6 +25,14 @@
: > CFLAGS+=-I${.CURDIR}/../../libexec/rtld-
: > CFLAGS+=-I${.CURDIR}/../../libexec/rtld-elf/${MACHINE_CPUARCH}
: > CFLAGS+=-I${.CURDIR}/../libthread_db CFLAGS+=-Winline
: > +
: > +LIBTHR_UNWIND_STACK=yes
: > +
: > +.ifdef LIBTHR_UNWIND_STACK
: > +CFLAGS+=-I${.CURDIR}/../../contrib/gcc -fexceptions
: > +CFLAGS+=-D_PTHREAD_FORCED_UNWIND
: > +.endif
: > +
: >
:
: Reaching into bowels of GCC like that is never good.
Would this pulling in GPL'd code?
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r212558 - head/usr.bin
In message: <4c9020c5.90...@freebsd.org>
Doug Barton writes:
: On 9/13/2010 8:30 AM, Warner Losh wrote:
: > Author: imp
: > Date: Mon Sep 13 15:30:09 2010
: > New Revision: 212558
: > URL: http://svn.freebsd.org/changeset/base/212558
: >
: > Log:
: >Move to using Makefile.arch to include the proper target-specific
: >programs.
: >
: > Modified:
: >head/usr.bin/Makefile
: >
: > Modified: head/usr.bin/Makefile
: >
==
: > --- head/usr.bin/Makefile Mon Sep 13 15:19:49 2010(r212557)
: > +++ head/usr.bin/Makefile Mon Sep 13 15:30:09 2010 (r212558)
: > @@ -11,48 +11,29 @@
: >
: > SUBDIR= alias \
: > apply \
: > - ${_ar} \
:
: > .if ${MK_TOOLCHAIN} != "no"
: > -_ar= ar
:
: > +SUBDIR+= ar
:
:
: I'm curious about why you're changing the method we use to switch
: optional elements. The change seems gratuitous to me, but I'm willing
: to be persuaded.
I posted these exact patches many times to arch@ and while people
commented on other aspects of the change, no body ever commented on
this aspect of the change (apart from comments about how to do it
better). That's why I specifically said that there was no objection
from arch@ for these changes.
Doing things this way makes it easier for different architectures to
subset or augment the directories to build (and it makes it a lot
easier to know what's built on a given architecture). They can be
concentrated into individual Makefiles that are easier to select on.
MIPS and ARM are both moving to having multiple names (powerpc moved a
couple of months ago) and the current arrangement doesn't scale well
in the face of these changes. It is far from gratuitous.
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r212525 - head/usr.sbin
In message: Andrew Thompson writes: : On 13 September 2010 14:21, Warner Losh wrote: : > Author: imp : > Date: Mon Sep 13 02:21:07 2010 : > New Revision: 212525 : > URL: http://svn.freebsd.org/changeset/base/212525 : > : > Log: : > Merge from tbemd: use Makefile.arch to control building. : > : > Reviewed by: arch@ (many times, no objection) : > : > Added: : > head/usr.sbin/Makefile.amd64 (contents, props changed) : > head/usr.sbin/Makefile.arm (contents, props changed) : > head/usr.sbin/Makefile.i386 (contents, props changed) : > head/usr.sbin/Makefile.ia64 (contents, props changed) : > head/usr.sbin/Makefile.mips (contents, props changed) : > head/usr.sbin/Makefile.orig (contents, props changed) : : ^^ oops. Yea, noticed when I almost made the mistake again. Fixed. Thanks! Others? Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r212270 - head/share/man/man4
In message: <201009062202.o86m29b4067...@svn.freebsd.org> Weongyo Jeong writes: : Author: weongyo : Date: Mon Sep 6 22:02:08 2010 : New Revision: 212270 : URL: http://svn.freebsd.org/changeset/base/212270 : : Log: : Adds bwi(4) at SEE ALSO section because some old devices aren't : supported by the bwn(4) firmware that as fas as I know the vendor : dropped its support. Bumps date also. Should we list them, at least by description? These are the 802.11b-only cards from what I've read in the Linux lists. They don't have enough RAM... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211722 - head/cddl/lib/libzpool
In message: <20100830205814.gf1...@garage.freebsd.pl>
Pawel Jakub Dawidek writes:
: On Mon, Aug 23, 2010 at 05:36:00PM -0600, M. Warner Losh wrote:
: > In message: <201008232204.o7nm4upa054...@svn.freebsd.org>
: > Marius Strobl writes:
: > : Author: marius
: > : Date: Mon Aug 23 22:04:30 2010
: > : New Revision: 211722
: > : URL: http://svn.freebsd.org/changeset/base/211722
: > :
: > : Log:
: > : Use real atomic operations for sparc64.
: > :
: > : MFC after: 1 week
: > :
: > : Modified:
: > : head/cddl/lib/libzpool/Makefile
: > :
: > : Modified: head/cddl/lib/libzpool/Makefile
: > :
==
: > : --- head/cddl/lib/libzpool/Makefile Mon Aug 23 21:40:03 2010
(r211721)
: > : +++ head/cddl/lib/libzpool/Makefile Mon Aug 23 22:04:30 2010
(r211722)
: > : @@ -11,7 +11,7 @@
: > : # LIST_SRCS
: > : .PATH: ${.CURDIR}/../../../sys/cddl/contrib/opensolaris/uts/common/os
: > : # ATOMIC_SRCS
: > : -.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "amd64" ||
${MACHINE_ARCH} == "ia64" || ${MACHINE_ARCH} == "powerpc64"
: > : +.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "amd64" ||
${MACHINE_ARCH} == "ia64" || ${MACHINE_ARCH} == "sparc64" || ${MACHINE_ARCH} ==
"powerpc64"
: > : .PATH:
${.CURDIR}/../../../sys/cddl/contrib/opensolaris/common/atomic/${MACHINE_ARCH}
: > : ATOMIC_SRCS= opensolaris_atomic.S
: > : .else
: >
: > I find it disturbing that we have 3 or 4 copies of this code in our
: > Makefiles...
:
: Then you will like @183089 :)
Yea, I have something very similar in my TBEMD branch... :)
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211832 - head/usr.sbin
In message: Juli Mallett writes: : On Wed, Aug 25, 2010 at 22:25, Warner Losh wrote: : > Author: imp : > Date: Thu Aug 26 05:25:51 2010 : > New Revision: 211832 : > URL: http://svn.freebsd.org/changeset/base/211832 : > : > Log: : > Ugly kludge to paper over some kind of ld bug and/or misuse: don't : > build uathload on mips n64 either. : : Thanks for taking care of this. : : If you could include n32 in this case, that'd be great. I don't know : whether the rescue stuff is also broken on n32, but it's probably : worth doing a quick build with TARGET_ABI=n32 to check, if you're in : the mood to commit these workarounds :) OK. Too bad this ugly kludge broke the case when TARGET_ABI isn't defined :( Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211722 - head/cddl/lib/libzpool
In message: <201008232204.o7nm4upa054...@svn.freebsd.org>
Marius Strobl writes:
: Author: marius
: Date: Mon Aug 23 22:04:30 2010
: New Revision: 211722
: URL: http://svn.freebsd.org/changeset/base/211722
:
: Log:
: Use real atomic operations for sparc64.
:
: MFC after: 1 week
:
: Modified:
: head/cddl/lib/libzpool/Makefile
:
: Modified: head/cddl/lib/libzpool/Makefile
: ==
: --- head/cddl/lib/libzpool/Makefile Mon Aug 23 21:40:03 2010
(r211721)
: +++ head/cddl/lib/libzpool/Makefile Mon Aug 23 22:04:30 2010
(r211722)
: @@ -11,7 +11,7 @@
: # LIST_SRCS
: .PATH: ${.CURDIR}/../../../sys/cddl/contrib/opensolaris/uts/common/os
: # ATOMIC_SRCS
: -.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "amd64" ||
${MACHINE_ARCH} == "ia64" || ${MACHINE_ARCH} == "powerpc64"
: +.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "amd64" ||
${MACHINE_ARCH} == "ia64" || ${MACHINE_ARCH} == "sparc64" || ${MACHINE_ARCH} ==
"powerpc64"
: .PATH:
${.CURDIR}/../../../sys/cddl/contrib/opensolaris/common/atomic/${MACHINE_ARCH}
: ATOMIC_SRCS= opensolaris_atomic.S
: .else
I find it disturbing that we have 3 or 4 copies of this code in our
Makefiles...
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211695 - head/sys/kern
Hi Pluknet...
I think that kern/Makefile is an ex-parrot and plan on removing it
later today.
Warner
P.S. sorry for the top post, but I wanted things in the archives..
In message:
pluknet writes:
: On 23 August 2010 10:22, Warner Losh wrote:
: > Author: imp
: > Date: Mon Aug 23 06:22:35 2010
: > New Revision: 211695
: > URL: http://svn.freebsd.org/changeset/base/211695
: >
: > Log:
: > This should really be MACHINE not MACHINE_ARCH, and is this Makefile even
used?
: >
:
: Hi.
:
: I wrote this letter almost 2.5y ago with no response.
: Hope this helps.
:
: %%%
: I looked at sys/kern/ Makefile Make.tags.inc. AFAICS they were partially
: abandoned years ago and has broken tags support and even contain 4.4BSD-Lite
: paths, that never ever being in FreeBSD CVS or was dropped years ago. So make
: links exits with error. It looks very odd:
:
: pl$ make links
: rm -f /var/db/sys_tags
: ln -s /sys/i386/tags /var/db/sys_tags
: for i in conf dev dev/scsi fs fs/deadfs fs/fdescfs fs/fifofs
: fs/lofs fs/nullfs fs/portalfs fs/procfs fs/specfs fs/unionfs hp
: hp/dev hp/hpux kern libkern net netinet nfs scripts sys ufs ufs/ffs
: ufs/lfs ufs/ufs vm; do (cd ../$i && { rm -f tags; ln -s
: /var/db/sys_tags tags; }) done
: cd: can't cd to ../dev/scsi
: cd: can't cd to ../fs/lofs
: cd: can't cd to ../fs/specfs
: cd: can't cd to ../hp
: cd: can't cd to ../hp/dev
: cd: can't cd to ../hp/hpux
: cd: can't cd to ../scripts
: cd: can't cd to ../ufs/lfs
: for i in i386; do (cd ../$i && make SYSTAGS=/var/db/sys_tags links); done
: for i in /sys/conf /sys/kern /sys/net /sys/netatalk /sys/netatm
: /sys/netinet /sys/netinet6 /sys/netipsec /sys/netipx /sys/netnatm
: /sys/nfs /sys/pci /sys/vm /sys/sys; do (cd $i && { rm -f tags; ln
: -s ../i386/tags tags; }) done
: for i in /sys/dev/advansys /sys/dev/aha /sys/dev/aic7xxx
: /sys/dev/buslogic /sys/dev/ccd /sys/dev/dec /sys/dev/dpt
: /sys/dev/en /sys/dev/hea /sys/dev/hfa /sys/dev/iicbus /sys/dev/isp
: /sys/dev/pdq /sys/dev/ppbus /sys/dev/smbus /sys/dev/vn
: /sys/dev/vx /sys/fs/deadfs /sys/fs/devfs /sys/fs/fdescfs
: /sys/fs/fifofs /sys/fs/msdosfs /sys/fs/nullfs /sys/fs/portalfs
: /sys/fs/procfs /sys
: /fs/specfs /sys/fs/unionfs /sys/fs/cd9660 /sys/ufs/ffs
: /sys/ufs/ufs; do (cd $i && { rm -f tags; ln -s ../../i386/tags tags;
: }) done
: cd: can't cd to /sys/dev/ccd
: cd: can't cd to /sys/dev/dec
: cd: can't cd to /sys/dev/hea
: cd: can't cd to /sys/dev/vn
: cd: can't cd to /sys/fs/specfs
: for i in apm i386 ibcs2 include isa linux; do (cd $i && { rm -f tags;
: ln -s ../tags tags; }) done
: cd: can't cd to apm
:
: I moved that two files from src and could complete build kernel
: without errors, so it
: seems they are not referenced by any kernel building tools.
:
: Yes, there is tags target in src/Makefile, I didn't looked too much
: how it interacts with Makefile Make.tags.inc, but by their erroneous
: paths I doubt there is any interaction.
:
: I found this in NetBSD's kern/Makefile:
: +# XXX
: +# [Note by Perry Metzger, Sept. 1998]
: +# As it stands, the tags support below is hopelessly
: +# broken. Just look at the names of the architectures it is dealing
: +# with and where it expects to find the support for them to see why.
: +# I've left the stuff in this Makefile alone in the hope that someone
: +# will fix it someday -- I am assuming that it might help that
: +# person if they have the old Makefile goo left in place as a starting
: +# point.
: +# XXX
:
: ps. BTW I tried to make tags from src/ (with clean obj, if that
: matters) and the target
: began to build my gcc (cc/cc_tools) after going through various world paths.
: Is that intended?
: %%%
:
: --
: wbr,
: pluknet
:
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211501 - in head/sys: modules modules/send netinet netinet6 sys
In message: <20100823070057.ga6...@freebsd.org> Alexey Dokuchaev writes: : That said, I wish we all grow a thiker skin and start actually value the : criticism like we did in the old days. We do value criticism, when it is constructive, flexible and well timed. The point that everybody has been making is that Doug's criticism didn't meet these criteria. He chose a bad example (Ana already had a man page in review, evidently) and pressed it beyond all reason. The project has grown to this point because although we have guidelines, we intelligently apply them rather than having cast-in-stone rules (just look at our bylaws, for example). In addition, he presented no evidence to show that we have a problem that's worse than before. He didn't pick, say, those items added in the last year that still don't have documentation to bolster his case, nor did he research to see if there might be a small group of people that don't document and address his concerns to them rather than the whole group which my experience tells me is doing a good, but not perfect, job with documentation. In short, he flew off the handle at an issue he feels strongly about, and has been somewhat inflexible about accepting this very criticism. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211501 - in head/sys: modules modules/send netinet netinet6 sys
In message: <4c717990.6020...@freebsd.org> Doug Barton writes: : On 08/21/2010 18:12, M. Warner Losh wrote: : > Do we really need to have a bunch of threads about why people should : > do the things they have promised to do? : : Since this is basically a useless/snarky question, here are some : useless/snarky responses. Feel free to pick your favorite. : : Apparently we do, since there's still no man page for the new feature. : : I don't know Warner, what do you think? : : How many threads would you prefer on this topic? : : I guess you're right, we don't really need man pages after all. Thanks : for setting me straight. I think you're drawing the wrong conclusion here. My point is that we have trusted folks in the past to do the right thing, even when they don't say they will. Here we have someone who says she'll commit something soon. We should take her at her word that she'll do this. Reverting all the code is cutting off our nose to spite our face and is too extreme a remedy raised far too early in the process. Complaining like this sends lots of negative energy towards Ann and might actively turn her off to writing the man page, which is exactly the result you are trying to avoid. While the ends are noble, the means I strongly disagree with. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211594 - head/sys/dev/bge
In message: <20100822022001.gc1...@michelle.cdnetworks.com> Pyun YongHyeon writes: : On Sat, Aug 21, 2010 at 08:10:42PM -0600, M. Warner Losh wrote: : > In message: <20100822012433.gb1...@michelle.cdnetworks.com> : > Pyun YongHyeon writes: : > : On Sat, Aug 21, 2010 at 07:13:34PM -0600, M. Warner Losh wrote: : > : > In message: <201008212313.o7lndgph083...@svn.freebsd.org> : > : > Pyun YongHyeon writes: : > : > : Author: yongari : > : > : Date: Sat Aug 21 23:13:16 2010 : > : > : New Revision: 211594 : > : > : URL: http://svn.freebsd.org/changeset/base/211594 : > : > : : > : > : Log: : > : > : Load tunable from loader.conf(5) instead of device.hints(5). : > : > : > : > Why the move? : > : > : > : : > : Because bge(4) man page didn't mention device.hints. The tunable : > : could be set via sysctl or loader. : > : > It's just that our other drivers use the hints mechanism. : > : > Of course, you could easily set either of these in either loader.conf : > or device.hints... They are basically the same thing... : > : : Yes, but hints requires "hint" string to be present before : driver.unit.keyword string which is not the same syntax of sysctl : variable. I guess my bigger point is that we should consider migration now that we have a better mechanism... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211594 - head/sys/dev/bge
In message: <20100822012433.gb1...@michelle.cdnetworks.com> Pyun YongHyeon writes: : On Sat, Aug 21, 2010 at 07:13:34PM -0600, M. Warner Losh wrote: : > In message: <201008212313.o7lndgph083...@svn.freebsd.org> : > Pyun YongHyeon writes: : > : Author: yongari : > : Date: Sat Aug 21 23:13:16 2010 : > : New Revision: 211594 : > : URL: http://svn.freebsd.org/changeset/base/211594 : > : : > : Log: : > : Load tunable from loader.conf(5) instead of device.hints(5). : > : > Why the move? : > : : Because bge(4) man page didn't mention device.hints. The tunable : could be set via sysctl or loader. It's just that our other drivers use the hints mechanism. Of course, you could easily set either of these in either loader.conf or device.hints... They are basically the same thing... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211501 - in head/sys: modules modules/send netinet netinet6 sys
In message: Doug Barton writes: : On Sat, 21 Aug 2010, Rui Paulo wrote: : : > If your concern is to change the status quo, you do understand that : > you picked the worst possible thread to hijack ? Esp. since the author : > promised to roll out a man page. : : I didn't hijack anything, I responded to Ana's message saying that a : man page was forthcoming. To me, since Ana intends to write a man page : anyway I thought this was an excellent opportunity to highlight the : fact that committing the man page along with the code is the preferred : course of action. Do we really need to have a bunch of threads about why people should do the things they have promised to do? Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211594 - head/sys/dev/bge
In message: <201008212313.o7lndgph083...@svn.freebsd.org> Pyun YongHyeon writes: : Author: yongari : Date: Sat Aug 21 23:13:16 2010 : New Revision: 211594 : URL: http://svn.freebsd.org/changeset/base/211594 : : Log: : Load tunable from loader.conf(5) instead of device.hints(5). Why the move? Warner : Modified: : head/sys/dev/bge/if_bge.c : : Modified: head/sys/dev/bge/if_bge.c : == : --- head/sys/dev/bge/if_bge.c Sat Aug 21 22:23:22 2010(r211593) : +++ head/sys/dev/bge/if_bge.c Sat Aug 21 23:13:16 2010(r211594) : @@ -4898,6 +4898,8 @@ bge_add_sysctls(struct bge_softc *sc) : struct sysctl_ctx_list *ctx; : struct sysctl_oid_list *children, *schildren; : struct sysctl_oid *tree; : + char tn[32]; : + int unit; : : ctx = device_get_sysctl_ctx(sc->bge_dev); : children = SYSCTL_CHILDREN(device_get_sysctl_tree(sc->bge_dev)); : @@ -4917,6 +4919,7 @@ bge_add_sysctls(struct bge_softc *sc) : : #endif : : + unit = device_get_unit(sc->bge_dev); : /* :* A common design characteristic for many Broadcom client controllers :* is that they only support a single outstanding DMA read operation : @@ -4929,13 +4932,13 @@ bge_add_sysctls(struct bge_softc *sc) :* performance is about 850Mbps. However forcing coalescing mbufs :* consumes a lot of CPU cycles, so leave it off by default. :*/ : + sc->bge_forced_collapse = 0; : + snprintf(tn, sizeof(tn), "dev.bge.%d.forced_collapse", unit); : + TUNABLE_INT_FETCH(tn, &sc->bge_forced_collapse); : SYSCTL_ADD_INT(ctx, children, OID_AUTO, "forced_collapse", : CTLFLAG_RW, &sc->bge_forced_collapse, 0, : "Number of fragmented TX buffers of a frame allowed before " : "forced collapsing"); : - resource_int_value(device_get_name(sc->bge_dev), : - device_get_unit(sc->bge_dev), "forced_collapse", : - &sc->bge_forced_collapse); : : if (BGE_IS_5705_PLUS(sc)) : return; : ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211393 - head/lib/libutil
In message: <86bp8xf5u6@ds4.des.no> Dag-Erling Smørgrav writes: : "M. Warner Losh" writes: : > And we're back to the reason for why issetugid() :) : : Does setuid() "untaint" a program? No. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211393 - head/lib/libutil
In message: <861v9ty7bg@ds4.des.no> Dag-Erling Smørgrav writes: : Attilio Rao writes: : > Dag-Erling Smørgrav writes: : > > Perhaps the test in setusercontext() should be changed to use : > > geteuid() instead of getuid(). : > Yes, I think that it probabilly makes more sense (geteuid() testing in : > setusercontext()). : : What if the user's ~/.login_conf sets a custom PATH, and the application : switches back to root privs and fork()-exec()s some other program? And we're back to the reason for why issetugid() :) Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211503 - head/sys/mips/atheros
In message: Juli Mallett writes: : On Thu, Aug 19, 2010 at 12:16, M. Warner Losh wrote: : > Branching is a lot easier and saner. But there's still a cost to : > branching that must be weighed... : : As long as one isn't trying to be overly-clever in using the tools it : really isn't so bad and is about as bad as Perforce. I don't think we : should ever use the merge command to merge commits to head from a : short-lived/non-vendor branch. It really sounds like you have had an : unusually-bad experience with Subversion and I think we should try to : dissect that rather than writing off developing in branches. The tbemd branch has been a pita to keep going as long as I've had to... : I haven't had any significant problems with merging from head to my : branch until I reached the level of having dozens of files and : directories added in my branch originally and then looped-back from : head. yea. I'll admit that part of my angst is from the projects/mips tree, which did get somewhat out of hand. : I, like Adrian, tend to do very sort of incremental work and lots of : little commits to break up my progress (and to have lots of points to : revert to.) It has generally been my understanding that we frown on : doing that sort of thing in head. I don't see the point of generating : an E-Mail to everyone who reads the commit lists to add a small, : unused header file, except in very occasional circumstances. I think : that's a great level of detail to work at in a branch. Yea, perforce will generate mail only for those that opt in... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211503 - head/sys/mips/atheros
In message: <4c6d80a0.4080...@freebsd.org> Andre Oppermann writes: : On 19.08.2010 20:42, M. Warner Losh wrote: : > In message:<4c6d6fd7.7060...@freebsd.org> : > Andre Oppermann writes: : > : On 19.08.2010 19:20, M. Warner Losh wrote: : > :> In message:<4c6d2933.9020...@freebsd.org> : > :> Andre Oppermann writes: : > :> : On 19.08.2010 13:53, Adrian Chadd wrote: : > :> :> Author: adrian : > :> :> Date: Thu Aug 19 11:53:55 2010 : > :> :> New Revision: 211503 : > :> :> URL: http://svn.freebsd.org/changeset/base/211503 : > :> :> : > :> :> Log: : > :> :> Add some initial AR724X chipset support. : > :> :> : > :> :> This is untested but should at least allow an AR724X to boot. : > :> : : > :> : Isn't this something that should be done on a project branch and : > :> : merged back when in a good working state? : > :> : > :> We don't have a branch for mips stuff these days. This stuff is : > OK, : > :> since the AR724X is just being rolled out right now... For non : > AR724x : > :> systems, this won't affect anything... : > : : > : I was more concerned about tree breakage for non-tested code. When : > : developing something bleeding edge it is often useful to just commit : > : some stuff and have it sorted out later. In head this is more : > : dangerous. A small AR724X development branch would be ideal for : > : this. Branching is cheap with SVN these days. : > : > Merging isn't that cheap with svn. The svn:mergeinfo properties make : > them a pita. Given that this code won't break anything, except : > possibly the now-unsupported AR724x, I think a branch would be : > overkill. We'd have to drag that branch along all the time until we : > can get actual hardware to test it on, which is a high overhead. : : Didn't know that branching and merging isn't that easy with SVN after : all. This was one of the supposed benefits for switching from CVS. : If there is no risk of head breakage I don't mind at all. Branching is a lot easier and saner. But there's still a cost to branching that must be weighed... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211503 - head/sys/mips/atheros
In message: <4c6d6fd7.7060...@freebsd.org> Andre Oppermann writes: : On 19.08.2010 19:20, M. Warner Losh wrote: : > In message:<4c6d2933.9020...@freebsd.org> : > Andre Oppermann writes: : > : On 19.08.2010 13:53, Adrian Chadd wrote: : > :> Author: adrian : > :> Date: Thu Aug 19 11:53:55 2010 : > :> New Revision: 211503 : > :> URL: http://svn.freebsd.org/changeset/base/211503 : > :> : > :> Log: : > :> Add some initial AR724X chipset support. : > :> : > :> This is untested but should at least allow an AR724X to boot. : > : : > : Isn't this something that should be done on a project branch and : > : merged back when in a good working state? : > : > We don't have a branch for mips stuff these days. This stuff is OK, : > since the AR724X is just being rolled out right now... For non AR724x : > systems, this won't affect anything... : : I was more concerned about tree breakage for non-tested code. When : developing something bleeding edge it is often useful to just commit : some stuff and have it sorted out later. In head this is more : dangerous. A small AR724X development branch would be ideal for : this. Branching is cheap with SVN these days. Merging isn't that cheap with svn. The svn:mergeinfo properties make them a pita. Given that this code won't break anything, except possibly the now-unsupported AR724x, I think a branch would be overkill. We'd have to drag that branch along all the time until we can get actual hardware to test it on, which is a high overhead. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211503 - head/sys/mips/atheros
In message: <4c6d2933.9020...@freebsd.org> Andre Oppermann writes: : On 19.08.2010 13:53, Adrian Chadd wrote: : > Author: adrian : > Date: Thu Aug 19 11:53:55 2010 : > New Revision: 211503 : > URL: http://svn.freebsd.org/changeset/base/211503 : > : > Log: : >Add some initial AR724X chipset support. : > : >This is untested but should at least allow an AR724X to boot. : : Isn't this something that should be done on a project branch and : merged back when in a good working state? We don't have a branch for mips stuff these days. This stuff is OK, since the AR724X is just being rolled out right now... For non AR724x systems, this won't affect anything... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211310 - stable/8/sys/conf
In message: <1b6f3618-9eef-4c94-b198-8e0900ac5...@kientzle.com> Tim Kientzle writes: : On Aug 14, 2010, at 11:40 AM, Warner Losh wrote: : : > Author: imp : > Date: Sat Aug 14 18:40:05 2010 : > New Revision: 211310 : > URL: http://svn.freebsd.org/changeset/base/211310 : > : > Log: : > Map COMPAT_IA32 to COMPAT_FREEBSD32 : > : > Added: : > stable/8/sys/conf/options-compat (contents, props changed) : > : > Added: stable/8/sys/conf/options-compat : > == : > --- /dev/null 00:00:00 1970 (empty, because file is newly added) : > +++ stable/8/sys/conf/options-compatSat Aug 14 18:40:05 2010 (r211310) : > @@ -0,0 +1,2 @@ : > +# $FreeBSD$ : > +COMPAT_IA32COMPAT_FREEBSD32 : : This breaks the build for i386. : : "make kernel" in a clean checkout produces an error about : "COMPAT_IA32 not in options". OK. I've fixed this for all the other architectures supported in stable/8. I've also pushed a fix into -current that will fix this problem when merged to stable so we can take them back out... Sorry for the hassle... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211310 - stable/8/sys/conf
In message: <1b6f3618-9eef-4c94-b198-8e0900ac5...@kientzle.com> Tim Kientzle writes: : On Aug 14, 2010, at 11:40 AM, Warner Losh wrote: : : > Author: imp : > Date: Sat Aug 14 18:40:05 2010 : > New Revision: 211310 : > URL: http://svn.freebsd.org/changeset/base/211310 : > : > Log: : > Map COMPAT_IA32 to COMPAT_FREEBSD32 : > : > Added: : > stable/8/sys/conf/options-compat (contents, props changed) : > : > Added: stable/8/sys/conf/options-compat : > == : > --- /dev/null 00:00:00 1970 (empty, because file is newly added) : > +++ stable/8/sys/conf/options-compatSat Aug 14 18:40:05 2010 (r211310) : > @@ -0,0 +1,2 @@ : > +# $FreeBSD$ : > +COMPAT_IA32COMPAT_FREEBSD32 : : This breaks the build for i386. : : "make kernel" in a clean checkout produces an error about : "COMPAT_IA32 not in options". Yea, I neglected to commit the options.i386 file. I've just done that now. I may also need to commit this to mips, et al. Doing test builds to find out. Grump. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211146 - head
In message: Adrian Chadd writes: : On 11 August 2010 22:17, Ed Schouten wrote: : > Hi Adrian, : > : > * Adrian Chadd wrote: : >> Modified: : >> head/Makefile.mips : > : > Can't this file be simply removed now? : : I think so. Warner? I was planning on removing it once I finished the tbemd merge that's stalled :(. There's a small chance we may need it in the near future (like within the month), and I'd like to make sure we really don't before deleting it. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211023 - head/usr.sbin/syslogd
In message: <201008101956.o7aju5ms044...@haluter.fromme.com>
Oliver Fromme writes:
:
: M. Warner Losh wrote:
: > /*
: > * Macros to cast a struct sockaddr, or parts thereof. struct
: > * sockaddr's alginment is loose to later be cast to a sockaddr_in or
: > * sockaddr_in6. On architectures with strict alignment requirements,
: > * this leads to compiler warnings because the compiler doesn't know
: > * the ABI guarantees proper alignment.
: > */
: >
: > But this leads me to think that the right fix might be:
: >
: > /*
: > * Structure used by kernel to store most
: > * addresses.
: > */
: > struct sockaddr {
: >unsigned char sa_len; /* total length */
: >sa_family_t sa_family; /* address family */
: >charsa_data[14];/* actually longer; address value */
: > } __aligned(4);
: >
: > since that's what the ABI defines
:
: Yes, that would solve most of the problems, at least the ones
: related to struct sockaddr.
:
: Can we make that change to struct sockaddr, or does it cause
: unwanted side-effects?
:
: I could do a full "make universe" to test it, but it would
: probably take two days on my 9-current machine.
Just do it on MIPS.
You'll find that a number of structures are potentially already
allocated with less than required alignment. There's about a dozen
places in the tree that would start to fail if we did this, or the
stronger form of __aligned(8). We could add that to the other
structures, but then we're breaking ABI rules, I think.
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211023 - head/usr.sbin/syslogd
In message: <11606.1281464...@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20100810.115457.1126759349893144516@bsdimp.com>, "M. Warner Los : h" writes: : >In message: <20100811.023235.13138059@allbsd.org> : >Hiroki Sato writes: : >: Oliver Fromme wrote : >: in <201008101623.o7agns7i042...@haluter.fromme.com>: : >: : >: ol> -static intvalidate(struct sockaddr *, const char *); : >: ol> -static void unmapped(struct sockaddr *); : >: ol> +static intvalidate(struct sockaddr_storage *, const char *); : >: ol> +static void unmapped(struct sockaddr_storage *); : >: : >: Why is s/struct sockaddr */struct sockaddr_storage */ needed here? : >: Using (struct sockaddr *) as an argument looks reasonable to me since : >: the struct sockaddr_storage is mostly for memory allocation, not for : >: access via pointer. : > : >Because struct sockaddr * has a too loose alignment requirement for : >later casting, while sockaddr_storage has the proper alignment. : : This is the kind of detail Bruce, Warner and I know, but I bet it : was news to most of you. : : Somebody should add it to the relevant manualpages... It was news to me when I saw it :) But given other posix requirements for this interface, maybe there's a better fix... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211023 - head/usr.sbin/syslogd
In message: <86sk2m1hsj@ds4.des.no>
Dag-Erling Smørgrav writes:
: "M. Warner Losh" writes:
: > /*
: > * Macros to cast a struct sockaddr, or parts thereof.
: > * On architectures with strict alignment requirements, the compiler
: > * can bogusly warn about alignment problems since its static analysis
: > * is insufficient for it to know that with the APIs used, there
: > * really is no alignment issue.
: > */
:
: That's a bit harsh on the compiler, don't you think? It never pays to
: hurt the compiler's feelings :)
/*
* Macros to cast a struct sockaddr, or parts thereof. struct
* sockaddr's alginment is loose to later be cast to a sockaddr_in or
* sockaddr_in6. On architectures with strict alignment requirements,
* this leads to compiler warnings because the compiler doesn't know
* the ABI guarantees proper alignment.
*/
But this leads me to think that the right fix might be:
/*
* Structure used by kernel to store most
* addresses.
*/
struct sockaddr {
unsigned char sa_len; /* total length */
sa_family_t sa_family; /* address family */
charsa_data[14];/* actually longer; address value */
} __aligned(4);
since that's what the ABI defines
: > : @@ -2410,8 +2419,8 @@
: > : }
: > : reject = 0;
: > : for (j = 0; j < 16; j += 4) {
: > : - if ((*(u_int32_t
*)&sin6->sin6_addr.s6_addr[j] & *(u_int32_t *)&m6p->sin6_addr.s6_addr[j])
: > : - != *(u_int32_t
*)&a6p->sin6_addr.s6_addr[j]) {
: > : + if
((UINT32_CAST(sin6->sin6_addr.s6_addr[j]) &
UINT32_CAST(m6p->sin6_addr.s6_addr[j]))
: > : + !=
UINT32_CAST(a6p->sin6_addr.s6_addr[j])) {
: > : ++reject;
: > : break;
: > : }
: > :
: > :
: >
: > Why 16 and 4 here? What's so magical about them?
:
: 4 = bytes in a uint32_t, 16 = bytes in an ipv6 address.
Isn't that better served by 'sizeof(uint32_t)' and
'sizeof(ipv6_addr_t)'?
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211023 - head/usr.sbin/syslogd
In message: <20100811.023235.13138059@allbsd.org> Hiroki Sato writes: : Oliver Fromme wrote : in <201008101623.o7agns7i042...@haluter.fromme.com>: : : ol> -static int validate(struct sockaddr *, const char *); : ol> -static void unmapped(struct sockaddr *); : ol> +static int validate(struct sockaddr_storage *, const char *); : ol> +static void unmapped(struct sockaddr_storage *); : : Why is s/struct sockaddr */struct sockaddr_storage */ needed here? : Using (struct sockaddr *) as an argument looks reasonable to me since : the struct sockaddr_storage is mostly for memory allocation, not for : access via pointer. Because struct sockaddr * has a too loose alignment requirement for later casting, while sockaddr_storage has the proper alignment. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211023 - head/usr.sbin/syslogd
In message: <201008101623.o7agns7i042...@haluter.fromme.com>
Oliver Fromme writes:
:
: M. Warner Losh wrote:
: > In message: <201008101313.o7addhye040...@haluter.fromme.com>
: > Oliver Fromme writes:
: > : M. Warner Losh wrote:
: > : > The casting that syslogd does with struct sockaddrFOO is what triggers
: > : > it. I'm not sure how to fix it, so there's about 6 or 8 programs in
: > : > the tree that have WARNS lowered to 3 because of it.
: > :
: > : I've given it try, please see the patch below.
: > : This is not really pretty, but it's a start.
: > : It builds with WARNS=6 on all archs, including mips.
: > :
: > : What do you think?
:
: Please ignore that patch. It compiles, but has some problems.
:
: des pointed out that it makes sense to use a macro for type
: casts. The new patch below does this for the cases where
: simply using struct sockaddr_storage doesn't work.
:
: > [...]
: > : @@ -2409,9 +2414,9 @@
: > : continue;
: > : }
: > : reject = 0;
: > : -for (j = 0; j < 16; j += 4) {
: > : -if ((*(u_int32_t
*)&sin6->sin6_addr.s6_addr[j] & *(u_int32_t *)&m6p->sin6_addr.s6_addr[j])
: > : -!= *(u_int32_t
*)&a6p->sin6_addr.s6_addr[j]) {
: > : +for (j = 0; j < 16; j++) {
: > : +if ((sin6->sin6_addr.s6_addr[j]
& m6p->sin6_addr.s6_addr[j])
: > : +!=
a6p->sin6_addr.s6_addr[j]) {
: >
: > This code looks better, but why have the casts been removed? I take
: > it they aren't necessary?
:
: Right. On the other hand, the loop iterations are increased
: from 4 to 16, making the whole thing less efficient.
: In the new patch below I introduced a typecast macro for
: this case, too, so the iterations stay at 4.
:
: Again, the new patch passes the universe test.
:
: Best regards
:Oliver
:
: --- syslogd.c.orig2010-08-05 21:59:11.0 +0200
: +++ syslogd.c 2010-08-10 18:15:46.0 +0200
: @@ -123,6 +123,15 @@
: #define MAXUNAMES 20 /* maximum number of user names */
:
: /*
: + * Macros to cast a struct sockaddr, or parts thereof.
: + * These are needed to silence the compiler on architectures
: + * with strict alignment requirements.
: + */
: +
: +#define SIN_CAST(sa)((struct sockaddr_in *)(uintptr_t)(sa))
: +#define UINT32_CAST(c) (*(u_int32_t *)(uintptr_t)&(c))
You might want to add an explanation that the ABI guarantees the
uint32's will have proper alignment to be accessed in this way. Maybe:
/*
* Macros to cast a struct sockaddr, or parts thereof.
* On architectures with strict alignment requirements, the compiler
* can bogusly warn about alignment problems since its static analysis
* is insufficient for it to know that with the APIs used, there
* really is no alignment issue.
*/
: +/*
: * Unix sockets.
: * We have two default sockets, one with 666 permissions,
: * and one for privileged programs.
: @@ -330,8 +339,8 @@
: static void readklog(void);
: static void reapchild(int);
: static void usage(void);
: -static int validate(struct sockaddr *, const char *);
: -static void unmapped(struct sockaddr *);
: +static int validate(struct sockaddr_storage *, const char *);
: +static void unmapped(struct sockaddr_storage *);
: static void wallmsg(struct filed *, struct iovec *, const int iovlen);
: static int waitdaemon(int, int, int);
: static void timedout(int);
: @@ -652,8 +661,8 @@
: if (l > 0) {
: line[l] = '\0';
: hname = cvthname((struct
sockaddr *)&frominet);
: - unmapped((struct sockaddr
*)&frominet);
: - if (validate((struct sockaddr
*)&frominet, hname))
: + unmapped(&frominet);
: + if (validate(&frominet, hname))
: printline(hname, line,
RemoteAddDate ? ADDDATE : 0);
: } else if (l < 0 && errno != EINTR)
: logerror("recvfrom inet");
: @@ -678,17 +687,17 @@
: }
:
: static void
: -unmapped(struct sockaddr *sa)
: +unmapped(struct sockaddr_storage *ss)
: {
: struct sockaddr_in6 *sin6;
: struct sockaddr_in sin4;
:
: - if (sa
Re: svn commit: r211023 - head/usr.sbin/syslogd
In message: <201008101313.o7addhye040...@haluter.fromme.com>
Oliver Fromme writes:
: M. Warner Losh wrote:
: > The casting that syslogd does with struct sockaddrFOO is what triggers
: > it. I'm not sure how to fix it, so there's about 6 or 8 programs in
: > the tree that have WARNS lowered to 3 because of it.
:
: I've given it try, please see the patch below.
: This is not really pretty, but it's a start.
: It builds with WARNS=6 on all archs, including mips.
:
: What do you think?
I have just one comment at the end about the removal of the u_int32_t
casts. Otherwise, this looks really good. Thanks for taking the time
to do this.
: Best regards
:Oliver
:
: --- syslogd.c.orig2010-08-05 21:59:11.0 +0200
: +++ syslogd.c 2010-08-10 15:02:19.0 +0200
: @@ -175,7 +175,7 @@
: struct {
: charf_hname[MAXHOSTNAMELEN];
: struct addrinfo *f_addr;
: -
: + in_port_t f_port;
: } f_forw; /* forwarding address */
: charf_fname[MAXPATHLEN];
: struct {
: @@ -330,8 +330,8 @@
: static void readklog(void);
: static void reapchild(int);
: static void usage(void);
: -static int validate(struct sockaddr *, const char *);
: -static void unmapped(struct sockaddr *);
: +static int validate(struct sockaddr_storage *, const char *);
: +static void unmapped(struct sockaddr_storage *);
: static void wallmsg(struct filed *, struct iovec *, const int iovlen);
: static int waitdaemon(int, int, int);
: static void timedout(int);
: @@ -652,8 +652,8 @@
: if (l > 0) {
: line[l] = '\0';
: hname = cvthname((struct
sockaddr *)&frominet);
: - unmapped((struct sockaddr
*)&frominet);
: - if (validate((struct sockaddr
*)&frominet, hname))
: + unmapped(&frominet);
: + if (validate(&frominet, hname))
: printline(hname, line,
RemoteAddDate ? ADDDATE : 0);
: } else if (l < 0 && errno != EINTR)
: logerror("recvfrom inet");
: @@ -678,17 +678,17 @@
: }
:
: static void
: -unmapped(struct sockaddr *sa)
: +unmapped(struct sockaddr_storage *ss)
: {
: struct sockaddr_in6 *sin6;
: struct sockaddr_in sin4;
:
: - if (sa->sa_family != AF_INET6)
: + if (ss->ss_family != AF_INET6)
: return;
: - if (sa->sa_len != sizeof(struct sockaddr_in6) ||
: - sizeof(sin4) > sa->sa_len)
: + if (ss->ss_len != sizeof(struct sockaddr_in6) ||
: + sizeof(sin4) > ss->ss_len)
: return;
: - sin6 = (struct sockaddr_in6 *)sa;
: + sin6 = (struct sockaddr_in6 *)ss;
: if (!IN6_IS_ADDR_V4MAPPED(&sin6->sin6_addr))
: return;
:
: @@ -699,7 +699,7 @@
: sizeof(sin4.sin_addr));
: sin4.sin_port = sin6->sin6_port;
:
: - memcpy(sa, &sin4, sin4.sin_len);
: + memcpy(ss, &sin4, sin4.sin_len);
: }
:
: static void
: @@ -1186,8 +1186,7 @@
: break;
:
: case F_FORW:
: - port = (int)ntohs(((struct sockaddr_in *)
: - (f->f_un.f_forw.f_addr->ai_addr))->sin_port);
: + port = f->f_un.f_forw.f_port;
: if (port != 514) {
: dprintf(" %s:%d\n", f->f_un.f_forw.f_hname, port);
: } else {
: @@ -1711,8 +1710,7 @@
: break;
:
: case F_FORW:
: - port = (int)ntohs(((struct sockaddr_in *)
: -
(f->f_un.f_forw.f_addr->ai_addr))->sin_port);
: + port = f->f_un.f_forw.f_port;
: if (port != 514) {
: printf("%s:%d",
: f->f_un.f_forw.f_hname, port);
: @@ -1767,6 +1765,7 @@
: cfline(const char *line, struct filed *f, const char *prog, const char *host)
: {
: struct addrinfo hints, *res;
: + struct servent *srvent;
: int error, i, pri, syncfile;
: const char *p, *q;
: char *bp;
: @@ -1954,6 +1953,12 @@
: break;
: }
: f->f_un.f_forw.f_addr = res;
: + srvent = getservbyname(p ? p : "syslog", NULL);
: + if (srvent != NULL)
: + f->f_un.f_forw.f_port = srvent-&
Re: svn commit: r208165 - in head/sys: kern mips/conf mips/include mips/mips mips/rmi mips/rmi/dev/xlr
In message: "Jayachandran C." writes: : top->cg_level = CG_SHARE_NONE; : : >>> : >>> ... and this is why I particulary hate big commits with complete lack : >>> of technical details. : >>> : >>> This particulary chunk was supposed to fix a nasty and completely MI : >>> bug that some users have already met (kern/148698). The complete lack : >>> of details didn't help in identify the issue neither that it was a : >>> valuable fix. : >>> : >>> The fix is, however, improper (there is no clear relationship between : >>> the multiplication and why that happens) thus I would rather use what : >>> Joe has reported in the PR. : >> : >> : >> I was not aware of the PR when I sent this changes to rrs@, and this : >> went as a part of MIPS SMP support for XLR which has 32 CPUs : >> : >> But I'm not sure that the current change is correct, cg_mask is of : >> type cpumask_t and I don't think it is guaranteed to be 32 bit (as it : >> is a machine dependent type). : > : > Actually the 32 bits limit is well aware and acknowledged in cpumask_t. : > While it is true that it should be an 'opaque' type, in reality it is : > not. The maximum limit of 32 CPUs is a reality due to cpumask_t on all : > our architectures. : > That is why we are going to use cpuset_t for dealing with CPUs numbers : > (which is really opaque, at same extent, and is not bound to any : > size). : : In my opinion, your changes added another pitfall for the person who : tries to make the cpumask_t 64 bit to support more cpus, which really : could have been avoided. : : But if cpumask_t is going to be changed to cpuset_t soon, I guess we : are fine :) : : JC. Yes, the correct fix, short of cpuset_t, is not: - top->cg_mask = (1 << mp_ncpus) - 1; + if (mp_ncpus == sizeof(top->cg_mask) * 8) + top->cg_mask = -1; + else + top->cg_mask = (1 << mp_ncpus) - 1; but rather if (mp_ncpus > sizeof(top->cg_mask) * NBBY) mp_ncpus = sizeof(top->cg_mask) * NBBY; /* Or panic */ if (mp_ncpus > sizeof(top->cg_mask) * NBBY) top->cg_mask = ~0; /* which avoids the signed error */ else top->cg_mask = (1 << mp_ncpus) - 1; I'm not sure why the expression would fail (1 << 32 == 0 -1 == all bits set), but I've not looked at the old thread to see why the compiler is generating bogus code. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211021 - head/sys/dev/usb
In message: Gavin Atkinson writes: : On Sun, 8 Aug 2010, M. Warner Losh wrote: : > In message: : > Gavin Atkinson writes: : > : On Sat, 7 Aug 2010, M. Warner Losh wrote: : > : > In message: <201008071608.o77g8bnn088...@svn.freebsd.org> : > : > Gavin Atkinson writes: : > : > : Author: gavin : > : > : Date: Sat Aug 7 16:08:37 2010 : > : > : New Revision: 211021 : > : > : URL: http://svn.freebsd.org/changeset/base/211021 : > : > : : > : > : Log: : > : > : Sort this file a little better: the vendors are supposed to be sorted by : > : > : vendor ID in the vendor section, and by symbolic name in the product : > : > : section. Products are sorted by product ID. While here, get rid of a : > : > : duplicate Microsoft Mouse entry, revealed by sorting. : > : > : > : > I thought products were sorted by the ID number, not the ID name. : > : : > : Yes, within a manufacturer, products should be sorted by ID. Each : > : manufacturer section is sorted by the symbolic manufacturer name, though. : > : > Within each product section, the products are sorted by numeric id, : > not symbolic id. That's how it was when I was maintaining this file, : > and is how pccarddevs also works. : > : > eg: : > : > product ALCOR SDCR_6335 0x6335 SD/MMC Card Reader : > product ALCOR SDCR_6362 0x6362 SD/MMC Card Reader : > product ALCOR TRANSCEND 0x6387 Transcend JetFlash Drive : > product ALCOR MA_KBD_HUB0x9213 MacAlly Kbd Hub : > product ALCOR AU98140x9215 AU9814 Hub : > product ALCOR UMCR_9361 0x9361 USB Multimedia Card Reader : > product ALCOR SM_KBD0x9410 MicroConnectors/StrongMan Keyboard : > product ALCOR NEC_KBD_HUB 0x9472 NEC Kbd Hub : > product ALCOR AU63900x6390 AU6390 USB-IDE converter : : Indeed, that is wrong. That's not a section that I have touched, though. : : > : I'm not which one of us is misunderstanding the other - do you think my : > : change is somehow wrong? : > : > I think your change misorders things, unless I'm misreading it. It : > sorts based on symbolic ID rather than numeric ID. : : The only section I touched with this commit was the MICROSOFT one, and : here is the ordering after my commit: : : product MICROSOFT SIDEPREC0x0008 SideWinder Precision Pro : product MICROSOFT INTELLIMOUSE0x0009 IntelliMouse : product MICROSOFT NATURALKBD 0x000b Natural Keyboard Elite : product MICROSOFT DDS80 0x0014 Digital Sound System 80 : product MICROSOFT SIDEWINDER 0x001a Sidewinder Precision Racing Wheel : product MICROSOFT INETPRO 0x001c Internet Keyboard Pro : product MICROSOFT TBEXPLORER 0x0024 Trackball Explorer : product MICROSOFT INTELLIEYE 0x0025 IntelliEye mouse : product MICROSOFT INETPRO20x002b Internet Keyboard Pro : product MICROSOFT MN510 0x006e MN510 Wireless : product MICROSOFT MN110 0x007a 10/100 USB NIC : product MICROSOFT WLINTELLIMOUSE 0x008c Wireless Optical IntelliMouse : product MICROSOFT WLNOTEBOOK 0x00b9 Wireless Optical Mouse (Model 1023) : product MICROSOFT COMFORT3000 0x00d1 Comfort Optical Mouse 3000 (Model 1043) : product MICROSOFT WLNOTEBOOK3 0x00d2 Wireless Optical Mouse 3000 (Model 1049) : product MICROSOFT NATURAL4000 0x00db Natural Ergonomic Keyboard 4000 : product MICROSOFT WLNOTEBOOK2 0x00e1 Wireless Optical Mouse 3000 (Model 1056) : product MICROSOFT XBOX360 0x0292 XBOX 360 WLAN : : I can't see any which are misordered, can you? I must have I misread the diff then. My mistake. Sorry for the noise. I thought you were sorting based on the third column rather than the 4th. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211023 - head/usr.sbin/syslogd
In message: <86tyn4tbuc@ds4.des.no> Dag-Erling Smørgrav writes: : Jilles Tjoelker writes: : > In other cases, I propose adding a cast to void * in between, like : > (struct sockaddr_in *)(void *)ai->ai_addr : : Better to cast through uintptr_t. Perhaps we should have a : __DECONST-like macro for this? : : #define __ALIGNED_CAST(t, v) ((t)(uintptr_t)(v)) I like the idea of a macro. Why is a cast through uintptr_t better? Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211021 - head/sys/dev/usb
In message: Gavin Atkinson writes: : On Sat, 7 Aug 2010, M. Warner Losh wrote: : > In message: <201008071608.o77g8bnn088...@svn.freebsd.org> : > Gavin Atkinson writes: : > : Author: gavin : > : Date: Sat Aug 7 16:08:37 2010 : > : New Revision: 211021 : > : URL: http://svn.freebsd.org/changeset/base/211021 : > : : > : Log: : > : Sort this file a little better: the vendors are supposed to be sorted by : > : vendor ID in the vendor section, and by symbolic name in the product : > : section. Products are sorted by product ID. While here, get rid of a : > : duplicate Microsoft Mouse entry, revealed by sorting. : > : > I thought products were sorted by the ID number, not the ID name. : : Yes, within a manufacturer, products should be sorted by ID. Each : manufacturer section is sorted by the symbolic manufacturer name, though. Within each product section, the products are sorted by numeric id, not symbolic id. That's how it was when I was maintaining this file, and is how pccarddevs also works. eg: product ALCOR SDCR_6335 0x6335 SD/MMC Card Reader product ALCOR SDCR_6362 0x6362 SD/MMC Card Reader product ALCOR TRANSCEND 0x6387 Transcend JetFlash Drive product ALCOR MA_KBD_HUB0x9213 MacAlly Kbd Hub product ALCOR AU98140x9215 AU9814 Hub product ALCOR UMCR_9361 0x9361 USB Multimedia Card Reader product ALCOR SM_KBD0x9410 MicroConnectors/StrongMan Keyboard product ALCOR NEC_KBD_HUB 0x9472 NEC Kbd Hub product ALCOR AU63900x6390 AU6390 USB-IDE converter has the last one out of order only (it should be sorted 4th in this list). : I'm not which one of us is misunderstanding the other - do you think my : change is somehow wrong? I think your change misorders things, unless I'm misreading it. It sorts based on symbolic ID rather than numeric ID. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211023 - head/usr.sbin/syslogd
In message: <201008082037.o78kbldt022...@haluter.fromme.com>
Oliver Fromme writes:
:
: M. Warner Losh wrote:
: > In message: <201008071620.o77gkdbb091...@svn.freebsd.org>
: > Oliver Fromme writes:
: > : Author: olli
: > : Date: Sat Aug 7 16:20:12 2010
: > : New Revision: 211023
: > : URL: http://svn.freebsd.org/changeset/base/211023
: > : Modified: head/usr.sbin/syslogd/Makefile
: > :
==
: > : --- head/usr.sbin/syslogd/Makefile Sat Aug 7 16:14:40 2010
(r211022)
: > : +++ head/usr.sbin/syslogd/Makefile Sat Aug 7 16:20:12 2010
(r211023)
: > : @@ -12,7 +12,7 @@ SRCS= syslogd.c ttymsg.c
: > : DPADD= ${LIBUTIL}
: > : LDADD= -lutil
: > :
: > : -WARNS?= 3
: > : +WARNS?= 6
: > :
: > : .if ${MK_INET6_SUPPORT} != "no"
: > : CFLAGS+= -DINET6
: >
: > This breaks MIPS, so I've reverted it. Please make sure that all
: > architectures work when bumping up WARNS.
:
: Thanks for fixing it for me.
:
: I did make the universe check, but apparently I did something
: wrong, so I didn't notice the problem. I'm sorry for that.
The casting that syslogd does with struct sockaddrFOO is what triggers
it. I'm not sure how to fix it, so there's about 6 or 8 programs in
the tree that have WARNS lowered to 3 because of it.
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211023 - head/usr.sbin/syslogd
In message: <201008071620.o77gkdbb091...@svn.freebsd.org>
Oliver Fromme writes:
: Author: olli
: Date: Sat Aug 7 16:20:12 2010
: New Revision: 211023
: URL: http://svn.freebsd.org/changeset/base/211023
: Modified: head/usr.sbin/syslogd/Makefile
: ==
: --- head/usr.sbin/syslogd/MakefileSat Aug 7 16:14:40 2010
(r211022)
: +++ head/usr.sbin/syslogd/MakefileSat Aug 7 16:20:12 2010
(r211023)
: @@ -12,7 +12,7 @@ SRCS= syslogd.c ttymsg.c
: DPADD= ${LIBUTIL}
: LDADD= -lutil
:
: -WARNS?= 3
: +WARNS?= 6
:
: .if ${MK_INET6_SUPPORT} != "no"
: CFLAGS+= -DINET6
This breaks MIPS, so I've reverted it. Please make sure that all
architectures work when bumping up WARNS.
Thanks!
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r211021 - head/sys/dev/usb
In message: <201008071608.o77g8bnn088...@svn.freebsd.org> Gavin Atkinson writes: : Author: gavin : Date: Sat Aug 7 16:08:37 2010 : New Revision: 211021 : URL: http://svn.freebsd.org/changeset/base/211021 : : Log: : Sort this file a little better: the vendors are supposed to be sorted by : vendor ID in the vendor section, and by symbolic name in the product : section. Products are sorted by product ID. While here, get rid of a : duplicate Microsoft Mouse entry, revealed by sorting. I thought products were sorted by the ID number, not the ID name. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r210578 - head/usr.bin/grep
In message: <20100729122034.ga28...@stack.nl>
Jilles Tjoelker writes:
: On Thu, Jul 29, 2010 at 12:11:14AM +, Gabor Kovesdan wrote:
: > Author: gabor
: > Date: Thu Jul 29 00:11:14 2010
: > New Revision: 210578
: > URL: http://svn.freebsd.org/changeset/base/210578
:
: > Log:
: > - Some improvements on the exiting code, like replacing memcpy with
: > strlcpy/strcpy
:
: Hmm, I don't think this is an improvement :(
I agree in this case. The changes don't actually improve the safety
of the code, but may make the code slower due to the need to recompute
the length...
: If you know the length of the string, then memcpy() is usually the right
: function to use. I think this is clearer, and it is definitely more
: efficient.
:
: The strlcpy() function is for cases where the code does not know the
: length. The receiving buffer typically has a fixed length and overflow
: either leads to an error condition or silent truncation. (In the latter
: case, a security problem might still result.)
:
: Note that this is the reasoning of the glibc people why they do not want
: strlcat/strlcpy. I think these functions are acceptable but should be
: used with care, not as a panacea against all buffer overflows.
The glibc people's line of reasoning is flawed. Because it might be
abused, it should be excluded is not a good reason. It is
demonstrably better than the alternatives, even if it doesn't solve
all problems. By the same logic, one should remove most of str*
functions, since they can all be misused...
Warner
: > Modified: head/usr.bin/grep/fastgrep.c
: >
==
: > --- head/usr.bin/grep/fastgrep.cWed Jul 28 21:52:09 2010
(r210577)
: > +++ head/usr.bin/grep/fastgrep.cThu Jul 29 00:11:14 2010
(r210578)
: > @@ -119,8 +119,7 @@ fastcomp(fastgrep_t *fg, const char *pat
: > * string respectively.
: > */
: > fg->pattern = grep_malloc(fg->len + 1);
: > - memcpy(fg->pattern, pat + (bol ? 1 : 0) + wflag, fg->len);
: > - fg->pattern[fg->len] = '\0';
: > + strlcpy(fg->pattern, pat + (bol ? 1 : 0) + wflag, fg->len + 1);
: >
: > /* Look for ways to cheat...er...avoid the full regex engine. */
: > for (i = 0; i < fg->len; i++) {
:
: :(
:
: Note that this code may not be safe if fg->len comes from an untrusted
: user, as fg->len + 1 is 0 if fg->len == SIZE_MAX. This is not the case
: if fg->len is an actual length from strlen() or similar.
:
: > Modified: head/usr.bin/grep/grep.c
: >
==
: > --- head/usr.bin/grep/grep.cWed Jul 28 21:52:09 2010
(r210577)
: > +++ head/usr.bin/grep/grep.cThu Jul 29 00:11:14 2010
(r210578)
: [snip]
: > @@ -234,32 +237,44 @@ add_pattern(char *pat, size_t len)
: > --len;
: > /* pat may not be NUL-terminated */
: > pattern[patterns] = grep_malloc(len + 1);
: > - memcpy(pattern[patterns], pat, len);
: > - pattern[patterns][len] = '\0';
: > + strlcpy(pattern[patterns], pat, len + 1);
: > ++patterns;
: > }
:
: :(
:
: Alternatively, consider strndup() here.
:
: > /*
: > - * Adds an include/exclude pattern to the internal array.
: > + * Adds a file include/exclude pattern to the internal array.
: > */
: > static void
: > -add_epattern(char *pat, size_t len, int type, int mode)
: > +add_fpattern(const char *pat, int mode)
: > {
: >
: > /* Increase size if necessary */
: > - if (epatterns == epattern_sz) {
: > - epattern_sz *= 2;
: > - epattern = grep_realloc(epattern, ++epattern_sz *
: > + if (fpatterns == fpattern_sz) {
: > + fpattern_sz *= 2;
: > + fpattern = grep_realloc(fpattern, ++fpattern_sz *
: > sizeof(struct epat));
: > }
: > - if (len > 0 && pat[len - 1] == '\n')
: > ---len;
: > - epattern[epatterns].pat = grep_malloc(len + 1);
: > - memcpy(epattern[epatterns].pat, pat, len);
: > - epattern[epatterns].pat[len] = '\0';
: > - epattern[epatterns].type = type;
: > - epattern[epatterns].mode = mode;
: > - ++epatterns;
: > + fpattern[fpatterns].pat = grep_strdup(pat);
: > + fpattern[fpatterns].mode = mode;
: > + ++fpatterns;
: > +}
:
: This part seems an improvement. The length came from strlen() anyway.
:
: > Modified: head/usr.bin/grep/queue.c
: >
==
: > --- head/usr.bin/grep/queue.c Wed Jul 28 21:52:09 2010
(r210577)
: > +++ head/usr.bin/grep/queue.c Thu Jul 29 00:11:14 2010
(r210578)
: > @@ -60,7 +60,7 @@ enqueue(struct str *x)
: > item->data.len = x->len;
: > item->data.line_no = x->line_no;
: > item->data.off = x->off;
: > - memcpy(item->data.dat, x->dat, x->len);
: > + strcpy(item->data.dat, x->dat);
: > item->data.file = x->file;
: >
: > STAILQ_INSERT_TAIL(&queue, item
Re: svn commit: r210286 - head/sys/contrib/octeon-sdk
In message: <201007200719.o6k7jhfj022...@svn.freebsd.org> Juli Mallett writes: : Author: jmallett : Date: Tue Jul 20 07:19:43 2010 : New Revision: 210286 : URL: http://svn.freebsd.org/changeset/base/210286 : : Log: : Import the Cavium Simple Executive from the Cavium Octeon SDK. The Simple : Executive is a library that can be used by standalone applications and kernels : to abstract access to Octeon SoC and board-specific hardware and facilities. : The FreeBSD port to Octeon will be updated to use this where possible. It should be noted that this is from the Cavium User's site and has basically a BSD license with a special disclaimer of liability/warranty. Cavium documents this as being compatible with the closed-source version that Cavium makes available under NDA. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r210225 - in head/sys: kern sys
In message: <4c436535.7000...@freebsd.org> Colin Percival writes: : On 07/18/10 13:23, Edward Tomasz Napierala wrote: : > Log: : > The "/*-" comment marker is supposed to denote copyrights. Remove non-copyright : > occurences from sys/sys/ and sys/kern/. : : The "/*-" comment marker indicates to utilities that comments should not be : re-wrapped. Some of the comments you've changed would distinctly suffer if : they were re-wrapped, e.g., : : > -/*- : > +/* : > * Change a process's real uid. : > * Side effects: newcred->cr_ruid will be updated, newcred->cr_ruidinfo : > * will be updated, and the old and new cr_ruidinfo proc : : If you don't want to have "/*-" for these, please change them instead to : "/**", since that is an alternative "box comment" marker. Agreed. I specifically didn't *remove* any of the prior /*- comments when I used that to denote the license... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r210005 - head/sys/modules/acpi/acpi
In message: <201007161514.04955.j...@freebsd.org> Jung-uk Kim writes: : On Thursday 15 July 2010 08:04 am, Bruce Evans wrote: : > On Tue, 13 Jul 2010, Jung-uk Kim wrote: : > > Log: : > > Define SMP unconditionally for amd64 and remove opt_global.h : > > from SRCS. Note it is done just for correctness sake because we : > > do not build, ship, or support acpi.ko on amd64. : > > : > > Prodded by: bde : > : > Thanks. : > : > It was much more interesting than I noticed. Modules are supposed : > to be independent of all configuration options, especially global : > ones, especially especially SMP. Perhaps this is too much to ask : > for acpi. Does it work now, after you removed an SMP ifdef from it? : : I removed "#ifdef SMP" from acpi.c because 'smp_started' is available : for both UP and SMP kernels. On the other hand, I cannot remove : these easily from sys/amd64/acpica/acpi_wakeup.c, i.e., it requires : some symbols from sys/amd64/amd64/mp_machdep.c, which are only : available in SMP case. : : FYI, we never had to worry about acpi.ko on i386 because we didn't : implement suspend/resume for SMP case in the first place. X-) Does this mean we do implement it on amd64 now? I may have to start trying to use it again... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r210054 - in head/sys: conf kern x86/x86
In message: <201007141241.36772@freebsd.org> John Baldwin writes: : On Wednesday, July 14, 2010 11:59:46 am Alexander Motin wrote: : > John Baldwin wrote: : > > On Wednesday, July 14, 2010 9:31:27 am Alexander Motin wrote: : > >> Author: mav : > >> Date: Wed Jul 14 13:31:27 2010 : > >> New Revision: 210054 : > >> URL: http://svn.freebsd.org/changeset/base/210054 : > >> : > >> Log: : > >> Move timeevents.c to MI code, as it is not x86-specific. I already have : > >> it working on Marvell ARM SoCs, and it would be nice to unify timer : code : > >> between more platforms. : > >> : > >> Added: : > >> head/sys/kern/timeevents.c : > >> - copied unchanged from r210053, head/sys/x86/x86/timeevents.c : > >> Deleted: : > >> head/sys/x86/x86/timeevents.c : > >> Modified: : > >> head/sys/conf/files.amd64 : > >> head/sys/conf/files.i386 : > >> head/sys/conf/files.pc98 : > > : > > Can this be merged with kern_et.c, : > : > They are different. kern_et.c provides event timer drivers API, : > timeevents.c consumes it to manage kernel clocks. kern_et.c : > theoretically can be used without timeevents.c if some other code : > consume timers, for example, exposing them to user-level. : > : > May be names indeed cryptic a bit, but I had no better ideas. : > : > > or perhaps called subr_eventtimers.c instead? : > : > Whatever you like, but why exactly so and why "subr_" important? : : The vast majority of files in sys/kern use some sort of prefix, either sys_*, : kern_*, subr_*, etc. subr_ was just a suggestion to avoid clashing with : kern_et.c. If timeevents.c is specific to clocks then maybe it should have : 'clock' in its name somehow? Right now having kern_et == kern_eventtimer.c : and timeevents.c is a bit ambiguous. Somehow making it clear that : timeevents.c is for clocks might help. Also, subr_ prefix helps prevent collisions in other parts of the tree for files with the same name. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r209832 - head/usr.sbin/sysinstall
In message: Doug Barton writes: : On Thu, 8 Jul 2010, Randi Harper wrote: : : > On Thu, Jul 8, 2010 at 2:28 PM, Gabor Kovesdan : > wrote: : >> Em 2010.07.08. 23:26, Randi Harper escreveu: : >>> : >>> Author: randi : >>> Date: Thu Jul 8 21:26:26 2010 : >>> New Revision: 209832 : >>> URL: http://svn.freebsd.org/changeset/base/209832 : >>> : >>> Log: : >>> Revert r209787 pending further discussion. : >>> : >>> Approved by: cperciva (mentor) : >>> : >> : >> Thanks! As I mentioned on IRC, I'll also try to improve this feature, : >> I'm : >> just very busy with other projects at the moment. : : Unfortunately the road to the current sysinstall hell was paved with : just such good intentions. My suggestion is that we all get out of the : way of the people who are, actually, DOING the work. :) For this specific option, however, what harm would there be in leaving well enough alone? Or, failing that, adding "(experts only)" to it? : > As was mentioned on IRC, I think a good stopgap would be to at least : > remove the upgrade option from the main menu. It's not really an : > acceptable form of upgrade, it doesn't do an intelligent merging of : > config files. It would be better placed in the Fixit submenu if we're : > going to be leaving it around for a while and renaming it to something : > like "Mangle My Filesystem". :P : : Sounds like a better option would be to just remove it from the menu : altogether and ifdef 0 the code. That way if $SOMEONE wants to step in : and fix the existing code within a reasonable period of time (6 months : or less?) then they will still have that option, but users won't : suffer in the meantime. In 6 months, I suspect there will be a very different field of play in the installer space. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r209787 - head/usr.sbin/sysinstall
In message: <4c3591f5.2040...@freebsd.org> Colin Percival writes: : On 07/08/10 01:13, Gabor Kovesdan wrote: : > Em 2010.07.08. 5:28, Randi Harper escreveu: : >>Remove the ability to upgrade via sysinstall. [...] : >> : >>Approved by:cperciva (mentor) : >> : > Please revert. It has never been discussed in FreeBSD mailing lists, : > while it is mandatory before such important changes. : : This was discussed on the freebsd-sysinstall list last month: : http://lists.freebsd.org/pipermail/freebsd-sysinstall/2010-June/12.html : : My personal feeling was that since the level of interest in sysinstall from : FreeBSD developers was generally low, this would be sufficient, so I told : randi to go ahead and commit without also adding noise to -arch; but if you : think the freebsd-sysinstall list is insufficient I'll get her to back this : out pending discussion on -arch. freebsd-sysinstall is unlikely to represent more than a tiny sliver of the freebsd community. Talking about ripping out major functionality likely won't get a good sampling of the community there and will tend to produce skewed results. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r209513 - in head: etc/mtree usr.sbin usr.sbin/pc-sysinstall usr.sbin/pc-sysinstall/backend usr.sbin/pc-sysinstall/backend-partmanager usr.sbin/pc-sysinstall/backend-query usr.sbin/pc-
In message: Garrett Cooper writes: : On Thu, Jun 24, 2010 at 3:21 PM, Warner Losh wrote: : > Author: imp : > Date: Thu Jun 24 22:21:47 2010 : > New Revision: 209513 : > URL: http://svn.freebsd.org/changeset/base/209513 : > : > Log: : > Bring in Kris Moore's pc-sysinstall shell script from PC-BSD. This : > shell script is the back end logic necessary for an installer. It : > contains both query routines to allow a front-end installer to present : > reasonable choices to the user and also action routines which allow : > the front end installer to put a FreeBSD distribution onto a disk. It : > supports installing onto the usual suspects, as well as advanced : > features like Mirroring, ZFS, Encryprion and GPT labels. : > : > While this is only the back-end of the installer, it can do unattended : > scripted installations. In PC-BSD's world view, all installations are : > scripted and all the front-end does is write the script. As such, it : > is useful in its own right. : > : > This has been extensively tested over the past several releases of : > PC-BSD. However, differences between that environment and FreeBSD : > suggest there will be a period of shake-out while those differences : > are discovered and corrected. : > : > A text-based front-end is in the works. For the GUI-based front-end, : > you can use the PC-BSD distribution. : > : > Kris' BSDcan paper on pc-sysinstall is linked off his talk on the : > BSDcan site: : > http://www.bsdcan.org/2010/schedule/events/173.en.html : > : > The man page is written by Josh Paetzel, and I wrote the Makefiles for : > the FreeBSD integration. Kris wrote the rest. : > : > This represents version r7010 in the PC-BSD repo. : > http://svn.pcbsd.org/pcbsd/current/pc-sysinstall : > : > Submitted by: kris@ : > Sponsored by: iX Systems : : Maybe now would be a good time to introduce build tunables for : adding/removing pc-sysinstall and/or sysinstall, like pkg_install has? I think that would be somewhat premature. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r209511 - head
In message: <20100624151959.6b00b...@anacreon.physics.wisc.edu> Nathan Whitehorn writes: : On Thu, 24 Jun 2010 17:53:25 + (UTC) : Warner Losh wrote: : : > Author: imp : > Date: Thu Jun 24 17:53:25 2010 : > New Revision: 209511 : > URL: http://svn.freebsd.org/changeset/base/209511 : > : > Log: : > Merge from tbemd: : > : > use MACHINE_CPUARCH instead of MACHINE_CPU since the sources for the : > CSU is based on MACHINE_CPUARCH : > : > Reviewed by: arch@ (twice) : : This is not always true. For example, on powerpc64, the ABI is : different enough between powerpc and powerpc64, which share a CPUARCH, : that the csu code shares very little. I can work around this with : Makefile or preprocessor hacks, of course, but would be it be possible : here instead to check for MACHINE_ARCH before falling back to : MACHINE_CPUARCH? I can do the nested search. It won't break mips or arm, since the mipsel or mipseb variant won't exist... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r209511 - head
In message: <20100624151959.6b00b...@anacreon.physics.wisc.edu>
Nathan Whitehorn writes:
: On Thu, 24 Jun 2010 17:53:25 + (UTC)
: Warner Losh wrote:
:
: > Author: imp
: > Date: Thu Jun 24 17:53:25 2010
: > New Revision: 209511
: > URL: http://svn.freebsd.org/changeset/base/209511
: >
: > Log:
: > Merge from tbemd:
: >
: > use MACHINE_CPUARCH instead of MACHINE_CPU since the sources for the
: > CSU is based on MACHINE_CPUARCH
: >
: > Reviewed by: arch@ (twice)
:
: This is not always true. For example, on powerpc64, the ABI is
: different enough between powerpc and powerpc64, which share a CPUARCH,
: that the csu code shares very little. I can work around this with
: Makefile or preprocessor hacks, of course, but would be it be possible
: here instead to check for MACHINE_ARCH before falling back to
: MACHINE_CPUARCH?
Does this patch do what you are asking?
Warner
Index: mtree.h
===
--- mtree.h (revision 205300)
+++ mtree.h (working copy)
@@ -48,6 +48,11 @@
char*sha1digest;/* SHA-1 digest */
char*sha256digest; /* SHA-256 digest */
char*rmd160digest; /* RIPEMD160 digest */
+ char*sha384digest; /* SHA384 digest */
+ char*sha512digest; /* SHA512 digest */
+ char*tags; /* tags, comma delimited,
+* also with leading and
+* trailing commas */
char*slink; /* symbolic link reference */
uid_t st_uid; /* uid */
gid_t st_gid; /* gid */
Index: spec.c
===
--- spec.c (revision 205300)
+++ spec.c (working copy)
@@ -37,12 +37,14 @@
#include
#include
+#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -51,19 +53,261 @@
int lineno;/* Current spec line number. */
-static void set(char *, NODE *);
-static void unset(char *, NODE *);
+static voidaddchild(NODE *, NODE *);
+static voidreplacenode(NODE *, NODE *);
+static voidset(char *, NODE *);
+static voidunset(char *, NODE *);
+static int nodecmp(const NODE *, const NODE *);
+#define REPLACEPTR(x,v)do { if ((x)) free((x)); (x) = (v); } while (0)
+
+#define mtree_Sflag 0 /* kludge */
+
+static u_int
+nodetoino(u_int type)
+{
+
+ switch (type) {
+ case F_BLOCK:
+ return S_IFBLK;
+ case F_CHAR:
+ return S_IFCHR;
+ case F_DIR:
+ return S_IFDIR;
+ case F_FIFO:
+ return S_IFIFO;
+ case F_FILE:
+ return S_IFREG;
+ case F_LINK:
+ return S_IFLNK;
+#ifdef S_IFSOCK
+ case F_SOCK:
+ return S_IFSOCK;
+#endif
+ default:
+ printf("unknown type %d", type);
+ abort();
+ }
+ /* NOTREACHED */
+}
+
+static const char *
+nodetype(u_int type)
+{
+
+ return (inotype(nodetoino(type)));
+}
+
+static void
+mtree_err(const char *fmt, ...)
+{
+ va_list ap;
+
+ va_start(ap, fmt);
+ vwarnx(fmt, ap);
+ va_end(ap);
+#if 0
+ if (mtree_lineno)
+ warnx("failed at line %lu of the specification",
+ (u_long) mtree_lineno);
+#endif
+ exit(1);
+ /* NOTREACHED */
+}
+
+static void
+replacenode(NODE *cur, NODE *new)
+{
+
+#define REPLACE(x) cur->x = new->x
+#define REPLACESTR(x) REPLACEPTR(cur->x,new->x)
+
+ if (cur->type != new->type) {
+#if 0
+ if (mtree_Mflag) {
+ /*
+* merge entries with different types; we
+* don't want children retained in this case.
+*/
+ REPLACE(type);
+ free_nodes(cur->child);
+ cur->child = NULL;
+ } else {
+#endif
+ mtree_err(
+ "existing entry for `%s', type `%s'"
+ " does not match type `%s'",
+ cur->name, nodetype(cur->type),
+ nodetype(new->type));
+#if 0
+ }
+#endif
+ }
+
+ REPLACE(st_size);
+ REPLACE(st_mtimespec);
+ REPLACESTR(slink);
+ if (cur->slink != NULL) {
+ if ((cur->slink = strdup(new->slink)) == NULL)
+ mtree_err("memory allocation error");
+ if (strunvis(cur->slink, new->slink) == -1)
+ mtree_err("strunvis failed on `%s'", new->slink
Re: svn commit: r209490 - head/sys/kern
In message: <3659e546-80a0-4e82-8112-40b093728...@mac.com>
Marcel Moolenaar writes:
:
: On Jun 23, 2010, at 4:26 PM, Nathan Whitehorn wrote:
:
: > @@ -53,7 +53,7 @@ __FBSDID("$FreeBSD$");
: > */
: >
: > #ifndef HZ
: > -# if defined(__amd64__) || defined(__i386__) || defined(__ia64__) ||
defined(__sparc64__)
: > +# if defined(__amd64__) || defined(__i386__) || defined(__ia64__) ||
defined(__sparc64__) || defined(__powerpc__)
: > #define HZ 1000
: > # else
: > #define HZ 100
:
: Would you mind inverting the #if statement? The common case is
: obviously 1KHz, so listing the exceptions (I belief that's only
: arm and mips) is more effective...
Shouldn't this be defined in some file in ARCH/include instead?
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r209358 - head/cddl/contrib/opensolaris/lib/libdtrace/common
In message: <20100621133340.75017...@kan.dnsalias.net> Alexander Kabaev writes: : DTrace _does_ try to unput EOF though and apparently gets away with it : on Solaris, so while yor version is correct, it is also useless. Then DTrace can't possibly work on ARM. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r209221 - head/bin/sh
In message: <4c1a7953.4080...@freebsd.org> Doug Barton writes: : I've been very supportive of Jilles work up to this point, and I think : he's done a great job of making our sh functional and compliant as a : scripting shell. However in my mind adding completion (and his : suggested inclusion of the kill builtin) tips the balance from "good : system shell" to more of an interactive shell, and that makes me : wonder if this is the right direction to go in. If we want a good : interactive bourne-based shell in the base I'd rather have the : discussion about which one to import, rather than trying to have our : sh catch up with the last 15 years of development in this area. My main objection to sh growing lots of new functionality is the embedded world. It is so much smaller than csh, like 1/3 the size. I'd prefer we keep it small, or at least keep it buildable in the small... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r209129 - head/sys/arm/arm
In message: <20100616210344.47209...@bender>
Andrew Turner writes:
: On Sun, 13 Jun 2010 13:08:23 + (UTC)
: Rafal Jaworowski wrote:
:
: > Author: raj
: > Date: Sun Jun 13 13:08:23 2010
: > New Revision: 209129
: > URL: http://svn.freebsd.org/changeset/base/209129
: >
: > Log:
: > Improve style.
: >
: > Modified:
: > head/sys/arm/arm/nexus.c
: >
: > Modified: head/sys/arm/arm/nexus.c
: >
==
: > --- head/sys/arm/arm/nexus.cSun Jun 13 13:02:43 2010
: > (r209128) +++ head/sys/arm/arm/nexus.c Sun Jun 13 13:08:23
: > 2010(r209129) @@ -107,6 +107,7 @@ static devclass_t
: > nexus_devclass; static int
: > nexus_probe(device_t dev)
: > {
: > +
: > device_quiet(dev); /* suppress attach message for
: > neatness */
: > mem_rman.rm_start = 0;
: > @@ -116,7 +117,7 @@ nexus_probe(device_t dev)
: > if (rman_init(&mem_rman) || rman_manage_region(&mem_rman, 0,
: > ~0u)) panic("nexus_probe mem_rman");
: >
: > - return (0);
: > + return (BUS_PROBE_DEFAULT);
: Changing the return value of nexus_probe from 0 to BUS_PROBE_DEFAULT
: causes the following panic for me when the s3c24x0 driver calls
: rman_init. The attached patch fixes it by moving the call to rman_init
: from nexus_probe to nexus_attach.
The reason is that softc is reset between probe/attach when a number
that isn't 0 is returned, but doesn't when 0 is returned.
Warner
: Andrew
:
: KDB: debugger backends: ddb
: KDB: current backend: ddb
: Copyright (c) 1992-2010 The FreeBSD Project.
: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
: The Regents of the University of California. All rights
: reserved. FreeBSD is a registered trademark of The FreeBSD Foundation.
: FreeBSD 9.0-CURRENT #10 r209128M: Wed Jun 16 20:47:22 NZST 2010
: and...@bender:/usr/obj/arm/home/andrew/freebsd/svn/head/sys/LN2410SBC
: arm WARNING: WITNESS option enabled, expect reduced performance.
: CPU: ARM920T rev 0 (ARM9TDMI core)
: DC enabled IC enabled WB enabled LABT
: 16KB/32B 64-way Instruction cache
: 16KB/32B 64-way write-back-locking-A Data cache
: real memory = 67108864 (64 MB)
: avail memory = 5632 (53 MB)
: s3c24x00 on motherboard
: s3c24x00: Found S3C2410A CPU (Chip ID: 0x32410002)
: s3c24x00: fclk 202 MHz hclk 101 MHz pclk 50 MHz
: panic: Bad tailq NEXT(0xc068eab8->tqh_last) != NULL
: KDB: enter: panic
: [ thread pid 0 tid 10 ]
: Stopped at kdb_enter+0x44: ldrbr15, [r15, r15, ror r15]!
: db> reset
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r208964 - in head: . etc/mtree lib share/mk usr.bin
In message:
Rafal Jaworowski writes:
:
: On 2010-06-10, at 17:25, M. Warner Losh wrote:
:
: > In message: <201006091957.o59jvkbu025...@svn.freebsd.org>
: >Roman Divacky writes:
: > : Modified: head/share/mk/bsd.own.mk
: > :
==
: > : --- head/share/mk/bsd.own.mk Wed Jun 9 19:32:20 2010
(r208963)
: > : +++ head/share/mk/bsd.own.mk Wed Jun 9 19:57:20 2010
(r208964)
: > : @@ -288,6 +288,18 @@ _no_fdt= FDT
: > : .endif
: > :
: > : #
: > : +# Default behaviour of MK_CLANG depends on the architecture.
: > : +#
: > : +.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386" || \
: > : +${MACHINE_ARCH} == "powerpc"
: > : +_clang_yes=CLANG
: > : +_clang_no=
: > : +.else
: > : +_clang_yes=
: > : +_clang_no=CLANG
: > : +.endif
: >
: > We really should *NOT* be encoding architecture stuff like this into
: > bsd.own.mk. Sometimes the right thing here is MACHINE_ARCH, and for
: > the moment, since clang is not a bootstrap tool, this is correct.
: > However, once clang is a bootstrap tool, this will be incorrect
: > because during the bootstrapping for cross building TARGET_ARCH is
: > what should be tested. We have the same problem with the FTD stuff
: > that was recently committed. raj@ and I have been talking about the
: > best ways to fix it.
:
: I think I'm going to drop setting WITH_FDT by default for selected
: arches until the tdbemd arrives, and for this little (I hope :-)
: while it will just be required for FDT-enabled platforms to specify
: WITH_FDT explicitly.
Yes. I think that the current WITH/WITHOUT system works well for
things that are optional, like sendmail or lpt. I think it doesn't
work well to specify intrinsic characteristics about a platform.
That's why we're having the problems with FDT and CLANG. They are
trying to specify a property of a platform by turning an optional
component on or off. We've traditionally not done that, but instead
have controlled this via Makefile ifdefs. I'm transitioning the
latter to provide better separation
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r208964 - in head: . etc/mtree lib share/mk usr.bin
In message: <201006091957.o59jvkbu025...@svn.freebsd.org>
Roman Divacky writes:
: Modified: head/share/mk/bsd.own.mk
: ==
: --- head/share/mk/bsd.own.mk Wed Jun 9 19:32:20 2010(r208963)
: +++ head/share/mk/bsd.own.mk Wed Jun 9 19:57:20 2010(r208964)
: @@ -288,6 +288,18 @@ _no_fdt= FDT
: .endif
:
: #
: +# Default behaviour of MK_CLANG depends on the architecture.
: +#
: +.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386" || \
: +${MACHINE_ARCH} == "powerpc"
: +_clang_yes=CLANG
: +_clang_no=
: +.else
: +_clang_yes=
: +_clang_no=CLANG
: +.endif
We really should *NOT* be encoding architecture stuff like this into
bsd.own.mk. Sometimes the right thing here is MACHINE_ARCH, and for
the moment, since clang is not a bootstrap tool, this is correct.
However, once clang is a bootstrap tool, this will be incorrect
because during the bootstrapping for cross building TARGET_ARCH is
what should be tested. We have the same problem with the FTD stuff
that was recently committed. raj@ and I have been talking about the
best ways to fix it.
I'm merging my tbemd code in the next few days/weeks and hope to start
to address this problem. It already starts to address the insanity we
have in the Makefile.incs.
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r208921 - in head/sys: amd64/amd64 conf i386/i386 x86/x86
In message: <201006090803.21947@freebsd.org>
John Baldwin writes:
: On Tuesday 08 June 2010 6:39:30 pm M. Warner Losh wrote:
: > In message: <201006081725.24684@freebsd.org>
: > John Baldwin writes:
: > : On Tuesday 08 June 2010 3:22:10 pm M. Warner Losh wrote:
: > : > In message: <201006081446.09423@freebsd.org>
: > : > John Baldwin writes:
: > : > : On Tuesday 08 June 2010 2:04:07 pm John Baldwin wrote:
: > : > : > Author: jhb
: > : > : > Date: Tue Jun 8 18:04:07 2010
: > : > : > New Revision: 208921
: > : > : > URL: http://svn.freebsd.org/changeset/base/208921
: > : > : >
: > : > : > Log:
: > : > : > Move the machine check support code to the x86 tree since it is
: > : identical
: > : > : > on i386 and amd64.
: > : > : >
: > : > : > Requested by: alc
: > : > :
: > : > : It would be nice to consolidate as that is identical
on
: > : both
: > : > : platforms, but that moving to x86/include is trickier as the header
needs
: > : to
: > : > : be available in userland, probably as still.
: > : > : would work ok (i.e. in /usr/include/x86/mca.h), but that makes things
: > : trickier
: > : > : in the kernel as the file should really live in sys/x86/include, not
: > : sys/x86
: > : > : directly.
: > : > :
: > : > : I'm open to suggestions on if this is feasible and if so how to do it.
: > : >
: > : > I believe we had a long talk about this before.
: > : >
: > : > copy the current {i386,amd64}/mca.h to x86/mca.h
: > : > new {i386,amd64}/mca.h == #include (no copyright notice,
etc)
: > : >
: > : > just like we do for the pc98 stuff. The mca.h file would live in
: > : > sys/x86/include.
: > :
: > : How does this work for the kernel? doesn't map to
: > : sys/x86/include/mca.h.
: >
: > You still include macine/mca.h inside the kernel, except for mca.c
: > itself. You shouldn't short-circuit things because you know an
: > implementation detail.
:
: I was asking how the actual contents would work since it
: would #include which only works if you have some sort of x86
: symlink. :)
Yes. You've surmised how this is going to work.
: > : For machine we make a symlink that points to
: > : sys//include. Are you proposing an x86 symlink in the kernel
build
: > : directory that for i386, pc98, and amd64 that points to sys/x86/include?
: >
: > Yes.
: >
: > : Ah, looks like you are. This is handled by _ILINKS in kern.post.mk
currently.
: > : If you will fix all the glue magic so #include works in
kernel and
: > : userland I have several headers I can move (apicreg.h, mca.h, etc.).
: >
: > I believe this is correct...
: >
: > But a lot of it is dependent on the merge of tbemd branch, which is
: > still at least a week away. Can you wait that long?
:
: Yes, I can wait for quite a while.
cool.
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r208921 - in head/sys: amd64/amd64 conf i386/i386 x86/x86
In message: <201006081725.24684@freebsd.org>
John Baldwin writes:
: On Tuesday 08 June 2010 3:22:10 pm M. Warner Losh wrote:
: > In message: <201006081446.09423@freebsd.org>
: > John Baldwin writes:
: > : On Tuesday 08 June 2010 2:04:07 pm John Baldwin wrote:
: > : > Author: jhb
: > : > Date: Tue Jun 8 18:04:07 2010
: > : > New Revision: 208921
: > : > URL: http://svn.freebsd.org/changeset/base/208921
: > : >
: > : > Log:
: > : > Move the machine check support code to the x86 tree since it is
: identical
: > : > on i386 and amd64.
: > : >
: > : > Requested by: alc
: > :
: > : It would be nice to consolidate as that is identical on
: both
: > : platforms, but that moving to x86/include is trickier as the header needs
: to
: > : be available in userland, probably as still.
: > : would work ok (i.e. in /usr/include/x86/mca.h), but that makes things
: trickier
: > : in the kernel as the file should really live in sys/x86/include, not
: sys/x86
: > : directly.
: > :
: > : I'm open to suggestions on if this is feasible and if so how to do it.
: >
: > I believe we had a long talk about this before.
: >
: > copy the current {i386,amd64}/mca.h to x86/mca.h
: > new {i386,amd64}/mca.h == #include (no copyright notice, etc)
: >
: > just like we do for the pc98 stuff. The mca.h file would live in
: > sys/x86/include.
:
: How does this work for the kernel? doesn't map to
: sys/x86/include/mca.h.
You still include macine/mca.h inside the kernel, except for mca.c
itself. You shouldn't short-circuit things because you know an
implementation detail.
: For machine we make a symlink that points to
: sys//include. Are you proposing an x86 symlink in the kernel build
: directory that for i386, pc98, and amd64 that points to sys/x86/include?
Yes.
: Ah, looks like you are. This is handled by _ILINKS in kern.post.mk currently.
: If you will fix all the glue magic so #include works in kernel
and
: userland I have several headers I can move (apicreg.h, mca.h, etc.).
I believe this is correct...
But a lot of it is dependent on the merge of tbemd branch, which is
still at least a week away. Can you wait that long?
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r208921 - in head/sys: amd64/amd64 conf i386/i386 x86/x86
In message: <201006081446.09423@freebsd.org>
John Baldwin writes:
: On Tuesday 08 June 2010 2:04:07 pm John Baldwin wrote:
: > Author: jhb
: > Date: Tue Jun 8 18:04:07 2010
: > New Revision: 208921
: > URL: http://svn.freebsd.org/changeset/base/208921
: >
: > Log:
: > Move the machine check support code to the x86 tree since it is identical
: > on i386 and amd64.
: >
: > Requested by: alc
:
: It would be nice to consolidate as that is identical on both
: platforms, but that moving to x86/include is trickier as the header needs to
: be available in userland, probably as still.
: would work ok (i.e. in /usr/include/x86/mca.h), but that makes things
trickier
: in the kernel as the file should really live in sys/x86/include, not sys/x86
: directly.
:
: I'm open to suggestions on if this is feasible and if so how to do it.
I believe we had a long talk about this before.
copy the current {i386,amd64}/mca.h to x86/mca.h
new {i386,amd64}/mca.h == #include (no copyright notice, etc)
just like we do for the pc98 stuff. The mca.h file would live in
sys/x86/include.
That was the consensus of the conversation at the time. There's some
support for this already in the tree for pc98 vs i386 stuff. There's
work in flight for mips and powerpc that do similar things for the
64-bit versions (the mips stuff is on the drawing board, the powerpc
stuff is in nathanw's branch). Plus this dove-tails into the
MACHINE_CPUARCH stuff I've worked on with the tbemd branch that's
headed into head as soon as the mips merge is sorted out.
In src/include/Makefile we have:
.if defined(_MARCH)
${INSTALL} -d -o ${BINOWN} -g ${BINGRP} -m 755 \
${DESTDIR}${INCLUDEDIR}/${_MARCH}; \
cd ${.CURDIR}/../sys/${_MARCH}/include; \
${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 *.h \
${DESTDIR}${INCLUDEDIR}/${_MARCH}
.if exists(${.CURDIR}/../sys/${_MARCH}/include/pc)
${INSTALL} -d -o ${BINOWN} -g ${BINGRP} -m 755 \
${DESTDIR}${INCLUDEDIR}/${_MARCH}/pc; \
cd ${.CURDIR}/../sys/${_MARCH}/include/pc; \
${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 *.h \
${DESTDIR}${INCLUDEDIR}/${_MARCH}/pc
.endif
.endif
we could add
.if defined(_MCARCH)
${INSTALL} -d -o ${BINOWN} -g ${BINGRP} -m 755 \
${DESTDIR}${INCLUDEDIR}/${_MCARCH}; \
cd ${.CURDIR}/../sys/${_MARCH}/include; \
${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 *.h \
${DESTDIR}${INCLUDEDIR}/${_MCARCH}
.endif
just after it, plus a few touch-ups elsewhere in the file (like
defining _MCARCH if MACHINE_CPUARCH != MACHINE_ARCH).
And just to recap, MACHINE_ARCH is the binary architecture that's
being built. MACHINE_CPUARCH is where the source for a group of
related MACHINE_ARCH live. MACHINE_CPUARCH is mips for all mips
platforms, but MACHINE_ARCH is mipsel or mipseb (and maybe mips64el
and mips64eb) for those platforms. To apply this pattern to intel,
MACHINE_ARCH={i386,amd64} and MACHINE_CPUARCH=x86.
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r208737 - in head: contrib/binutils/bfd contrib/binutils/gas/config contrib/binutils/include/elf contrib/binutils/include/opcode contrib/binutils/opcodes contrib/gcc/config contrib/gcc
In message: Juli Mallett writes: : On Wed, Jun 2, 2010 at 05:42, John Baldwin wrote: : > On Wednesday 02 June 2010 7:06:03 am Juli Mallett wrote: : >> o) Fix our GCC spec to define __mips64 for 64-bit targets, not __mips64__, the : >> former being what libgcc, etc., check and the latter seemingly being a : >> misspelling of a hand merge from a Linux spec. : > : > I wonder if it would be useful to define both? The macros we check for : > architecture-specific code for other architectures all have both leading and : > trailing underscores (e.g. __i386__, __amd64__, etc.). Being able to use : > __mips64__ instead of __mips64 for that in kernel sources, etc. would be : > more consistent. : : __mips64 is a mistake and adding __mips64__ and using it would be a : bigger one, I think, since it's kind of confusing and not actually : useful enough to use consistently. MIPS64 is the name of a particular : ISA, but not all 64-bit ISAs (indeed, the earliest 64-bit ISA is : MIPS-III) are derived from it. __mips64 implies a 64-bit ABI, but : there isn't a clean split between non-__mips64 ABIs and __mips64 ABIs : such that those are the only two things you'd ever need to check for. : We intend to support the n32 ABI in userland, which has 64-bit : registers. Conditionals related to that kind of thing would become : (__mips64__ || __mips_n32). I think it makes more sense to be : consistent and use macros related to specific ABIs, macros related to : specific ISAs and sometimes the macros related to the length of long : and the size of a pointer, since there are some ABIs that we might : support (o64) which can support strange combinations of those. What Juli said and __mips64 is neither an architecture nor a machine. All the other examples you gave are architectures. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r208545 - in head/release: amd64 i386 ia64 pc98 powerpc sparc64 sun4v
In message: Garrett Cooper writes: : On Wed, May 26, 2010 at 11:28 AM, Rob Farmer wrote: : > On Tue, May 25, 2010 at 10:48 AM, Xin LI wrote: : >> Author: delphij : >> Date: Tue May 25 17:48:17 2010 : >> New Revision: 208545 : >> URL: http://svn.freebsd.org/changeset/base/208545 : >> : >> Log: : >> libarchive now needs libcrypto and liblzma. : >> : >> Modified: : >> head/release/amd64/boot_crunch.conf : >> head/release/i386/boot_crunch.conf : >> head/release/ia64/boot_crunch.conf : >> head/release/pc98/boot_crunch.conf : >> head/release/powerpc/boot_crunch.conf : >> head/release/sparc64/boot_crunch.conf : >> head/release/sun4v/boot_crunch.conf : >> : >> Modified: head/release/amd64/boot_crunch.conf : >> == : >> --- head/release/amd64/boot_crunch.conf Tue May 25 17:43:23 2010 (r208544) : >> +++ head/release/amd64/boot_crunch.conf Tue May 25 17:48:17 2010 (r208545) : >> @@ -39,6 +39,6 @@ progs ppp : >> progs sysinstall : >> progs usbconfig : >> : >> -libs -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph : >> +libs -ll -ledit -lutil -lmd -lcrypt -lcrypto -lftpio -lz -lnetgraph : >> libs -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -ldevinfo : >> -libs -lbsdxml -larchive -lbz2 -lusb -ljail : >> +libs -lbsdxml -larchive -lbz2 -llzma -lusb -ljail : >> : > : > Does the order of the libs entries matter? Because I just tried on : > i386 after this commit and I still get errors related to the sha1, : > md5, etc. functions but it worked fine with -llzma -lcrypto at the end : > of the last line. : : In theory it shouldn't because the linker should be smart enough : to evaluate the dependencies and link everything properly, but our : copy of binutils isn't intelligent enough to determine the appropriate : order from what I've seen. the linker has never been that smart. Unless you tell it to link in everything, which we don't do. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r208537 - in head: share/mk tools/build/options
In message: <201005251512.o4pfclwl058...@svn.freebsd.org>
Rafal Jaworowski writes:
: +# Enable FDT by default for selected platforms.
: +.if defined(TARGET_ARCH) && \
: + (${TARGET_ARCH} == "arm" || ${TARGET_ARCH} == "powerpc")
: +# XXX this is temporarily disabled until all FDT support code is in place.
: +#_fdt= FDT
: +_no_fdt= FDT
: +.else
: +_no_fdt= FDT
: +.endif
The tests here should be:
.if ${MACHINE_ARCH} == "arm" || ${MACHINE_ARCH} == "powerpc"
Never test against TARGET_* in our Makefile system (except that
binutils, gcc and gdb all use this for piecewise compile)...
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r208183 - in head/sys: conf modules/mvs
In message: <4bf8d0fe.4060...@freebsd.org> Alexander Motin writes: : M. Warner Losh wrote: : > In message: <201005170351.o4h3pvug006...@svn.freebsd.org> : > Alexander Motin writes: : > : Author: mav : > : Date: Mon May 17 03:51:57 2010 : > : New Revision: 208183 : > : URL: http://svn.freebsd.org/changeset/base/208183 : > : : > : Log: : > : Make mvs_if.c to not be always linked statically into the kernel. : > : Link it same way as mvs.c. : > : > A consequence of this will be that if you kldload modules that use the : > mvs_if.m services, but don't have the mvs.ko module, then you'll have : > problems. I ran into this with pccard/pcic/pccbb/cardbus/*pccard.c : > drivers so I compiled pccard_if.m into the kernel statically. : > : > I don't know if that's a big deal for you, but it is why things like : > this are usually linked in statically. : : Not a big deal for now, until mvs_if.m used only inside mvs.ko itself : for PCI devices or statically linked kernel for PCI/SoC. Controller : driver is useless without channel driver, so probably it could be : declared as dependency, if sometimes needed. : : I just thought it is a bit dirty to have it in a kernel when all code : loaded as module. In that case, that should be fine. Just wanted to warn about the potential problem... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r208183 - in head/sys: conf modules/mvs
In message: <201005170351.o4h3pvug006...@svn.freebsd.org>
Alexander Motin writes:
: Author: mav
: Date: Mon May 17 03:51:57 2010
: New Revision: 208183
: URL: http://svn.freebsd.org/changeset/base/208183
:
: Log:
: Make mvs_if.c to not be always linked statically into the kernel.
: Link it same way as mvs.c.
A consequence of this will be that if you kldload modules that use the
mvs_if.m services, but don't have the mvs.ko module, then you'll have
problems. I ran into this with pccard/pcic/pccbb/cardbus/*pccard.c
drivers so I compiled pccard_if.m into the kernel statically.
I don't know if that's a big deal for you, but it is why things like
this are usually linked in statically.
Warner
: Modified:
: head/sys/conf/files
: head/sys/modules/mvs/Makefile
:
: Modified: head/sys/conf/files
: ==
: --- head/sys/conf/files Mon May 17 02:44:51 2010(r208182)
: +++ head/sys/conf/files Mon May 17 03:51:57 2010(r208183)
: @@ -1294,7 +1294,7 @@ dev/mpt/mpt_raid.c optional mpt
: dev/mpt/mpt_user.c optional mpt
: dev/msk/if_msk.c optional msk inet
: dev/mvs/mvs.coptional mvs
: -dev/mvs/mvs_if.m standard
: +dev/mvs/mvs_if.m optional mvs
: dev/mvs/mvs_pci.coptional mvs pci
: dev/mwl/if_mwl.c optional mwl
: dev/mwl/if_mwl_pci.c optional mwl pci
:
: Modified: head/sys/modules/mvs/Makefile
: ==
: --- head/sys/modules/mvs/Makefile Mon May 17 02:44:51 2010
(r208182)
: +++ head/sys/modules/mvs/Makefile Mon May 17 03:51:57 2010
(r208183)
: @@ -3,7 +3,7 @@
: .PATH: ${.CURDIR}/../../dev/mvs
:
: KMOD=mvs
: -SRCS=mvs.c mvs_pci.c mvs.h mvs_if.h device_if.h bus_if.h pci_if.h
opt_cam.h
: +SRCS=mvs.c mvs_pci.c mvs.h mvs_if.c mvs_if.h device_if.h bus_if.h
pci_if.h opt_cam.h
:
: MFILES= kern/bus_if.m kern/device_if.m dev/pci/pci_if.m dev/mvs/mvs_if.m
:
:
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r208075 - in head/usr.sbin/apmd: . contrib
: Modified: head/usr.sbin/apmd/apmd.c : - execl(_PATH_BSHELL, "sh", "-c", p->line, (char *)NULL); : + execl(_PATH_BSHELL, "sh", "-c", p->line, NULL); This looks like a regression to me. Since execl is varadic, you do need this cast... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r207643 - in head: sys/dev/cxgb usr.sbin/cxgbtool
In message: <20100505193049.cd94c63e.n...@freebsd.org> Norikatsu Shigemura writes: : Hi np! : : On Wed, 5 May 2010 00:41:40 + (UTC) : Navdeep Parhar wrote: : > Add support for hardware filters to cxgb(4). The T3 chip can inspect : > L2/3/4 headers and can drop or steer packets as instructed. Filtering : > based on src ip, dst ip, src port, dst port, 802.1q, udp/tcp, and mac : > addr is possible. Add support in cxgbtool to program these filters. : : Great news. Do you have any schedule to implement ipfw(4) : hardware acceleration? :-) There's some embedded kit that has switches that can do limited filtering as well, and there it would be a big win Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r207472 - in head/sys: conf dev/ath/ath_hal/ar5212
In message: <9624cc6a-eeb1-4492-9e62-7acd0bf6f...@gsoft.com.au>
"Daniel O'Connor" writes:
:
: On 02/05/2010, at 2:06 AM, Warner Losh wrote:
: > Unfortunately, this condition is impossible to detect at runtime
: > without MIPS specific ifdefs. Rather than cast an overly-broad net
: > like Linux/OpenWRT dues (which enables this workaround all the time on
: > MIPS32 platforms), we put this option in the kernel for just the
: > affected machines. Sam didn't like this aspect of the patch when he
: > reviewed it, and I'd love to hear sane proposals on how to fix it :)
:
: Could you do TUNABLE_INT in the MIPS code and TUNABLE_INT_FETCH in ath_hal?
How is that better than a kernel option? The only place this would
ever happen is atheros AR71xx SoC. It isn't like some of the Atheros
71xx SoCs would have it and some wouldn't.
And besides, kenv has to be compiled into the kernel on MIPS these
days...
The only thing close to an idea I've had is to add:
__weak int
ath_needs_dma_war()
{
return 0;
}
and have this in the mips:
int needs_ath_dma_war = 0;
__weak int ath_needs_dma_war()
{
return needs_ath_dma_war;
}
and set it to 1 in the AR71xx CPU initialization. But that seemed
kind of lame...
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r206782 - stable/8/sys/conf
In message: <6fd1c0ab-aeff-4089-b549-266e73093...@gmail.com> Nikolay Denev writes: : On 19 Apr, 2010, at 20:45 , M. Warner Losh wrote: : : > In message: <677ad4c7-275f-40b3-821c-b23497950...@gmail.com> : >Nikolay Denev writes: : > : : > : On Apr 19, 2010, at 1:08 PM, Warner Losh wrote: : > : : > : > Nikolay : > : > : > : > Did you do a buildworld after updating the sources before the buildkernel? : > : > : > : > : > : > Warner : > : > : > : > : > : : > : : > : Hmm, no... I tried first to build the kernel. : > : > OK. Can you try a buildworld (or at least kernel-toolchain) before : > building the kernel? : > : > Warner : : Yep, the kernel was built OK after the buildworld. OK. Sounds like I need to add a version check on the config stuff then to make it clearer you need to do this. thanks. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r206782 - stable/8/sys/conf
In message: <677ad4c7-275f-40b3-821c-b23497950...@gmail.com> Nikolay Denev writes: : : On Apr 19, 2010, at 1:08 PM, Warner Losh wrote: : : > Nikolay : > : > Did you do a buildworld after updating the sources before the buildkernel? : > : > : > Warner : > : > : : : Hmm, no... I tried first to build the kernel. OK. Can you try a buildworld (or at least kernel-toolchain) before building the kernel? Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r206082 - in head: . share/man/man7 share/mk sys/conf
In message: <20100409092721.19743kgds231h...@webmail.leidinger.net>
Alexander Leidinger writes:
: Quoting "M. Warner Losh" (from Thu, 08 Apr 2010
: 15:12:13 -0600 (MDT)):
:
: > In message: <20100407100015.117169nw2iu6x...@webmail.leidinger.net>
: > Alexander Leidinger writes:
: > : Quoting "M. Warner Losh" (from Tue, 06 Apr 2010
: > : 10:54:17 -0600 (MDT)):
: > :
: > : > In message:
: > <20100405181450.13494itjj2ehj...@webmail.leidinger.net>
: > : > Alexander Leidinger writes:
: > : > : Warner, do you mind if I back-out r206082 and change the place
: > where
: > : > : NORMAL_CTFCONVERT is used instead (fist I have to search for it
: > : > : again... not today)? It would make it consistent with all other
: > : > places
: > : > : (SYSTEM_CTFCONVERT and the plain test and use of CTFxxx).
: > : >
: > : > Go ahead. I just did the fast and dirty fix. I though it was
: > : > consistent with how other things were done, but if not, feel free
: > to
: > : > correct it. Also, see bde's commentary :)
: > :
: > : I can not find it, can you please forward it to me?
: >
: > Will do.
: >
: > : Here is what I have ATM (copy&paste, so tabs are probably mangled):
: > : ---snip---
: > : Index: usr.sbin/config/mkmakefile.c
: > : ===
: > : --- usr.sbin/config/mkmakefile.c(revision 206031)
: > : +++ usr.sbin/config/mkmakefile.c(working copy)
: > : @@ -741,7 +741,7 @@
: > : printf("config: don't know rules for %s\n",
: > : np); break;
: > : }
: > : - snprintf(cmd, sizeof(cmd), "${%s_%c%s}\n.if
: > : - defined(NORMAL_CTFCONVERT) &&
: > : - !empty(NORMAL_CTFCONVERT)\n\t${NORMAL_CTFCONVERT}\n.endif",
: > : - ftype,
: > : + snprintf(cmd, sizeof(cmd), "${%s_%c%s}\...@${normal_ctfconvert}",
: > : ftype,
: > : toupper(och),
: > : ftp->f_flags & NOWERROR ? "_NOWERROR" : "");
: > : compilewith = cmd;
: >
: > Uggg, this should have never been put into mkmakefile.c in the first
: > place. I'm concerned that a change like this will have bad effects
: > for people that have cross-threaded config and kernels. :(
:
: You need to have a look at the complete code, there is more than only
: the use of NORMAL_CTFCONVERT. Regarding the cross-case, I think it can
: be done by overriding NORMAL_CTFCONVERT (if needed).
I have looked at the complete code. config has no business knowing
about these things. It is a layering violation. It must be removed
from config. However, since you didn't put it there, you should do
the next best thing and fix the bug in the current implementation.
: > However, go ahead and fix it. I worry about people with
: > cross-threaded kernels, but that won't be a huge deal, I don't think.
: > Please monitor the lists to make sure...
:
: Do I understand this right, that you think I shall do it before I get
: the forwarded mail?
I think you should commit this fix. I'll forward you bde's mail and
you can work on another fix. In the mean time (after you commit the
patch we're talking about right now), please monitor hackers@ and
current@ for any problems.
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r206082 - in head: . share/man/man7 share/mk sys/conf
In message: <20100407100015.117169nw2iu6x...@webmail.leidinger.net>
Alexander Leidinger writes:
: Quoting "M. Warner Losh" (from Tue, 06 Apr 2010
: 10:54:17 -0600 (MDT)):
:
: > In message: <20100405181450.13494itjj2ehj...@webmail.leidinger.net>
: > Alexander Leidinger writes:
: > : Warner, do you mind if I back-out r206082 and change the place where
: > : NORMAL_CTFCONVERT is used instead (fist I have to search for it
: > : again... not today)? It would make it consistent with all other
: > places
: > : (SYSTEM_CTFCONVERT and the plain test and use of CTFxxx).
: >
: > Go ahead. I just did the fast and dirty fix. I though it was
: > consistent with how other things were done, but if not, feel free to
: > correct it. Also, see bde's commentary :)
:
: I can not find it, can you please forward it to me?
Will do.
: Here is what I have ATM (copy&paste, so tabs are probably mangled):
: ---snip---
: Index: usr.sbin/config/mkmakefile.c
: ===
: --- usr.sbin/config/mkmakefile.c(revision 206031)
: +++ usr.sbin/config/mkmakefile.c(working copy)
: @@ -741,7 +741,7 @@
: printf("config: don't know rules for %s\n",
: np); break;
: }
: - snprintf(cmd, sizeof(cmd), "${%s_%c%s}\n.if
: - defined(NORMAL_CTFCONVERT) &&
: -
!empty(NORMAL_CTFCONVERT)\n\t${NORMAL_CTFCONVERT}\n.endif",
: - ftype,
: + snprintf(cmd, sizeof(cmd), "${%s_%c%s}\...@${normal_ctfconvert}",
: ftype,
: toupper(och),
: ftp->f_flags & NOWERROR ? "_NOWERROR" : "");
: compilewith = cmd;
Uggg, this should have never been put into mkmakefile.c in the first
place. I'm concerned that a change like this will have bad effects
for people that have cross-threaded config and kernels. :(
However, go ahead and fix it. I worry about people with
cross-threaded kernels, but that won't be a huge deal, I don't think.
Please monitor the lists to make sure...
Warner
: Index: sys/conf/kern.pre.mk
: ===
: --- sys/conf/kern.pre.mk(revision 206248)
: +++ sys/conf/kern.pre.mk(working copy)
: @@ -128,7 +128,7 @@
: NORMAL_M= ${AWK} -f $S/tools/makeobjops.awk ${.IMPSRC} -c ; \
: ${CC} -c ${CFLAGS} ${WERROR} ${PROF} ${.PREFIX}.c
:
: -NORMAL_CTFCONVERT= @[ -z "${CTFCONVERT}" -o -n "${NO_CTF}" ] ||
: -${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
: +NORMAL_CTFCONVERT= [ -z "${CTFCONVERT}" -o -n "${NO_CTF}" ] ||
: ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
:
: NORMAL_LINT= ${LINT} ${LINTFLAGS} ${CFLAGS:M-[DIU]*} ${.IMPSRC}
:
: ---snip---
:
: Bye,
: Alexander.
:
: --
: http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
: http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
: Look before you leap.
: -- Samuel Butler
:
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r206082 - in head: . share/man/man7 share/mk sys/conf
In message: <20100405181450.13494itjj2ehj...@webmail.leidinger.net> Alexander Leidinger writes: : Warner, do you mind if I back-out r206082 and change the place where : NORMAL_CTFCONVERT is used instead (fist I have to search for it : again... not today)? It would make it consistent with all other places : (SYSTEM_CTFCONVERT and the plain test and use of CTFxxx). Go ahead. I just did the fast and dirty fix. I though it was consistent with how other things were done, but if not, feel free to correct it. Also, see bde's commentary :) Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r206176 - head/share/examples/indent
In message: Garrett Cooper writes: : On Mon, Apr 5, 2010 at 2:26 AM, Andriy Gapon wrote: : > Author: avg : > Date: Mon Apr 5 09:26:03 2010 : > New Revision: 206176 : > URL: http://svn.freebsd.org/changeset/base/206176 : > : > Log: : > indent.pro example: put all options one per line : > : > This should help with modification tracking. : > : > Discussed with: bde : > MFC after: 7 days : > : > Modified: : > head/share/examples/indent/indent.pro : > : > Modified: head/share/examples/indent/indent.pro : > == : > --- head/share/examples/indent/indent.pro Mon Apr 5 09:24:24 2010 (r206175) : > +++ head/share/examples/indent/indent.pro Mon Apr 5 09:26:03 2010 (r206176) : > @@ -14,5 +14,33 @@ : > -TSTAILQ_ENTRY : > -TSLIST_HEAD : > -TSLIST_ENTRY : > --bad -bap -nbbb -nbc -br -nbs -c41 -cd41 -cdb -ce -ci4 -cli0 -d0 -di8 -ndj : > --ei -nfc1 -nfcb -i8 -ip8 -l79 -lc77 -ldi0 -nlp -npcs -psl -sc -nsob -ta -nv : > +-bad : > +-bap : > +-nbbb : > +-nbc : > +-br : > +-nbs : > +-c41 : > +-cd41 : > +-cdb : > +-ce : > +-ci4 : > +-cli0 : > +-d0 : > +-di8 : > +-ndj : > +-ei : > +-nfc1 : > +-nfcb : > +-i8 : > +-ip8 : > +-l79 : > +-lc77 : > +-ldi0 : > +-nlp : > +-npcs : > +-psl : > +-sc : > +-nsob : > +-ta : > +-nv : : Isn't doing something like this going to make merge collisions : more prevalent? Actually, it will allow merging more easily. If I wanted to add -nld to the list and joe wanted to add -l4d, then those would be on lines by themselves (which makes merging easier) rather than on the same line (which makes merging impossible with today's tools). Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r205845 - head/sys/modules
In message: <20100329181831.ga14...@gypsy> Navdeep Parhar writes: : This commit has unplugged cxgb from the build, even for the : (!arm && !mips) case. Please fix. Doh! Will do ASAP. Thanks! Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r205710 - head/gnu/usr.bin/gdb
In message: <201003261940.o2qjery1041...@svn.freebsd.org>
Marcel Moolenaar writes:
: Author: marcel
: Date: Fri Mar 26 19:40:53 2010
: New Revision: 205710
: URL: http://svn.freebsd.org/changeset/base/205710
:
: Log:
: Handle cross-builds for gdbserver.
Cross-builds outside the normal build system? Otherwise, MACHINE_ARCH
is the right thing to check since TARGET* is only set in the
bootstrapping stages, not the actual build stages.
Warner
: Modified:
: head/gnu/usr.bin/gdb/Makefile
:
: Modified: head/gnu/usr.bin/gdb/Makefile
: ==
: --- head/gnu/usr.bin/gdb/Makefile Fri Mar 26 19:00:17 2010
(r205709)
: +++ head/gnu/usr.bin/gdb/Makefile Fri Mar 26 19:40:53 2010
(r205710)
: @@ -2,7 +2,9 @@
:
: SUBDIR= doc libgdb gdb gdbtui kgdb
:
: -.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "arm" ||
${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "powerpc"
: +TARGET_ARCH?= ${MACHINE_ARCH}
: +.if ${TARGET_ARCH} == "amd64" || ${TARGET_ARCH} == "arm" || \
: +${TARGET_ARCH} == "i386" || ${TARGET_ARCH} == "powerpc"
: SUBDIR+=gdbserver
: .endif
:
:
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r205307 - head/sys/i386/conf
In message: <4ba2f899.8070...@feral.com> Matthew Jacob writes: : Does anyone out there have a 486 DX4 even? Can you boot 8.0 CDs? The soekris boxes have a geode in them, which is a 486. I've run generic on them w/o disabling SSE for ages... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r205307 - head/sys/i386/conf
In message: <20100319114426.go32...@hoeg.nl> Ed Schouten writes: : * Xin LI wrote: : > Log: : > SSE is enabled by default about 5 years ago so there is no point pretending : > that we support I486 and I586 CPUs in the GENERIC kernel, users wants these : > support would have to build a custom kernel to explicitly disable SSE : > anyways. : > : > MFC after:1 month : : Could we please leave i586 here? I agree people should throw their : Pentiums on the scrapyard, but only supporting i686 by default is a bit : too agressive in my opinion. I don't think we should MFC this change at all. Geodes are still fairly popular machines and have 486 cores in them. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r205014 - in head: . sys/amd64/amd64 sys/amd64/conf sys/amd64/include sys/amd64/linux32 sys/compat/freebsd32 sys/compat/ia32 sys/conf sys/fs/procfs sys/ia64/conf sys/ia64/ia64 sys/ia64
In message: <20100317171648.gd7...@hoeg.nl> Ed Schouten writes: : * M. Warner Losh wrote: : > I agree with John this is too fine grained. We don't currently have : > this data for the removals, just when we did. And it isn't clear that : > our users could easily find this data either, even if we : > dumpster-dived the repo for it. : : I do think the same, but maybe in the future we should annotate compat : bits like these in source by specific __FreeBSD_version? Such annotations might be useful. However, most (all?) of them will be in the X00yyy, since we usually only demote code to compat status on -head. Users would likely almost always set this value to X0. Furthermore, you can't pick which of the things removed in release X are omitted arbitrarily, just a point in a list. This suggests, to my mind at least, that we're adding extra complexity in selecting compatibility bits, but not really providing much value add for that complexity. Am I missing something? Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r205014 - in head: . sys/amd64/amd64 sys/amd64/conf sys/amd64/include sys/amd64/linux32 sys/compat/freebsd32 sys/compat/ia32 sys/conf sys/fs/procfs sys/ia64/conf sys/ia64/ia64 sys/ia64
In message: <20100317085004.gb7...@hoeg.nl> Ed Schouten writes: : * M. Warner Losh wrote: : > Under your plan, which __FreeBSD_version would we use here? : : Well, the idea is that it's monotone. The lower you set the value, the : more rubbish you get. I agree with John this is too fine grained. We don't currently have this data for the removals, just when we did. And it isn't clear that our users could easily find this data either, even if we dumpster-dived the repo for it. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r205014 - in head: . sys/amd64/amd64 sys/amd64/conf sys/amd64/include sys/amd64/linux32 sys/compat/freebsd32 sys/compat/ia32 sys/conf sys/fs/procfs sys/ia64/conf sys/ia64/ia64 sys/ia64
In message: <20100313170725.gw8...@hoeg.nl> Ed Schouten writes: : * M. Warner Losh wrote: : > that sounds like a good idea. But it isn't as simple as changing all : > the COMPAT_FREEBSDX in the .c code. There's also hooks in the syscall : > glue generation that would be affected. : : Hmmm... Indeed. : : I thought a bit more about this and I realized it would be better if we : wouldn't use a FreeBSD major number for this, but the actual : __FreeBSD_version. Hmmm, that might be harder. The problem is that when I want to run a program from FreeBSD 3.0, I may need an interface that was in 3.0, but was removed prior to 5.0 shipping. This means the kernel needs the COMPAT_FREEBSD4 option right now to work. So things are kind of confusing. Under your plan, which __FreeBSD_version would we use here? The COMPAT_FREEBSD_BACK_TO=3 would be the right setting here. This may pick up a little extra junk, but would be clear to the user what they are configuring. Comments? Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r205014 - in head: . sys/amd64/amd64 sys/amd64/conf sys/amd64/include sys/amd64/linux32 sys/compat/freebsd32 sys/compat/ia32 sys/conf sys/fs/procfs sys/ia64/conf sys/ia64/ia64 sys/ia64
In message: <20100313090844.gv8...@hoeg.nl> Ed Schouten writes: : * Carlos A. M. dos Santos wrote: : > COMPAT_FREEBSD32 is an unfortunate choice. It can be easily : > interpreted as "compatible with FreeBSD 3.2". : : That's no problem, since COMPAT_FREEBSD%d was already a misnomer. It : would have been a lot better if it were replaced by a numerical : definition: : : options COMPAT_FREEBSD_MAJOR=7 that sounds like a good idea. But it isn't as simple as changing all the COMPAT_FREEBSDX in the .c code. There's also hooks in the syscall glue generation that would be affected. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r205024 - head/sys/net
julian> probably should add a flag that means "we have media state" julian> and if it is not set, assume it is always on. qing> That's a good idea. I will take your approach. I do too. While I have many of the older cards that don't support media detect (because the chips don't report that info), it will take some time to test them all out... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r205024 - head/sys/net
In message: Juli Mallett writes: : On Thu, Mar 11, 2010 at 15:30, Qing Li wrote: : >> : >> A couple of questions: : >> : >> (1) It used to be the case that quite a few interface drivers and types : >> didn't have a notion of "link up" -- especially older ethernet devices. Do : >> those all have the same problem? It was probably a design oversight that : >> devices don't declare an explicit capability for "can report link state". : >> : > : > What you raised is definitely a possibility and these fixes take the : > similar approach. I am going to try and go through each of these : > drivers in /sys/dev/ and converting them, very soon. : : Go through drivers in the embedded port directories, too. The Octeon : port's Ethernet driver was broken by this, and it looks like the : Atheros if_arge is probably broken, too. I would even suggest going : back to the old behavior briefly while the port maintainers are given : an opportunity to update their drivers. Actually, it looks like only : MIPS has Ethernet drivers outside of dev/ at a quick glance, but I'd : be surprised if there weren't other broken examples. arm has them as well. sys/arm/at91/if_ate.c. Powerpc does as well. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r204824 - head/sys/conf
In message: <20100310045345.ge96...@dragon.nuxi.org> "David O'Brien" writes: : On Tue, Mar 09, 2010 at 08:18:25PM -0700, M. Warner Losh wrote: : > In message: <20100310024553.ga13...@dragon.nuxi.org> : > "David O'Brien" writes: : .. : > PLEASE DO NOT CHANGE newvers.sh FROM WHAT IT IS NOW. Please talk : > about your proposed changes in -hackers@ or -current@ first. : : When I wrote that Doug's change had not made it thru my svnsync. : : It wasn't Doug's place to back out my change. Geez, you're acting like : this is making the kernel toxic (like the now route to 127.0.0.1). : : : : PLEASE CLALM DOWN WARNER. I am calm David. I'm asking you to play by the rules. You seemed to be planning another drive-by commit. Doug and I have both asked you to get a review before you make any changes to this file. These are reasonable requests. The standard way we do things in the project. Please respect that this is an area of high contention that's been a problem in the past and that drive-by commits create much consternation and emotional churn in the project. Please respect your fellow committers and get the code reviewed please. Thanks a lot. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r204824 - head/sys/conf
In message: <20100310024553.ga13...@dragon.nuxi.org> "David O'Brien" writes: : : On Sun, Mar 07, 2010 at 06:10:52PM -0800, Doug Barton wrote: : > On 03/07/10 17:01, David O'Brien wrote: : > : > > +*/sys/*|*/compile/*) : > : > Please revert your previous change, and feel free to add this one instead. : : This alone will not work - it doesn't fix the calculation of SRCDIR: : : + v=0 u=root d=/MM/test/my-fbsd-kern/i386/compile/GENERIC h=dragon t='Tue Mar 9 18:42:18 PST 2010' : + make -V KERN_IDENT : + i=GENERIC : + SRCDIR=/MM/test/my-fbsd-kern/i386/compile/GENERIC : + [ -n '' ] : + SRCDIR=/MM/test/my-fbsd-kern/i386/compile/GENERIC : + [ -d /MM/test/my-fbsd-kern/i386/compile/GENERIC/sys/.svn -a -x /bin/svnversion ] : + [ -d /MM/test/my-fbsd-kern/i386/compile/GENERIC/.git -a -x /bin/git ] : : : I will fix newvers.sh tonight. PLEASE DO NOT CHANGE newvers.sh FROM WHAT IT IS NOW. Please talk about your proposed changes in -hackers@ or -current@ first. Thanks a lot. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r204824 - head/sys/conf
In message: <4b97030a.1040...@freebsd.org>
Doug Barton writes:
: On 03/09/10 17:55, David O'Brien wrote:
: > On Sun, Mar 07, 2010 at 06:10:52PM -0800, Doug Barton wrote:
: >> On 03/07/10 17:01, David O'Brien wrote:
: >>> +*/sys/*|*/compile/*)
: >>
: >> Please revert your previous change, and feel free to add this one instead.
: >>
: >> I'm a little aggravated because this question of "what if the directory
: >> isn't named */sys/*?" was already addressed when I made the change, and
: >> the general agreement was that !sys was an edge case that wasn't worth
: >> worrying about.
: >
: > I probably would have if I had been able to update my main system to a
: > kernel newer than Nov 9th. Every time I've tried HEAD is toxic[*].
: > Tried again this morning - "no route to 127.0.0.1".
:
: I'm not sure what the connection is there. But FWIW Qing posted the fix
: for that: http://people.freebsd.org/~qingli/route.h.diff. Not sure why
: he hasn't committed it yet. The fix works for me.
:
: >> I'm even more aggravated that your change doesn't work for the common case.
: >
: > Sorry, I build all my kernels the traditional way. I was agrivated that
: > your change didn't work with the kernel build method with 15 years
: > history...
:
: The "traditional" way hasn't been the recommended method of kernel
: building for years now.
:
: In any case, at least one user has complained on the list that not
: having the svn revision in uname has caused them an actual problem, so I
: backed out your change today. If you'd like to submit a patch for review
: (-current or -hackers are good choices) that ADDS support for
: */compile/* I have no objection, and as long as it doesn't cause any
: problems for people whose sources are in */sys/* I think that'd be
: great, and will do whatever I can to help.
I'd recommend something similar to the following change:
Index: newvers.sh
===
--- newvers.sh (revision 204938)
+++ newvers.sh (working copy)
@@ -38,13 +38,14 @@
fi
RELEASE="${REVISION}-${BRANCH}"
VERSION="${TYPE} ${RELEASE}"
+S=sys
if [ "X${PARAMFILE}" != "X" ]; then
RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \
${PARAMFILE})
else
RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \
- $(dirname $0)/../sys/param.h)
+ $(dirname $0)/../$S/param.h)
fi
@@ -88,15 +89,15 @@
i=`${MAKE:-make} -V KERN_IDENT`
case "$d" in
-*/sys/*)
+*/$S/*)
SRCDIR=${d##*obj}
if [ -n "$MACHINE" ]; then
SRCDIR=${SRCDIR##/$MACHINE}
fi
- SRCDIR=${SRCDIR%%/sys/*}
+ SRCDIR=${SRCDIR%%/$S/*}
for dir in /bin /usr/bin /usr/local/bin; do
- if [ -d "${SRCDIR}/sys/.svn" -a -x "${dir}/svnversion" ] ; then
+ if [ -d "${SRCDIR}/$S/.svn" -a -x "${dir}/svnversion" ] ; then
svnversion=${dir}/svnversion
break
fi
@@ -107,7 +108,7 @@
done
if [ -n "$svnversion" ] ; then
- svn=" r`cd ${SRCDIR}/sys && $svnversion`"
+ svn=" r`cd ${SRCDIR}/$S && $svnversion`"
fi
if [ -n "$git_cmd" ] ; then
git=`$git_cmd rev-parse --verify --short HEAD 2>/dev/null`
which would allow people that move sys to somewhere else to change one
line and still have everything work. They are going to have to make
changes anyway to support that, since it isn't supported by FreeBSD
out of the box.
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r204824 - head/sys/conf
In message: <20100308010125.ga6...@dragon.nuxi.org>
"David O'Brien" writes:
: On Sun, Mar 07, 2010 at 02:36:19PM -0700, M. Warner Losh wrote:
: > Please back out this change. It is unwise, I think.
:
: Instead I'd rather fix it for the use case you mention.
I'd still rather you back it out because it introduces a significant
regression in speed, see below...
: >%>%>%>%>%>%>%>%>%>%>%>%
: Index: newvers.sh
: ===
: --- newvers.sh(revision 204851)
: +++ newvers.sh(working copy)
: @@ -87,13 +87,11 @@ touch version
: v=`cat version` u=${USER:-root} d=`pwd` h=${HOSTNAME:-`hostname`} t=`date`
: i=`${MAKE:-make} -V KERN_IDENT`
:
: +# Are we doing a kernel build? Look for "/sys/" in pwd for 'make kernel',
: +# and "/compile/" for tradiational within-tree kernel build.
: case "$d" in
: -*/compile/*)
: - SRCDIR=${d##*obj}
: - if [ -n "$MACHINE" ]; then
: - SRCDIR=${SRCDIR##/$MACHINE}
: - fi
: - SRCDIR=$(cd ${SRCDIR%%/compile/*}/.. && pwd)
: +*/sys/*|*/compile/*)
: + SRCDIR=$(realpath $(dirname $0)/..)
:
: for dir in /bin /usr/bin /usr/local/bin; do
: if [ -d "${SRCDIR}/.svn" -a -x "${dir}/svnversion" ] ; then
: >%>%>%>%>%>%>%>%>%>%>%>%
:
:
: Do you get the subversion revision in your vers.c file with this patch?
Well, except that you get the revision for the whole tree, instead of
just for the kernel. And this takes a *LOT* longer to compute. The
whole reason we did the sys hack was to make build times not suck...
for dir in /bin /usr/bin /usr/local/bin; do
- if [ -d "${SRCDIR}/sys/.svn" -a -x "${dir}/svnversion" ] ; then
+ if [ -d "${SRCDIR}/.svn" -a -x "${dir}/svnversion" ] ; then
svnversion=${dir}/svnversion
break
fi
@@ -107,7 +107,7 @@ case "$d" in
done
if [ -n "$svnversion" ] ; then
- svn=" r`cd ${SRCDIR}/sys && $svnversion`"
+ svn=" r`cd ${SRCDIR} && $svnversion`"
fi
if [ -n "$git_cmd" ] ; then
git=`$git_cmd rev-parse --verify --short HEAD 2>/dev/null`
Again, like Doug said: "my kernel doesn't live in sys" isn't a problem
that is worth solving at the cost of "I have to run svnversion over
all of /usr/src every time I build a kernel."
Please, back this out. If you *MUST* support != sys, then do so in a
way that doesn't screw everybody else with long build times. And
*PLEASE* talk to people before doing a drive-by commit? This bit of
code has way too much loaded history behind it for just random
tweaking.
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r204850 - head/sys/kern
In message: <201003080921.34274@freebsd.org> John Baldwin writes: : On Sunday 07 March 2010 5:37:35 pm Warner Losh wrote: : > Author: imp : > Date: Sun Mar 7 22:37:35 2010 : > New Revision: 204850 : > URL: http://svn.freebsd.org/changeset/base/204850 : > : > Log: : > Bump up the firmware_table from 30 to 50. bwn needs more than 30, it : > seems. : : Are you sure? The error report I saw was from having firmwares for both : bwi(4) and bwn(4) loaded. Both of them use a lot of firmware images, but I : don't think either one in isolation uses more than 30. You're likely right about that. I know I had been experimenting with both and I had to bump the limit so I could do some A/B testing with bwi/bwn on my cards before the import. : I really think that FIRMWARE_MAX should at the least become a loader tunable : and have the array malloc'd either on-demand or via a SYSINIT(). Completely agreed. Bumping the limit was easy, and the cost to the system is relatively low. If anybody wants to make this more dynamic and/or controllable, go for it. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r204824 - head/sys/conf
In message: <201003071008.o27a80wc014...@svn.freebsd.org>
"David E. O'Brien" writes:
: Author: obrien
: Date: Sun Mar 7 10:08:00 2010
: New Revision: 204824
: URL: http://svn.freebsd.org/changeset/base/204824
:
: Log:
: Look for "compile" to decide if this is run as part of the kernel build.
: The assumption of "${ARCH}/compile/FOO" is much harder to change in our
: build (so assume one hasn't), then assuming every kernel is rooted at
"sys/".
Except buildkernel builds the kernel into
$MAKEOBJDIRPREFIX/$ARCH/$PATH_TO_TOP/sys/FOO ($ARCH/ is omitted when
building natively).
Please back out this change. It is unwise, I think.
Warner
: Modified:
: head/sys/conf/newvers.sh
:
: Modified: head/sys/conf/newvers.sh
: ==
: --- head/sys/conf/newvers.sh Sun Mar 7 09:52:35 2010(r204823)
: +++ head/sys/conf/newvers.sh Sun Mar 7 10:08:00 2010(r204824)
: @@ -88,15 +88,15 @@ v=`cat version` u=${USER:-root} d=`pwd`
: i=`${MAKE:-make} -V KERN_IDENT`
:
: case "$d" in
: -*/sys/*)
: +*/compile/*)
: SRCDIR=${d##*obj}
: if [ -n "$MACHINE" ]; then
: SRCDIR=${SRCDIR##/$MACHINE}
: fi
: - SRCDIR=${SRCDIR%%/sys/*}
: + SRCDIR=$(cd ${SRCDIR%%/compile/*}/.. && pwd)
:
: for dir in /bin /usr/bin /usr/local/bin; do
: - if [ -d "${SRCDIR}/sys/.svn" -a -x "${dir}/svnversion" ] ; then
: + if [ -d "${SRCDIR}/.svn" -a -x "${dir}/svnversion" ] ; then
: svnversion=${dir}/svnversion
: break
: fi
: @@ -107,7 +107,7 @@ case "$d" in
: done
:
: if [ -n "$svnversion" ] ; then
: - svn=" r`cd ${SRCDIR}/sys && $svnversion`"
: + svn=" r`cd ${SRCDIR} && $svnversion`"
: fi
: if [ -n "$git_cmd" ] ; then
: git=`$git_cmd rev-parse --verify --short HEAD 2>/dev/null`
:
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r204738 - head/lib
In message: <4b90532e.2000...@freebsd.org> Doug Barton writes: : On 3/4/2010 2:01 PM, Warner Losh wrote: : > Author: imp : > Date: Thu Mar 4 22:01:11 2010 : > New Revision: 204738 : > URL: http://svn.freebsd.org/changeset/base/204738 : > : > Log: : >Remove stale references to libkrb5. : >Rejigger the SUBDIR setting a smidge: we now set all the libraries : >that depend : >on something else, and then SUBDIR+= the rest. : : > +# Except it appears bind needs to be compiled last : : I'm not arguing, just curious ... how did you come to this conclusion, : and is this a problem that needs to be solved? I could certainly : understand why it might be true, the BIND libs pull in a lot of stuff. Purely by it being built last today, out of alphabetical order. I've not had time to investigate more fully... Since I'll be rearranging things a little for some other work I'm doing, I'll see if I can find out if it is true, and if so what the dependencies are and document them here. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r194266 - head/usr.bin/chpass
In message: Scott Long writes: : On Mar 4, 2010, at 11:53 AM, M. Warner Losh wrote: : > In message: <9a8644ad-3b92-4bce-8a51-132f8ea35...@samsco.org> : >Scott Long writes: : > : On Mar 4, 2010, at 10:53 AM, M. Warner Losh wrote: : > : > : > : > In message: : > : >Scott Long writes: : > : > : Forcing the entire build to fail if chflags fails breaks installing : > : > : to an NFS destination. I haven't tested all possible permutations : > : > : of src vs dest filesystems mounting, but I don't see how it can : > : > : work over any type of NFS mount. What is the reason for forcing : > : > : this failure? The NO_FSCHG variable is undocumented, and the : > : > : failure mode here is pretty useless at helping the user fix the : > : > : problem. I'd like to re-add the '-' modifier to the chflags : > : > : command that you removed. : > : > : > : > NO_FSCHG variable has been around a long time, and is de-facto : > : > supported. It will be documented shortly when I get done cleaning up : > : > build(7). : > : > : > : > NO_FSCHG has been the documented way (in examples) for installing over : > : > NFS for a very long time. It looks to my eye like this change fixed a : > : > problem with that... : > : > : > : > Warner : > : > : > : > : : > : : > : Every other base package that sets schg does so by allowing chflags to silently fail. My change puts chpass back into conformance with the status quo. : > : > Well, maybe for chflags, but not for install. You still need NO_FSCHG : > if you are installing over NFS, with or without this change... : > : : What am I missing by not using it? Just a few minutes ago I did a successful install over NFS on 9-current and 7-stable. Last night it failed for me when installing libraries Part of the problem was that they had been installed with schg when I'd built the tree on the local machine rather than my new remote machine... But it looks like this morning when I tried it to cut-and-paste the error, I can't find it with the -chflags change you made. So it looks like the need for flag for nfs installs has passed... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r194266 - head/usr.bin/chpass
In message: <9a8644ad-3b92-4bce-8a51-132f8ea35...@samsco.org> Scott Long writes: : On Mar 4, 2010, at 10:53 AM, M. Warner Losh wrote: : > : > In message: : >Scott Long writes: : > : Forcing the entire build to fail if chflags fails breaks installing : > : to an NFS destination. I haven't tested all possible permutations : > : of src vs dest filesystems mounting, but I don't see how it can : > : work over any type of NFS mount. What is the reason for forcing : > : this failure? The NO_FSCHG variable is undocumented, and the : > : failure mode here is pretty useless at helping the user fix the : > : problem. I'd like to re-add the '-' modifier to the chflags : > : command that you removed. : > : > NO_FSCHG variable has been around a long time, and is de-facto : > supported. It will be documented shortly when I get done cleaning up : > build(7). : > : > NO_FSCHG has been the documented way (in examples) for installing over : > NFS for a very long time. It looks to my eye like this change fixed a : > problem with that... : > : > Warner : > : > : : : Every other base package that sets schg does so by allowing chflags to silently fail. My change puts chpass back into conformance with the status quo. Well, maybe for chflags, but not for install. You still need NO_FSCHG if you are installing over NFS, with or without this change... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r194266 - head/usr.bin/chpass
In message:
Scott Long writes:
: Forcing the entire build to fail if chflags fails breaks installing
: to an NFS destination. I haven't tested all possible permutations
: of src vs dest filesystems mounting, but I don't see how it can
: work over any type of NFS mount. What is the reason for forcing
: this failure? The NO_FSCHG variable is undocumented, and the
: failure mode here is pretty useless at helping the user fix the
: problem. I'd like to re-add the '-' modifier to the chflags
: command that you removed.
NO_FSCHG variable has been around a long time, and is de-facto
supported. It will be documented shortly when I get done cleaning up
build(7).
NO_FSCHG has been the documented way (in examples) for installing over
NFS for a very long time. It looks to my eye like this change fixed a
problem with that...
Warner
:
: Scott
:
: On Jun 15, 2009, at 3:05 PM, Ed Schouten wrote:
:
: > Author: ed
: > Date: Mon Jun 15 21:05:00 2009
: > New Revision: 194266
: > URL: http://svn.freebsd.org/changeset/base/194266
: >
: > Log:
: > Make the chpass Makefile honour NO_FSCHG.
: >
: > The chpass Makefile tried to set the fschg flag on the binaries, even if
: > NO_FSCHG was passed to the installworld. This meant that if I installed
: > FreeBSD into a Jail, I couldn't installworld from within the Jail
: > anymore.
: >
: > Now that it listens to NO_FSCHG, we can just make it bail out when it
: > fails, just like PRECIOUSPROG does.
: >
: > Modified:
: > head/usr.bin/chpass/Makefile
: >
: > Modified: head/usr.bin/chpass/Makefile
: >
==
: > --- head/usr.bin/chpass/MakefileMon Jun 15 21:03:25 2009
(r194265)
: > +++ head/usr.bin/chpass/MakefileMon Jun 15 21:05:00 2009
(r194266)
: > @@ -39,11 +39,12 @@ MLINKS+= chpass.1 ypchpass.1 chpass.1 yp
: >
: > beforeinstall:
: > .for i in chpass chfn chsh ypchpass ypchfn ypchsh
: > - [ ! -e ${DESTDIR}${BINDIR}/$i ] || \
: > - chflags noschg ${DESTDIR}${BINDIR}/$i || true
: > + -chflags noschg ${DESTDIR}${BINDIR}/$i
: > .endfor
: >
: > +.if !defined(NO_FSCHG)
: > afterinstall:
: > - -chflags schg ${DESTDIR}${BINDIR}/chpass
: > + chflags schg ${DESTDIR}${BINDIR}/chpass
: > +.endif
: >
: > .include
:
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn: head/sbin/newfs
In message: <4b8f3f4b.7020...@freebsd.org> Maxim Sobolev writes: : Warner Losh wrote: : > Author: imp : > Date: Wed Mar 3 21:53:25 2010 : > New Revision: 204672 : > URL: http://svn.freebsd.org/changeset/base/204672 : > Log: : > Cast these to intmax_t before printing to fix build bustage. Better : > solutions welcome. : : Thanks for a quick fix and sorry for the breakage. IMHO you fix's : fine, there is no real reason to use 64-bit quantity anyway, it's just : because expand_number(3) interface is not very well designed and : forces anyone using it stick with that data type. So downsizing from : 64-bit to 32-bit on platforms where intmax_t is 32-bit only (if any) : should not be an issue in real life. Yea, but as others have pointed out, this seems to point out that there's interface problems, and things have silently changed from needing to be int to needing to be int64_t, which breaks on i386... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r204672 - head/sbin/newfs
In message:
Garrett Cooper writes:
: On Mar 3, 2010, at 1:53 PM, Warner Losh wrote:
:
: > Author: imp
: > Date: Wed Mar 3 21:53:25 2010
: > New Revision: 204672
: > URL: http://svn.freebsd.org/changeset/base/204672
: >
: > Log:
: > Cast these to intmax_t before printing to fix build bustage. Better
: > solutions welcome.
: >
: > Modified:
: > head/sbin/newfs/mkfs.c
: >
: > Modified: head/sbin/newfs/mkfs.c
: > ===
: > ===
: > ===
: > =
: > --- head/sbin/newfs/mkfs.cWed Mar 3 21:47:25 2010(r204671)
: > +++ head/sbin/newfs/mkfs.cWed Mar 3 21:53:25 2010(r204672)
: > @@ -191,8 +191,8 @@ restart:
: > exit(17);
: > }
: > if (sblock.fs_fsize < sectorsize) {
: > -printf("increasing fragment size from %d to sector size (%d)\n",
: > -sblock.fs_fsize, sectorsize);
: > + printf("increasing fragment size from %d to sector size (%jd)\n",
: > +sblock.fs_fsize, (intmax_t)sectorsize);
: > sblock.fs_fsize = sectorsize;
: > }
: > if (sblock.fs_bsize > MAXBSIZE) {
: > @@ -337,8 +337,8 @@ restart:
: > } else if (density < minfragsperinode * fsize) {
: > origdensity = density;
: > density = minfragsperinode * fsize;
: > -fprintf(stderr, "density increased from %d to %d\n",
: > -origdensity, density);
: > +fprintf(stderr, "density increased from %d to %jd\n",
: > +origdensity, (intmax_t)density);
: > }
: > origdensity = density;
: > for (;;) {
: > @@ -346,8 +346,9 @@ restart:
: > if (fragsperinode < minfragsperinode) {
: > bsize <<= 1;
: > fsize <<= 1;
: > -printf("Block size too small for a file system %s %d\n",
: > - "of this size. Increasing blocksize to", bsize);
: > +printf("Block size too small for a file system %s %jd\n",
: > +"of this size. Increasing blocksize to",
: > +(intmax_t)bsize);
: > goto restart;
: > }
: > minfpg = fragsperinode * INOPB(&sblock);
: > @@ -371,7 +372,8 @@ restart:
: > density -= sblock.fs_fsize;
: > }
: > if (density != origdensity)
: > -printf("density reduced from %d to %d\n", origdensity, density);
: > +printf("density reduced from %d to %jd\n", origdensity,
: > +(intmax_t)density);
: > /*
: >* Start packing more blocks into the cylinder group until
: >* it cannot grow any larger, the number of cylinder groups
:
: Use PRId64 from inttypes.h ?
Nope.
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r204591 - in head: sbin/ipfw sys/conf sys/net sys/netinet sys/netinet/ipfw sys/netinet/ipfw/test
In message: <20100302192845.gd2...@deviant.kiev.zoral.com.ua>
Kostik Belousov writes:
: On Tue, Mar 02, 2010 at 08:03:44PM +0100, Luigi Rizzo wrote:
: > On Tue, Mar 02, 2010 at 08:51:30PM +0200, Kostik Belousov wrote:
: > ...
: > > > --- head/sbin/ipfw/Makefile Tue Mar 2 17:34:11 2010
(r204590)
: > > > +++ head/sbin/ipfw/Makefile Tue Mar 2 17:40:48 2010
(r204591)
: > > > @@ -3,7 +3,6 @@
: > > > PROG= ipfw
: > > > SRCS= ipfw2.c dummynet.c ipv6.c main.c nat.c altq.c
: > > > WARNS?=2
: > > > -DPADD= ${LIBUTIL}
: > > > LDADD= -lutil
: > > > MAN= ipfw.8
: > > Removal of DPADD is most likely regression ?
: >
: > possibly.
: > i couldn't figure out why it was there in the
: > first place, can you clarify what it was for ?
: To depend on the libutil, so that ipfw is reloaded when libutil.a is
: changed.
:
: The question I do not know answer for, is why do we need LDADD.
DPADD is used to add the static file (/usr/lib/libutil.a). LDADD is
used to add the library to the command line (-lutil). IIRC, it isn't
always possible to map one to the other, but I've never explored why...
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r204548 - head/gnu/usr.bin/binutils/ld
In message: <201003020543.o225h4bn034...@svn.freebsd.org>
Warner Losh writes:
: Author: imp
: Date: Tue Mar 2 05:43:04 2010
: New Revision: 204548
: URL: http://svn.freebsd.org/changeset/base/204548
:
: Log:
: Add n32 ABI generators...
:
: Submitted by: neel, jmallet
Correction: This was submitted by JC (C. Jayachandran).
: Added:
: head/gnu/usr.bin/binutils/ld/elf32btsmipn32_fbsd.sh
: - copied unchanged from r204272,
head/gnu/usr.bin/binutils/ld/elf32btsmip_fbsd.sh
: head/gnu/usr.bin/binutils/ld/elf32ltsmipn32_fbsd.sh
: - copied unchanged from r204272,
head/gnu/usr.bin/binutils/ld/elf32ltsmip_fbsd.sh
: Modified:
: head/gnu/usr.bin/binutils/ld/Makefile.mips
: head/gnu/usr.bin/binutils/ld/genscripts.sh
:
: Modified: head/gnu/usr.bin/binutils/ld/Makefile.mips
: ==
: --- head/gnu/usr.bin/binutils/ld/Makefile.mipsTue Mar 2 05:40:01
2010(r204547)
: +++ head/gnu/usr.bin/binutils/ld/Makefile.mipsTue Mar 2 05:43:04
2010(r204548)
: @@ -10,7 +10,8 @@ NATIVE_EMULATION=elf${_sz}btsmip_fbsd
: NATIVE_EMULATION=elf${_sz}ltsmip_fbsd
: .endif
:
: -MIPS_ABIS=elf32btsmip_fbsd elf32ltsmip_fbsd elf64btsmip_fbsd elf64ltsmip_fbsd
: +MIPS_ABIS=elf32btsmip_fbsd elf32ltsmip_fbsd elf64btsmip_fbsd
elf64ltsmip_fbsd \
: +elf32btsmipn32_fbsd elf32ltsmipn32_fbsd
: .for abi in ${MIPS_ABIS}
: #.if (${abi} != ${NATIVE_EMULATION})
: EMS+= ${abi}
:
: Copied: head/gnu/usr.bin/binutils/ld/elf32btsmipn32_fbsd.sh (from r204272,
head/gnu/usr.bin/binutils/ld/elf32btsmip_fbsd.sh)
: ==
: --- /dev/null 00:00:00 1970 (empty, because file is newly added)
: +++ head/gnu/usr.bin/binutils/ld/elf32btsmipn32_fbsd.sh Tue Mar 2
05:43:04 2010(r204548, copy of r204272,
head/gnu/usr.bin/binutils/ld/elf32btsmip_fbsd.sh)
: @@ -0,0 +1,4 @@
: +# $FreeBSD$
: +. ${srcdir}/emulparams/elf32btsmip.sh
: +. ${srcdir}/emulparams/elf_fbsd.sh
: +GENERATE_PIE_SCRIPT=yes
:
: Copied: head/gnu/usr.bin/binutils/ld/elf32ltsmipn32_fbsd.sh (from r204272,
head/gnu/usr.bin/binutils/ld/elf32ltsmip_fbsd.sh)
: ==
: --- /dev/null 00:00:00 1970 (empty, because file is newly added)
: +++ head/gnu/usr.bin/binutils/ld/elf32ltsmipn32_fbsd.sh Tue Mar 2
05:43:04 2010(r204548, copy of r204272,
head/gnu/usr.bin/binutils/ld/elf32ltsmip_fbsd.sh)
: @@ -0,0 +1,4 @@
: +# $FreeBSD$
: +. ${srcdir}/emulparams/elf32ltsmip.sh
: +. ${srcdir}/emulparams/elf_fbsd.sh
: +GENERATE_PIE_SCRIPT=yes
:
: Modified: head/gnu/usr.bin/binutils/ld/genscripts.sh
: ==
: --- head/gnu/usr.bin/binutils/ld/genscripts.shTue Mar 2 05:40:01
2010(r204547)
: +++ head/gnu/usr.bin/binutils/ld/genscripts.shTue Mar 2 05:43:04
2010(r204548)
: @@ -50,6 +50,7 @@ fi
: if test -d ldscripts; then
:true
: else
: + rm -f ldscripts
:mkdir ldscripts
: fi
:
:
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
