Re: svn commit: r219045 - head/lib/libc/gen
On Fri, Feb 25, 2011 at 3:05 PM, Ed Schouten wrote: > Author: ed > Date: Fri Feb 25 23:05:35 2011 > New Revision: 219045 > URL: http://svn.freebsd.org/changeset/base/219045 > > Log: > Fix style(9) issues in pututxline(3). > > Also, make sure to initialize the `ret' variable properly. I guess it's my first pointy hat by proxy :/... -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219181 - head/release
On Thu, Mar 3, 2011 at 11:37 AM, Matthew Jacob wrote: > > >> I think it is a very important feature to ensure release builds are not >> polluted by local changes in /etc/src.conf, etc. I think it would be good >> to support both models perhaps, but for our official release builds I >> think >> we need the clean environment. I certainly use 'make release' now for my >> own custom FooBSD builds to get a clean environment. >> > While not disagreeing with you on this, one should really always do 'env -i > PATH=/usr/bin:/bin make release' if you want to ensure non-pollution. It's more in-depth than that. The only way to ensure that the release builds are non-tainted without doing a ton of hacks is to create an untainted chroot/jail for the release build, or do the previous incantation in release/Makefile, as a number of components can taint the environment outside of PATH (see nanobsd's build scripts for a start on this). My personal preference is to have the scripts and infrastructure exist within release to do this instead of within release/Makefile, but this would require changes to any existing infrastructure that anyone depending on release/Makefile is employing out in the field; on the bright side maybe release/Makefile and nanobsd could converge because they'd be using more of the same logic to run things and the things that would truly differ are just the payload content. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219424 - head/sbin/geom/class/eli
2011/3/9 Alexey Dokuchaev : > On Wed, Mar 09, 2011 at 07:43:51AM +, Pawel Jakub Dawidek wrote: >> Author: pjd >> Date: Wed Mar 9 07:43:51 2011 >> New Revision: 219424 >> URL: http://svn.freebsd.org/changeset/base/219424 >> >> Log: >> Change example to not be controversial. >> I'm sorry to anyone who felt offended by this. >> >> PR: docs/155385 > > Sorry to see these little jokes go, but Lena does have her merits. > However, there are still traces of "sexism" present in new version: > employee is assumed to be male. :-) Replacing "his" with "their" > is standard way out in cases like this, I believe. Actually the proper way is "his or her". It's grammatically correct and doesn't necessarily imply gender supremacy. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219084 - in head: bin/test tools/regression/bin/test
On Wed, Mar 9, 2011 at 12:59 PM, Xin LI wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 03/09/11 12:56, Ulrich Spörlein wrote: >> On Sun, 27.02.2011 at 12:28:06 +, Xin LI wrote: >>> Author: delphij >>> Date: Sun Feb 27 12:28:06 2011 >>> New Revision: 219084 >>> URL: http://svn.freebsd.org/changeset/base/219084 >>> >>> Log: >>> Accept == as an alias of = which is a popular GNU extension. >>> >>> This is intentionally undocumented for now since it's not part >>> of any standard. >>> >>> MFC after: 1 month >> >> So we are giving up the fight? > > What fight? https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tpl&source=L&listname=austin-group-l&id=15441 -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r217586 - in head: sbin/sysctl share/man/man9 sys/cam/scsi sys/dev/cxgb sys/dev/wi sys/net sys/sys
On Wed, Jan 19, 2011 at 9:04 AM, Matthew D Fleming wrote: > Author: mdf > Date: Wed Jan 19 17:04:07 2011 > New Revision: 217586 > URL: http://svn.freebsd.org/changeset/base/217586 > > Log: > sysctl(8) should use the CTLTYPE to determine the type of data when > reading. (This was already done for writing to a sysctl). This > requires all SYSCTL setups to specify a type. Most of them are now > checked at compile-time. > > Remove SYSCTL_*X* sysctl additions as the print being in hex should be > controlled by the -x flag to sysctl(8). I appreciate the work, but this really should have been followed up by a __FreeBSD_version__ bump, as this unfortunately broke some ports like emulators/*qemu*. I just filed a PR for it as I noticed it when doing portmaster -af for the recent X.org upgrade. FWIW, this can be properly tested with: __FreeBSD_version__ < 900031; kib bumped the version a week after this commit. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219699 - head/sys/kern
On Wed, Mar 16, 2011 at 12:51 PM, Ivan Voras wrote: > On 16 March 2011 18:46, Roman Divacky wrote: >> >> On Wed, Mar 16, 2011 at 04:22:59PM +, Ivan Voras wrote: >> > Author: ivoras >> > Date: Wed Mar 16 16:22:59 2011 >> > New Revision: 219699 >> > URL: http://svn.freebsd.org/changeset/base/219699 >> > >> > Log: >> > The hardware has caught up; improvements are now observed even at 128, >> > but stay conservative and bump read_max to "only" 64 (it will probably be >> > a good idea to increase this to 128 after the next major release). >> >> how did you measure this? > > Specifically for this commit: my desktop 2xSATA 7200 RPM drives, > gmirror, single read "dd" stream, bs=1m. (Are there any ready read > multi-stream read tests which are not trivial i.e. they start from > different positions in the file?) Would be interesting to see how well things work with the new geom_raid bits and with other drives (SAS, SCSI). Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r218753 - head/etc/namedb
On Sun, Feb 20, 2011 at 12:18 PM, Doug Barton wrote: > On 2/20/2011 8:49 AM, Philip M. Gollucci wrote: >> >> On 2/19/2011 8:35 PM, Doug Barton wrote: >>> >>> On 02/19/2011 16:52, Philip M. Gollucci wrote: On 2/16/2011 4:23 PM, Doug Barton wrote: > > Author: dougb > Date: Wed Feb 16 21:23:09 2011 > New Revision: 218753 > URL: http://svn.freebsd.org/changeset/base/218753 > > Log: > Remove in-addr.arpa from the list of zones it is possible to slave > locally This is b/c of the recent change to fix the list of root servers that serve this right ? >>> >>> Not precisely. in-addr.arpa has moved to its own set of servers operated >>> jointly by the RIRs and ICANN. At some point in the near future this >>> zone will no longer be available directly from the root servers at all. >> >> We said the same thing, just I said it badly. > > Sorry to be pedantic, but it's for a (hopefully) good reason. People often > refer to any servers high up in the tree as "the root servers for ..." There > is actually only one set of root servers, the ones that serve the actual > root zone. For hysterical raisins these servers also served ARPA, and > IN-ADDR.ARPA. A little bit better job was done with IP6.ARPA to start with > so it was the first to move from one set of servers managed by the RIRs and > ICANN to a different set that are similarly named in order to take advantage > of name compression in the DNS packet. IN-ADDR.ARPA is the next to move both > for compression purposes, and to get the zone off the roots. > > So, not to pick on you here, my purpose is simply to clarify that they did > not change "the list of root servers," they actually changed the delegation > of IN-ADDR.ARPA to its own set of name servers. > > I should probably add that while it's technically possible, it's highly > unlikely that ARPA itself will move off the roots. The zone is very small, > and very static; and that is incredibly unlikely to change any time in the > near future. The IN-ADDR and IP6.ARPA zones on the other hand are both > larger, and more dynamic (although IN-ADDR is going to be changing less and > less as time goes on). Looks like this happened sometime in the last while because now I'm not getting NXDOMAIN errors after removing this entry when trying to run host on a machine in my network :). Doesn't fix my syslogd issue though (still debugging >o<...).. Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r219788 - head/release
On Sat, Mar 19, 2011 at 4:06 PM, Nathan Whitehorn wrote: > Author: nwhitehorn > Date: Sat Mar 19 23:06:17 2011 > New Revision: 219788 > URL: http://svn.freebsd.org/changeset/base/219788 > > Log: > Add support for checking out ports and doc trees from a CVS repository, > in addition to CVSUP, and add support for alternate SVN roots for src. > > Requested by: jhb Although this seems good and all, wouldn't it make sense to split off the pulling infrastructure into separate scripts so that someone could have hooks to do: - pre-pull (create paths, whatever) - pull - post-pull (patch?) That way someone could choose any arbitrary SCM (git, hg, etc), specify necessary configuration files, and apply local patches as necessary. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r220162 - head/usr.sbin/pc-sysinstall/backend-partmanager
On Wed, Mar 30, 2011 at 10:37 AM, Josh Paetzel wrote:
> Author: jpaetzel
> Date: Wed Mar 30 17:37:04 2011
> New Revision: 220162
> URL: http://svn.freebsd.org/changeset/base/220162
>
> Log:
> Check in two missing files missed in cleanup.
> Change expr to $(())
> Switch test from "$?" = "0" to $? -eq 0
>
> Approved by: kib (mentor)
>
> Modified:
> head/usr.sbin/pc-sysinstall/backend-partmanager/create-part.sh
> head/usr.sbin/pc-sysinstall/backend-partmanager/delete-part.sh
>
> Modified: head/usr.sbin/pc-sysinstall/backend-partmanager/create-part.sh
> ==
> --- head/usr.sbin/pc-sysinstall/backend-partmanager/create-part.sh Wed
> Mar 30 17:33:52 2011 (r220161)
> +++ head/usr.sbin/pc-sysinstall/backend-partmanager/create-part.sh Wed
> Mar 30 17:37:04 2011 (r220162)
> @@ -85,7 +85,7 @@ fi
>
> # If this is an empty disk, see if we need to create a new scheme for it
> gpart show ${DISK} >/dev/null 2>/dev/null
> -if [ "$?" != "0" -a "${SLICENUM}" = "1" ] ; then
> +if [ $? -eq 0 -a "${SLICENUM}" = "1" ] ; then
> gpart create -s ${TYPE} ${DISK}
> fi
>
>
> Modified: head/usr.sbin/pc-sysinstall/backend-partmanager/delete-part.sh
> ==
> --- head/usr.sbin/pc-sysinstall/backend-partmanager/delete-part.sh Wed
> Mar 30 17:33:52 2011 (r220161)
> +++ head/usr.sbin/pc-sysinstall/backend-partmanager/delete-part.sh Wed
> Mar 30 17:37:04 2011 (r220162)
> @@ -57,10 +57,10 @@ PARTINDEX=""
> while
> z=1
> do
> - CHARS=`expr $CHARS - 1`
> + CHARS=$((CHARS-1))
This can also be done with the null operator:
: $(( CHARS -= 1 ))
it's the way that the LTP project (which I'm still a member of) does
things in order to be 'portable' (non-portable being bash/korn shell
isms for what little it's worth :)..).
> LAST_CHAR=`echo "${PARTITION}" | cut -c $CHARS`
> - echo "${LAST_CHAR}" | grep "^[0-9]$" >/dev/null 2>/dev/null
> - if [ "$?" = "0" ] ; then
> + echo "${LAST_CHAR}" | grep -q "^[0-9]$" 2>/dev/null
> + if [ $? -eq 0 ] ; then
> PARTINDEX="${LAST_CHAR}${PARTINDEX}"
> else
> break
Thanks!
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r220168 - head/etc
On Mar 31, 2011, at 2:34 AM, Gavin Atkinson wrote:
> On Wed, 2011-03-30 at 18:35 +, Edward Tomasz Napierala wrote:
>> Author: trasz
>> Date: Wed Mar 30 18:35:02 2011
>> New Revision: 220168
>> URL: http://svn.freebsd.org/changeset/base/220168
>>
>> Log:
>> Add example devd.conf entry.
>>
>> +
>> +# This example works around a memory leak in PostgreSQL, restarting
>> +# it when "user:pgsql:swap:devctl=1G" rctl(8) rule gets triggered.
>> +notify 0 {
>> +match "system""RCTL";
>> +match "rule""user:70:swap:.*";
>> +action"/usr/local/etc/rc.d/postgresql restart"
>> +};
>> +
>> */
>
> This seems like a dangerous rule to have enabled by default?
It's commented out (devd.conf supports multiline C-style comments and this was
added at the end of the file).
Hth,
-Garrett___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r220387 - head/sys/vm
On Wed, Apr 6, 2011 at 9:27 AM, Edward Tomasz Napierala wrote: > Author: trasz > Date: Wed Apr 6 16:27:04 2011 > New Revision: 220387 > URL: http://svn.freebsd.org/changeset/base/220387 > > Log: > In vm_daemon(), do not skip processes stopped with SIGSTOP. Did you run this by anyone else before you committed the change? Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r220387 - head/sys/vm
2011/4/6 Edward Tomasz Napierała : > Wiadomość napisana przez Garrett Cooper w dniu 2011-04-06, o godz. 18:57: >> On Wed, Apr 6, 2011 at 9:27 AM, Edward Tomasz Napierala >> wrote: >>> Author: trasz >>> Date: Wed Apr 6 16:27:04 2011 >>> New Revision: 220387 >>> URL: http://svn.freebsd.org/changeset/base/220387 >>> >>> Log: >>> In vm_daemon(), do not skip processes stopped with SIGSTOP. >> >> Did you run this by anyone else before you committed the change? > > The whole racct patchset was reviewed by kib@, and I seem to remember > that he said this might cause problems. However, I didn't encounter > any problems with this, neither did any person testing the patchset. > > So, what's wrong with this? My concern was just that "Reviewed by" was missing and that this might introduce some unexpected functional issues (then again it's now going to kill stopped processes, right?). -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r220412 - in head: share/man/man4 sys/cam/ata
On Thu, Apr 7, 2011 at 12:03 PM, Alexander Best wrote: > On Thu Apr 7 11, Alexander Motin wrote: >> Author: mav >> Date: Thu Apr 7 08:17:53 2011 >> New Revision: 220412 >> URL: http://svn.freebsd.org/changeset/base/220412 >> >> Log: >> Make ada(4) driver to control device write cache, same as ata(4) does. >> Add kern.cam.ada.write_cache sysctl/tunable to control it alike hw.ata.wc. > > how hard would it be to support per device sysctls/tunables? i'd really like > to > do: > > kern.cam.ada.0.write_cache=0 (root fs) > kern.cam.ada.1.write_cache=1 (/usr, /var, etc.) Does it really make sense to turn on write caching for one drive and not the other(s)? Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r220412 - in head: share/man/man4 sys/cam/ata
On Thu, Apr 7, 2011 at 2:23 PM, Warner Losh wrote: > > On Apr 7, 2011, at 3:00 PM, Garrett Cooper wrote: > >> On Thu, Apr 7, 2011 at 12:03 PM, Alexander Best wrote: >>> On Thu Apr 7 11, Alexander Motin wrote: >>>> Author: mav >>>> Date: Thu Apr 7 08:17:53 2011 >>>> New Revision: 220412 >>>> URL: http://svn.freebsd.org/changeset/base/220412 >>>> >>>> Log: >>>> Make ada(4) driver to control device write cache, same as ata(4) does. >>>> Add kern.cam.ada.write_cache sysctl/tunable to control it alike >>>> hw.ata.wc. >>> >>> how hard would it be to support per device sysctls/tunables? i'd really >>> like to >>> do: >>> >>> kern.cam.ada.0.write_cache=0 (root fs) >>> kern.cam.ada.1.write_cache=1 (/usr, /var, etc.) >> >> Does it really make sense to turn on write caching for one drive and >> not the other(s)? > > Think about /usr/obj or /tmp and ask that question again. Or any filesystem > that's mounted that you don't really care about the contents of across a > power cycle. If you have to recreate it, that's OK. In those cases, you > may want the speed increase over safety that write_cache gives you. Or maybe > you have a drive that's doing write caching correctly and one that doesn't. Alex, Warner: thanks for the practical example; I hadn't really considered that :). Cheers! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r220584 - in head/sys: amd64/amd64 i386/i386
On Wed, Apr 13, 2011 at 2:49 PM, Dimitry Andric wrote: > On 2011-04-13 23:41, Dimitry Andric wrote: > ... >> >> But I don't really see why, yet. :) With r220532, it worked fine. > > Ah, I failed to notice the commit that came before, r220583. > Apparently, it can happen (at least in a VM environment) that the > DELAY(1000) in this fragment from cpu_est_clockrate(): > > wrmsr(MSR_MPERF, 0); > wrmsr(MSR_APERF, 0); > tsc1 = rdtsc(); > DELAY(1000); > mcnt = rdmsr(MSR_MPERF); > acnt = rdmsr(MSR_APERF); > tsc2 = rdtsc(); > intr_restore(reg); > perf = 1000 * acnt / mcnt; > > will still read 0 from MSR_MPERF, leading to a division by zero. Maybe > just fallback to the second method in the 'else' branch then? Yeah, it kind of peeves me that this kind of rinky dink stuff is done with VMware ESXi, etc (fake RAM returning 0MHz in the SMBIOS table in certain scenarios). Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r220584 - in head/sys: amd64/amd64 i386/i386
On Wed, Apr 13, 2011 at 3:27 PM, Jung-uk Kim wrote: > On Wednesday 13 April 2011 05:49 pm, Dimitry Andric wrote: >> On 2011-04-13 23:41, Dimitry Andric wrote: >> ... >> >> > But I don't really see why, yet. :) With r220532, it worked >> > fine. >> >> Ah, I failed to notice the commit that came before, r220583. >> Apparently, it can happen (at least in a VM environment) that the >> DELAY(1000) in this fragment from cpu_est_clockrate(): >> >> wrmsr(MSR_MPERF, 0); >> wrmsr(MSR_APERF, 0); >> tsc1 = rdtsc(); >> DELAY(1000); >> mcnt = rdmsr(MSR_MPERF); >> acnt = rdmsr(MSR_APERF); >> tsc2 = rdtsc(); >> intr_restore(reg); >> perf = 1000 * acnt / mcnt; >> >> will still read 0 from MSR_MPERF, leading to a division by zero. >> Maybe just fallback to the second method in the 'else' branch then? > > That means your VM has broken CPUID support. To get there, it has to > meet two conditions, i.e., TSC is invariant and it has APERF/MPERF > MSRs. A simple workaround is setting "machdep.disable_tsc=1" > tuanable from loader but your VM is the real culprit here. VMware ESXi lies on multiple fronts in this area I've discovered lately at $WORK, in particular the SMBIOS / FreeBSD are calling CPUID which is returning info based on the host processor instead of the emulated guest processor, which in turn is causes minor problems in our software. Example being that the host processor is a Intel Woodcrest CPU (this is what an in-house tool and FreeBSD reports) instead of a Pentium Pro emulated CPU (that's what dmidecode reports and that's what ESXi emulates). Wasn't happy about this breakage and someone should probably talk to VMware about fixing their emulation software so that it tells a consistent story across the board. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r220736 - head/sbin/natd
2011/4/18 Gleb Smirnoff : > On Sun, Apr 17, 2011 at 06:05:38AM +, Maxim Sobolev wrote: > M> Author: sobomax > M> Date: Sun Apr 17 06:05:37 2011 > M> New Revision: 220736 > M> URL: http://svn.freebsd.org/changeset/base/220736 > M> > M> Log: > M> If we can retrieve interface address sleep for one second and try again. > M> This can happen during start-up, when natd starts before dhclient has a > M> chance to receive IP address from the upstream provider. > M> > M> MFC after: 2 weeks > > This looks like a hack and better place for this hack would be shell > scripts rather than nat daemon. +1 -- in particular because this will affect all cases, and not just the dhclient-acquired IP external NIC case as the above commit message notes. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r220736 - head/sbin/natd
2011/4/18 Maxim Sobolev : > On 4/18/2011 11:13 AM, Gleb Smirnoff wrote: >> >> This looks like a hack and better place for this hack would be shell >> scripts rather than nat daemon. > > Well, I am not sure how would you apply shell script in such case. The > problem with the original code is that natd just silently exits, leaving > machine without a network connection. For some reason this problem started > after upgrade from 7.4 to 8.2, perhaps there is some changes in the dhclient > which allows it to run is parallel with other start-up activity. I've seen the problem that you've attempted to fix here before at home, and it actually occurred between 8.1 and 8.2. I merely hacked things to work at home in the rc script because I didn't want to muck around with natd's C sources. > And I don't see any problem with natd waiting indefinitely on the interface > to acquire IP address, it's no better and no worse than the current behavior > when the natd simply bails out. If it does this when backgrounded, that seems ok. If it blocks foregrounded like this, that's not acceptable. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On Apr 25, 2011, at 9:29 AM, Alexander Motin wrote: > Warner Losh wrote: >> On Apr 25, 2011, at 7:45 AM, Pawel Jakub Dawidek wrote: >>> On Sun, Apr 24, 2011 at 06:59:40PM +, Bjoern A. Zeeb wrote: I had been pondering devfs "link"s myself, the problem is that from the rc framework they come too late. If you can add a simple .ko that does it programmatically on 9 that would be great. The problem is that after booting the new kernel you don't know whether people had ATA_STATIC on or not, so we'd have to go with the defaults, that were in 8.x (and an extra tunable to flip the logic maybe)? >>> We do know that people have ATA_STATIC_ID, because if they don't, this >>> means they have their custom kernel config which doesn't contain ATA_CAM >>> and when they will use it next time they recompile their kernel they >>> will still have /dev/adX entries. >>> >>> Also, as Alexander already noted, because of all the problems with ATA >>> naming over the years and for other reasons too, people often hardcode >>> provider name in various GEOM classes metadata, so symlink won't help. >> >> Do we have a short list of the places to look? > > Quick man pages grepping shows that at least gmirror, gstripe, graid3, > gjournal, gvirstor, gconcat, gshsec support provider names hardcoding. > For gmirror and graid3 present status can be obtained by: `gXXX list | > egrep "Flags: .*HARDCODED"`. For gvirstor, gshsec, gstripe and gconcat: > `gXXX dump adX | egrep "Hardcoded provider: ad"`. For gjournal: > `gjournal dump adX | egrep "hcprovider: ad"`. > >> A lot of this could be done with a script that gets run at installworld and >> boot time to hunt down the old cases and report them to the user before they >> upgrade their kernel (but this would mean backing out the GENERIC change for >> a while to give people a chance to upgrade to label-based provisioning... > > If I understand idea right, independently of how much we delay it, there > will be some people who not updated during that window to get in code > detecting it during boot. Hardly many people of target auditory updating > their systems each month. Same time some checks indeed could be done in > installkernel. For people like me who install multiple kernels and boot them at will, especially when there are other features under a large degree of development, this kind of action isn't acceptable because it shoots you in the foot when moving between the different kernels. I'd prefer having an UPDATING note with all of the affected areas so that people can understand what needs to change and adjust their systems accordingly. As far as geom based hardcoding is concerned: maybe this can serve as a good lesson of what shouldn't be done and what should be fixed/have a translation layer added for this item? Thanks, -Garrett___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r206176 - head/share/examples/indent
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? Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r206363 - head/sys/dev/syscons/logo
On Wed, Apr 7, 2010 at 10:07 AM, Jung-uk Kim wrote: > Author: jkim > Date: Wed Apr 7 17:07:06 2010 > New Revision: 206363 > URL: http://svn.freebsd.org/changeset/base/206363 > > Log: > Add the official FreeBSD logo image file for logo_saver. > > Modified: > head/sys/dev/syscons/logo/logo.c Please readd the beastie logo based saver as beastie saver, or something similar. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r206550 - head/sbin/geom/class/sched
On Tue, Apr 13, 2010 at 2:52 AM, Luigi Rizzo wrote:
> Author: luigi
> Date: Tue Apr 13 09:52:42 2010
> New Revision: 206550
> URL: http://svn.freebsd.org/changeset/base/206550
>
> Log:
> use correct .PATH, remove unused CFLAGS
>
> Modified:
> head/sbin/geom/class/sched/Makefile
>
> Modified: head/sbin/geom/class/sched/Makefile
> ==
> --- head/sbin/geom/class/sched/Makefile Tue Apr 13 08:56:03 2010
> (r206549)
> +++ head/sbin/geom/class/sched/Makefile Tue Apr 13 09:52:42 2010
> (r206550)
> @@ -1,9 +1,8 @@
> # GEOM_LIBRARY_PATH
> # $FreeBSD$
>
> -.PATH: /usr/src/sbin/geom/misc
> -
> -CFLAGS += -I/usr/src/sbin/geom
> +.PATH: ${.CURDIR}/../../misc
> +#CFLAGS += -I/usr/src/sbin/geom
Shouldn't this just be removed instead of commented out?
Thanks,
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r206973 - head/share/mk
On Tue, Apr 20, 2010 at 6:13 PM, Xin LI wrote: > Author: delphij > Date: Wed Apr 21 01:13:08 2010 > New Revision: 206973 > URL: http://svn.freebsd.org/changeset/base/206973 > > Log: > When CPUTYPE is defined to any value, on amd64 platform "mmx" is > available through MACHINE_CPU, indicating the CPU supports that > feature, as done by revision 138685. > > This changeset adds "mmx" into the default amd64 MACHINE_CPU list > when no CPUTYPE is specified to provide consistent behavior. The crowd goes wild XD... Thanks Martin and Xin Li! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r207206 - head/bin/sh
On Wed, Apr 28, 2010 at 10:40 AM, Doug Barton wrote: > On 04/28/10 08:36, Ed Maste wrote: >> While we're on this topic, I'll mention the bashism I'd like to see >> support for > > ... and I'd like to cast a vote for NOT bloating our sh with features > from more advanced shells. Either we should actually import one of the > more advanced shells (and no, I don't want to start that bikeshed, > especially not on the svn list) or we should continue down the path > Jilles is taking of cleaning up the shell we have. > > I think Jilles is on the right path. Completely and wholeheartedly agree. -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r207849 - in head: . lib/libarchive rescue/rescue usr.bin/ar usr.bin/cpio usr.bin/cpio/test usr.bin/tar usr.bin/tar/test
On May 11, 2010, at 3:02 PM, N.J. Mann wrote: > In message <201005101528.o4afsimx091...@svn.freebsd.org>, >Martin Matuska (m...@freebsd.org) wrote: >> Author: mm >> Date: Mon May 10 15:28:44 2010 >> New Revision: 207849 >> URL: http://svn.freebsd.org/changeset/base/207849 >> >> Log: >> Enable liblzma support in libarchive >> Adjust dependencies for programs using libarchive >> Add xz and linkage against liblzma to rescue system >> >> Approved by:kientzle, delphij (mentor) >> MFC after: 2 weeks >> >> Modified: >> head/Makefile.inc1 >> head/lib/libarchive/Makefile >> head/rescue/rescue/Makefile >> head/usr.bin/ar/Makefile >> head/usr.bin/cpio/Makefile >> head/usr.bin/cpio/test/Makefile >> head/usr.bin/tar/Makefile >> head/usr.bin/tar/test/Makefile > [...] > > This commit breaks the build for me. I am building on a i386 system > running FreeBSD 7.3-STABLE r205828. Prior to this commit I could build > HEAD fine. Here are the last few lines of the build up to the point it > fails: > > ===> usr.bin/ar (obj,depend,all,install) > /usr/obj/home/FreeBSD.svn/base/head/tmp/home/FreeBSD.svn/base/head/usr.bin/ar > created for /home/FreeBSD.svn/base/head/usr.bin/ar > lex -t /home/FreeBSD.svn/base/head/usr.bin/ar/acplex.l > acplex.c > yacc -d /home/FreeBSD.svn/base/head/usr.bin/ar/acpyacc.y > cp y.tab.c acpyacc.c > rm -f .depend > mkdep -f .depend -a-I. -I/home/FreeBSD.svn/base/head/usr.bin/ar > -I/usr/obj/home/FreeBSD.svn/base/head/tmp/legacy/usr/include > /home/FreeBSD.svn/base/head/usr.bin/ar/ar.c acplex.c acpyacc.c > /home/FreeBSD.svn/base/head/usr.bin/ar/read.c > /home/FreeBSD.svn/base/head/usr.bin/ar/util.c > /home/FreeBSD.svn/base/head/usr.bin/ar/write.c > echo ar: /usr/lib/libc.a /usr/lib/libarchive.a /usr/lib/libbz2.a > /usr/lib/libz.a /usr/lib/liblzma.a /usr/lib/libelf.a > /usr/obj/home/FreeBSD.svn/base/head/tmp/legacy/usr/lib/libegacy.a >> .depend > cc -O2 -pipe -I. -I/home/FreeBSD.svn/base/head/usr.bin/ar -std=gnu99 > -I/usr/obj/home/FreeBSD.svn/base/head/tmp/legacy/usr/include -c > /home/FreeBSD.svn/base/head/usr.bin/ar/ar.c > cc -O2 -pipe -I. -I/home/FreeBSD.svn/base/head/usr.bin/ar -std=gnu99 > -I/usr/obj/home/FreeBSD.svn/base/head/tmp/legacy/usr/include -c acplex.c > cc -O2 -pipe -I. -I/home/FreeBSD.svn/base/head/usr.bin/ar -std=gnu99 > -I/usr/obj/home/FreeBSD.svn/base/head/tmp/legacy/usr/include -c acpyacc.c > cc -O2 -pipe -I. -I/home/FreeBSD.svn/base/head/usr.bin/ar -std=gnu99 > -I/usr/obj/home/FreeBSD.svn/base/head/tmp/legacy/usr/include -c > /home/FreeBSD.svn/base/head/usr.bin/ar/read.c > cc -O2 -pipe -I. -I/home/FreeBSD.svn/base/head/usr.bin/ar -std=gnu99 > -I/usr/obj/home/FreeBSD.svn/base/head/tmp/legacy/usr/include -c > /home/FreeBSD.svn/base/head/usr.bin/ar/util.c > cc -O2 -pipe -I. -I/home/FreeBSD.svn/base/head/usr.bin/ar -std=gnu99 > -I/usr/obj/home/FreeBSD.svn/base/head/tmp/legacy/usr/include -c > /home/FreeBSD.svn/base/head/usr.bin/ar/write.c > make: don't know how to make /usr/lib/liblzma.a. Stop > *** Error code 2 > > Stop in /home/FreeBSD.svn/base/head. > *** Error code 1 > > Stop in /home/FreeBSD.svn/base/head. > *** Error code 1 > > Stop in /home/FreeBSD.svn/base/head. > > > I have removed my /etc/make.conf and /etc/src.conf and deleted /usr/obj > before starting the build. Hi Nick, Please detail the steps that you did to actually reproduce the problem. Just to let you know though, piecewise updating of just libarchive isn't possible; you need to update some Makefiles and other pieces that Martin touched in the lzma import (in particular Makefile.inc1). Otherwise things will break quickly. HTH, -Garrett___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r208375 - in head/sys/dev: ahci ata
On Fri, May 21, 2010 at 6:29 AM, Alexander Motin wrote: > Author: mav > Date: Fri May 21 13:29:28 2010 > New Revision: 208375 > URL: http://svn.freebsd.org/changeset/base/208375 > > Log: > Improve suspend/resume support. Make sure controller is idle on suspend > and reset it on resume. Awesome -- this may fix part of the acpi(4) suspend issue on my laptop (a Lenovo T61p) as it currently auto-reboots with 8-STABLE based sources on amd64. Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r208545 - in head/release: amd64 i386 ia64 pc98 powerpc sparc64 sun4v
On Tue, May 25, 2010 at 11:10 AM, Jung-uk Kim wrote: > On Tuesday 25 May 2010 01:48 pm, 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 > > misc/146904? joerg brought up an interesting item on #bsddev: <@joerg> seeing Xin Li's last commit: does libmd contain SHA256 and SHA512? lzma doesn't use SHA512, but it does use SHA256. So does it actually need libcrypto now that libmd is included, or was it a bad analysis by your's truly? Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r208545 - in head/release: amd64 i386 ia64 pc98 powerpc sparc64 sun4v
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. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r208545 - in head/release: amd64 i386 ia64 pc98 powerpc sparc64 sun4v
On Wed, May 26, 2010 at 11:59 AM, Xin LI wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 2010/05/26 11:47, Garrett Cooper wrote: >> 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. > > Bad last minute change from me, I overlooked this :-/ > > Will a newer GNU ld solve this issue? Juli informed me (off-list) that GNU ld _does_ in fact do this, but only if you specify --start-group and --end-group in the linker arguments (which she claimed required more RAM). It might just be better to switch the linker library ordering as this would fix the issue cleanly and quickly. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r208613 - head/sys/conf
On Fri, May 28, 2010 at 3:35 AM, Rafal Jaworowski wrote: > Author: raj > Date: Fri May 28 10:35:44 2010 > New Revision: 208613 > URL: http://svn.freebsd.org/changeset/base/208613 > > Log: > Introduce kernel build options for the Flattened Device Tree support. > > Reviewed by: imp > Sponsored by: The FreeBSD Foundation > > Modified: > head/sys/conf/options > > Modified: head/sys/conf/options > == > --- head/sys/conf/options Fri May 28 09:30:13 2010 (r208612) > +++ head/sys/conf/options Fri May 28 10:35:44 2010 (r208613) > @@ -848,3 +848,7 @@ SND_PCM_64 opt_snd.h > SND_OLDSTEREO opt_snd.h > > X86BIOS > + > +# Flattened device tree options > +FDT opt_platform.h > +FDT_DTB_STATIC opt_platform.h Wewt -- awesome work guys...! Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r208954 - in head/contrib/llvm: . docs test tools/clang tools/clang/docs tools/clang/test website
On Wed, Jun 9, 2010 at 10:59 AM, Roman Divacky wrote: > Author: rdivacky > Date: Wed Jun 9 17:59:52 2010 > New Revision: 208954 > URL: http://svn.freebsd.org/changeset/base/208954 > > Log: > Import LLVM/clang from vendor stripped of docs/ test/ website/ www/ examples/ > in llvm/ and/or llvm/contrib/clang/ respectively. > > Approved by: ed (mentor) > Approved by: core > > Added: > head/contrib/llvm/ > - copied from r208953, vendor/llvm/dist/ > head/contrib/llvm/tools/clang/ > - copied from r208953, vendor/clang/dist/ > Deleted: > head/contrib/llvm/docs/ > head/contrib/llvm/test/ > head/contrib/llvm/tools/clang/docs/ > head/contrib/llvm/tools/clang/test/ > head/contrib/llvm/website/ Why strip test? This might actually be helpful for folks trying to evaluate whether or not they should upgrade to newer versions of clang. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r208954 - in head/contrib/llvm: . docs test tools/clang tools/clang/docs tools/clang/test website
On Wed, Jun 9, 2010 at 12:04 PM, Ed Schouten wrote: > Hi Garrett, > > * Garrett Cooper wrote: >> Why strip test? This might actually be helpful for folks trying to >> evaluate whether or not they should upgrade to newer versions of >> clang. > > The testsuite can be checked out separately from the vendor space. It > will account for about 50 MB of additional disk space usage. Yes, but the tests can change at any point in time and might not reflect the code stored in the repository. Could a note at least be provided, or a port maintained to help others (say vendors) who have to qualify FreeBSD that this is the particular version that needs to be picked up from in order to test our shiny new compiler? That would make things considerably easier to work with, as I've worked as QA in a Linux shop in the past, where a lot of Linux provided packages that we had in the tree did not have the associated test code, and as QA that made my job a pain to deal with. Just a small file that stated where and/or how to obtain things would make this a lot easier. I would think that developers would also like the same to see whether or not there are any particular known issues with clang/llvm. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r208965 - head/tools/build/options
On Wed, Jun 9, 2010 at 1:11 PM, Roman Divacky wrote: > Author: rdivacky > Date: Wed Jun 9 20:11:35 2010 > New Revision: 208965 > URL: http://svn.freebsd.org/changeset/base/208965 > > Log: > Add WITHOUT_CLANG file with a description. > > Approved by: ed (mentor) > > Added: > head/tools/build/options/WITHOUT_CLANG (contents, props changed) > > Added: head/tools/build/options/WITHOUT_CLANG > == > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/tools/build/options/WITHOUT_CLANG Wed Jun 9 20:11:35 2010 > (r208965) > @@ -0,0 +1,2 @@ > +$FreeBSD$ > +Set to not build the Clang C/C++ commpiler. Typo (s/commpiler/compiler/). Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r208954 - in head/contrib/llvm: . docs test tools/clang tools/clang/docs tools/clang/test website
On Jun 9, 2010, at 3:20 PM, Pawel Worach wrote: > On Jun 9, 2010, at 23:58, Garrett Cooper wrote: > >> On Wed, Jun 9, 2010 at 12:04 PM, Ed Schouten wrote: >>> Hi Garrett, >>> >>> * Garrett Cooper wrote: >>>> Why strip test? This might actually be helpful for folks trying to >>>> evaluate whether or not they should upgrade to newer versions of >>>> clang. >>> >>> The testsuite can be checked out separately from the vendor space. It >>> will account for about 50 MB of additional disk space usage. >> >> Yes, but the tests can change at any point in time and might not >> reflect the code stored in the repository. >> >> Could a note at least be provided, or a port maintained to help others >> (say vendors) who have to qualify FreeBSD that this is the particular >> version that needs to be picked up from in order to test our >> shiny new compiler? That would make things considerably easier to work >> with, as I've worked as QA in a Linux shop in the past, where a lot of >> Linux provided packages that we had in the tree did not have the >> associated test code, and as QA that made my job a pain to deal with. >> >> Just a small file that stated where and/or how to obtain things would >> make this a lot easier. >> >> I would think that developers would also like the same to see whether >> or not there are any particular known issues with clang/llvm. >> > > We have a buildbot running here[1] that has the goal of serving as a > qualification system. > > It does a nightly build of llvm/clang trunk in a self-host config, runs the > test suite in both stages and then builds freebsd trunk world+kernel and > boots the result. Yes, but how much is tested, and what code paths are tested in the compiled kernel? Do you have all of the devices required to test all of the drivers and extensive tests to exercise everything? Probably not; it sounds like what you have setup wise is a smoke test box -- which is good but it's not comprehensive enough to catch all issues... That also doesn't test out i386, or powerpc. Ideally the project should have a cluster of dedicated machines for regression testing available in a colo somewhere where someone can load images on the machine via netboot, or install, then execute a set of functional and/or performance tests to gauge whether or not the code has functional or performance regressions. Don't get me wrong, what you guys have is good -- but it's just not 100% convincing for someone making a switchover to a newer toolchain, because of all of the different variables that might be out there with all of the code in FreeBSD, as well as interactions with compiled code, and 3rd party software as well. But this is just the beginning of clang on FreeBSD and the project in and of itself has a long way to go. Adding the bits so that other groups could help evaluate, add tests, etc to ensure that clang/llvm works as expected is what we should be focusing on, not just runtime tests and `works for me' scenarios. Thanks, -Garrett___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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/p
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? Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r209542 - head/lib/libc/sys
On Sat, Jun 26, 2010 at 2:44 PM, Pawel Jakub Dawidek wrote: > Author: pjd > Date: Sat Jun 26 21:44:05 2010 > New Revision: 209542 > URL: http://svn.freebsd.org/changeset/base/209542 > > Log: > Just like in case of setgroups(2), for getgroups(2) also advice including > sys/param.h instead of sys/types.h so we get NGROUPS_MAX and NGROUPS > definitions. > > Modified: > head/lib/libc/sys/getgroups.2 > > Modified: head/lib/libc/sys/getgroups.2 > == > --- head/lib/libc/sys/getgroups.2 Sat Jun 26 20:59:10 2010 > (r209541) > +++ head/lib/libc/sys/getgroups.2 Sat Jun 26 21:44:05 2010 > (r209542) > @@ -37,7 +37,7 @@ > .Sh LIBRARY > .Lb libc > .Sh SYNOPSIS > -.In sys/types.h > +.In sys/param.h > .In unistd.h > .Ft int > .Fn getgroups "int gidsetlen" "gid_t *gidset" Hmmm... looks like our copy of getgroups(2) is not POSIX compliant then :/ : http://www.opengroup.org/onlinepubs/95399/functions/getgroups.html . Why not just use sysconf like the POSIX page suggests (which is portable)? Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r209582 - head/sys/kern
On Mon, Jun 28, 2010 at 6:42 PM, Doug Barton wrote: > On 06/28/10 18:04, Doug Barton wrote: >> Author: dougb >> Date: Tue Jun 29 01:04:24 2010 >> New Revision: 209582 >> URL: http://svn.freebsd.org/changeset/base/209582 >> >> Log: >> If i is going to be used in the loop unconditionally the declaration >> has to be unconditional as well. >> >> Conical head covering to: kib > > Hopefully it's clear to everyone that this is gentle ribbing, as opposed > to criticism. If the fix is so easy even *I* can figure it out, it truly > deserves a pointy hat. :) Ah, but Doug likes hats...! He just hates cones: http://faiththemutt.files.wordpress.com/2010/02/tumblr_kt24jwbmrb1qzyz6ko1_500.jpg :(... -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r209638 - in head/sys: amd64/amd64 i386/i386
On Thu, Jul 1, 2010 at 4:58 PM, Rui Paulo wrote: > > On 1 Jul 2010, at 23:22, John Baldwin wrote: > >> On Thursday 01 July 2010 05:58:46 pm Alexander Motin wrote: >>> Author: mav >>> Date: Thu Jul 1 21:58:46 2010 >>> New Revision: 209638 >>> URL: http://svn.freebsd.org/changeset/base/209638 >>> >>> Log: >>> Make stray irq counters have format alike to other counters. Unified >>> format makes string processing (for example by `systat -vm`) easier. >> >> As I said on the mailing lists, I actually think that the old way is a >> feature. I believe bde@ also has useful input on appropriately parsing >> interrupt names for systat -vmstat output. > > I forgot to voice my opinion on the mailing list, but I prefer the old way > too. I agree. The new way is a bit ambiguous and taken out of context it should be 19 stray cats, not stray irq19 :D. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r227951 - in head: . gnu/lib share/mk
On Thu, Nov 24, 2011 at 12:31 PM, Max Khon wrote:
> Author: fjoe
> Date: Thu Nov 24 20:31:06 2011
> New Revision: 227951
> URL: http://svn.freebsd.org/changeset/base/227951
>
> Log:
> libodialog: disconnect from the build and obsolete.
>
> Modified:
> head/ObsoleteFiles.inc
> head/gnu/lib/Makefile
> head/share/mk/bsd.libnames.mk
>
> Modified: head/ObsoleteFiles.inc
> ==
> --- head/ObsoleteFiles.inc Thu Nov 24 19:02:04 2011 (r227950)
> +++ head/ObsoleteFiles.inc Thu Nov 24 20:31:06 2011 (r227951)
> @@ -38,6 +38,17 @@
> # xargs -n1 | sort | uniq -d;
> # done
>
> +# 2025: libodialog removed
> +OLD_FILES+=usr/lib/libodialog.a
> +OLD_FILES+=usr/lib/libodialog.so
> +OLD_LIBS+=usr/lib/libodialog.so.7
> +OLD_FILES+=usr/lib/libodialog_p.a
> +.if ${TARGET_ARCH} == "amd64" || ${TARGET_ARCH} == "powerpc64"
> +OLD_FILES+=usr/lib32/libodialog.a
> +OLD_FILES+=usr/lib32/libodialog.so
> +OLD_LIBS+=usr/lib32/libodialog.so.7
> +OLD_FILES+=usr/lib32/libodialog_p.a
> +.endif
> # 20110930: sysinstall removed
> OLD_FILES+=usr/sbin/sysinstall
> OLD_FILES+=usr/share/man/man8/sysinstall.8.gz
>
> Modified: head/gnu/lib/Makefile
> ==
> --- head/gnu/lib/Makefile Thu Nov 24 19:02:04 2011 (r227950)
> +++ head/gnu/lib/Makefile Thu Nov 24 20:31:06 2011 (r227951)
> @@ -2,8 +2,7 @@
>
> .include
>
> -SUBDIR= csu libgcc libgcov libdialog libgomp libodialog libregex libreadline
> \
> - libssp
> +SUBDIR= csu libgcc libgcov libdialog libgomp libregex libreadline libssp
>
> # libsupc++ uses libstdc++ headers, although 'make includes' should
> # have taken care of that already.
>
> Modified: head/share/mk/bsd.libnames.mk
> ==
> --- head/share/mk/bsd.libnames.mk Thu Nov 24 19:02:04 2011
> (r227950)
> +++ head/share/mk/bsd.libnames.mk Thu Nov 24 20:31:06 2011
> (r227951)
> @@ -100,7 +100,6 @@ LIBNCURSESW?= ${DESTDIR}${LIBDIR}/libncu
> LIBNETGRAPH?= ${DESTDIR}${LIBDIR}/libnetgraph.a
> LIBNGATM?= ${DESTDIR}${LIBDIR}/libngatm.a
> LIBNVPAIR?= ${DESTDIR}${LIBDIR}/libnvpair.a
> -LIBODIALOG?= ${DESTDIR}${LIBDIR}/libodialog.a
> LIBOPIE?= ${DESTDIR}${LIBDIR}/libopie.a
tzsetup?
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r227951 - in head: . gnu/lib share/mk
On Thu, Nov 24, 2011 at 12:41 PM, Garrett Cooper wrote:
> On Thu, Nov 24, 2011 at 12:31 PM, Max Khon wrote:
>> Author: fjoe
>> Date: Thu Nov 24 20:31:06 2011
>> New Revision: 227951
>> URL: http://svn.freebsd.org/changeset/base/227951
>>
>> Log:
>> libodialog: disconnect from the build and obsolete.
>>
>> Modified:
>> head/ObsoleteFiles.inc
>> head/gnu/lib/Makefile
>> head/share/mk/bsd.libnames.mk
>>
>> Modified: head/ObsoleteFiles.inc
>> ==
>> --- head/ObsoleteFiles.inc Thu Nov 24 19:02:04 2011 (r227950)
>> +++ head/ObsoleteFiles.inc Thu Nov 24 20:31:06 2011 (r227951)
>> @@ -38,6 +38,17 @@
>> # xargs -n1 | sort | uniq -d;
>> # done
>>
>> +# 2025: libodialog removed
>> +OLD_FILES+=usr/lib/libodialog.a
>> +OLD_FILES+=usr/lib/libodialog.so
>> +OLD_LIBS+=usr/lib/libodialog.so.7
>> +OLD_FILES+=usr/lib/libodialog_p.a
>> +.if ${TARGET_ARCH} == "amd64" || ${TARGET_ARCH} == "powerpc64"
>> +OLD_FILES+=usr/lib32/libodialog.a
>> +OLD_FILES+=usr/lib32/libodialog.so
>> +OLD_LIBS+=usr/lib32/libodialog.so.7
>> +OLD_FILES+=usr/lib32/libodialog_p.a
>> +.endif
>> # 20110930: sysinstall removed
>> OLD_FILES+=usr/sbin/sysinstall
>> OLD_FILES+=usr/share/man/man8/sysinstall.8.gz
>>
>> Modified: head/gnu/lib/Makefile
>> ==
>> --- head/gnu/lib/Makefile Thu Nov 24 19:02:04 2011 (r227950)
>> +++ head/gnu/lib/Makefile Thu Nov 24 20:31:06 2011 (r227951)
>> @@ -2,8 +2,7 @@
>>
>> .include
>>
>> -SUBDIR= csu libgcc libgcov libdialog libgomp libodialog libregex
>> libreadline \
>> - libssp
>> +SUBDIR= csu libgcc libgcov libdialog libgomp libregex libreadline libssp
>>
>> # libsupc++ uses libstdc++ headers, although 'make includes' should
>> # have taken care of that already.
>>
>> Modified: head/share/mk/bsd.libnames.mk
>> ==
>> --- head/share/mk/bsd.libnames.mk Thu Nov 24 19:02:04 2011
>> (r227950)
>> +++ head/share/mk/bsd.libnames.mk Thu Nov 24 20:31:06 2011
>> (r227951)
>> @@ -100,7 +100,6 @@ LIBNCURSESW?= ${DESTDIR}${LIBDIR}/libncu
>> LIBNETGRAPH?= ${DESTDIR}${LIBDIR}/libnetgraph.a
>> LIBNGATM?= ${DESTDIR}${LIBDIR}/libngatm.a
>> LIBNVPAIR?= ${DESTDIR}${LIBDIR}/libnvpair.a
>> -LIBODIALOG?= ${DESTDIR}${LIBDIR}/libodialog.a
>> LIBOPIE?= ${DESTDIR}${LIBDIR}/libopie.a
>
> tzsetup?
Nevermind. Missed that commit..
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r227987 - in head: . lib share/mk
On Fri, Nov 25, 2011 at 7:26 PM, Dimitry Andric wrote: > Author: dim > Date: Sat Nov 26 03:26:06 2011 > New Revision: 227987 > URL: http://svn.freebsd.org/changeset/base/227987 > > Log: > Fix breakage after r227983; lib/libcxxrt still got built, because it was > not disabled in the usual way (by adding it to __DEFAULT_NO_OPTIONS in > share/mk/bsd.own.mk), and because the test for MK_LIBCPLUSPLUS in > Makefile.inc1 was incorrect. Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r227982 - in head: . release/doc/en_US.ISO8859-1/hardware share/man/man4 sys/conf sys/dev/amd sys/modules sys/modules/amd
On Fri, Nov 25, 2011 at 11:29 AM, Marius Strobl wrote: > Author: marius > Date: Fri Nov 25 19:29:21 2011 > New Revision: 227982 > URL: http://svn.freebsd.org/changeset/base/227982 > > Log: > Deorbit the broken amd(4) (see PR 124667), which was superseded by esp(4) > as of r227006. This commit broke tinderbox on i386/PAE and MIPS/OCTEON1. The following change should unbreak things if the driver compiles properly: Thanks, -Garrett $ svn diff `ls sys/*/conf/* | grep -v BAYONETTA` Index: sys/i386/conf/PAE === --- sys/i386/conf/PAE (revision 227998) +++ sys/i386/conf/PAE (working copy) @@ -24,7 +24,6 @@ # than 4 gigabytes of memory. nodevice ahb -nodevice amd nodevice sym nodevice trm Index: sys/mips/conf/OCTEON1 === --- sys/mips/conf/OCTEON1 (revision 227998) +++ sys/mips/conf/OCTEON1 (working copy) @@ -114,7 +114,7 @@ device ahd # AHA39320/29320 and onboard AIC79xx devices optionsAHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. -device amd # AMD 53C974 (Tekram DC-390(T)) +device esp # AMD Am53C974 (Tekram DC-390(T)) device hptiop # Highpoint RocketRaid 3xxx series device isp # Qlogic family #deviceispfw # Firmware for QLogic HBAs- normally a module ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r228124 - in head: share/mk sys/conf
On Tue, Nov 29, 2011 at 12:38 AM, Max Khon wrote: > Author: fjoe > Date: Tue Nov 29 08:38:47 2011 > New Revision: 228124 > URL: http://svn.freebsd.org/changeset/base/228124 > > Log: > Conditionalize ctfconvert/ctfmerge runs on make level (.if/.endif) instead > of executing a shell on every object or executable/library file. > > This shaves off more than 30,000 shell invocations during buildworld. Thank you Great minds truly do think alike. -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r228143 - in head: . share/mk tools/build/options
2011/11/29 Doug Barton : > On 11/29/2011 12:47, Gábor Kövesdán wrote: >> On 2011.11.29. 20:46, Max Khon wrote: >>> Log: >>> Turn off profiled libs build by default. >>> Can be enabled back using WITH_PROFILE=yes in /etc/src.conf >> I think it was useful. Profiling is useful for developing any piece of >> software that builds on libc or other common libs, even for software >> that is not directly related to FreeBSD. I think it should be reverted. > > Since we ask users to read -current, it would be useful if our > developers did too. :) > > As Max pointed out in his message about this, the profiled libs are only > really useful to a tiny percentage of developers. If you need them, > twist the knob. Building them should be off by default. +1. The needs of the many outweigh the needs of the few. As suggested elsewhere, I think it would also be a good idea to enable it in tinderbox builds. -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r228148 - head/sys/conf
On Wed, Nov 30, 2011 at 4:59 PM, Alexander Best wrote:
> On Tue Nov 29 11, John Baldwin wrote:
>> Author: jhb
>> Date: Tue Nov 29 21:28:48 2011
>> New Revision: 228148
>> URL: http://svn.freebsd.org/changeset/base/228148
>>
>> Log:
>> Remove a bit of debugging that accidentally crept in earlier.
>>
>> Modified:
>> head/sys/conf/newvers.sh
>>
>> Modified: head/sys/conf/newvers.sh
>> ==
>> --- head/sys/conf/newvers.sh Tue Nov 29 20:06:27 2011 (r228147)
>> +++ head/sys/conf/newvers.sh Tue Nov 29 21:28:48 2011 (r228148)
>> @@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin;
>> done
>>
>> if [ -n "$svnversion" ] ; then
>> - echo "$svnversion"
>> svn=`cd ${SYSDIR} && $svnversion`
>
> any chance we could replace $svnversion with something like the following:
>
> 'svn info|grep ^Revision|sed 's/^Revision: //'' ?
>
> this is much faster and the only downside seems to be the missing {MSP} at the
> end.
>
> running a standard hdd, svnversion takes almost half a minute, while the
> command above finishes in < 0.1 seconds.
We already hashed over that in the last discussion. svnversion was
picked because it iterates over the entire tree and you know for an
absolute fact that it's running versions X-Y-Z, instead of the version
of the Makefile being X.
Thanks,
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r228629 - head/usr.bin/gprof
On Sat, Dec 17, 2011 at 6:51 AM, Dimitry Andric wrote: > Author: dim > Date: Sat Dec 17 14:51:24 2011 > New Revision: 228629 > URL: http://svn.freebsd.org/changeset/base/228629 > > Log: > More fixes for correct printf length modifiers usr.bin/gprof. These fixes should be contributed upstream. Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r189263 - in head/usr.sbin/wpa: . hostapd hostapd_cli wpa_cli wpa_supplicant
On Mon, Dec 19, 2011 at 1:41 AM, Slawa Olhovchenkov wrote: > On Mon, Mar 02, 2009 at 02:28:22AM +, Sam Leffler wrote: > >> Author: sam >> Date: Mon Mar 2 02:28:22 2009 >> New Revision: 189263 >> URL: http://svn.freebsd.org/changeset/base/189263 >> >> Log: >> update to 0.6.8 >> >> Reviewed by: thompsa >> >> Modified: >> head/usr.sbin/wpa/Makefile.inc >> head/usr.sbin/wpa/hostapd/Makefile >> head/usr.sbin/wpa/hostapd/driver_freebsd.c >> head/usr.sbin/wpa/hostapd_cli/Makefile >> head/usr.sbin/wpa/wpa_cli/Makefile >> head/usr.sbin/wpa/wpa_supplicant/Makefile >> head/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c >> head/usr.sbin/wpa/wpa_supplicant/driver_wired.c >> Modified: head/usr.sbin/wpa/hostapd/Makefile >> == >> --- head/usr.sbin/wpa/hostapd/Makefile Mon Mar 2 02:26:53 2009 >> (r189262) >> +++ head/usr.sbin/wpa/hostapd/Makefile Mon Mar 2 02:28:22 2009 >> (r189263) > >> .if !empty(CFLAGS:M*-DEAP_SERVER) >> -SRCS+= eap.c eap_methods.c eap_identity.c >> +#SRCS+= eap.c eap_methods.c eap_identity.c > > EAP_SERVER functionality removed. Why? EAP support is only removed if -DEAP_SERVER isn't in CFLAGS (which seems like a bad idea because it should really be a bsd.own.mk knob). Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r189263 - in head/usr.sbin/wpa: . hostapd hostapd_cli wpa_cli wpa_supplicant
On Dec 19, 2011, at 11:14 AM, Slawa Olhovchenkov wrote: > On Mon, Dec 19, 2011 at 09:57:45AM -0800, Garrett Cooper wrote: > >> On Mon, Dec 19, 2011 at 1:41 AM, Slawa Olhovchenkov wrote: >>> On Mon, Mar 02, 2009 at 02:28:22AM +, Sam Leffler wrote: >>> >>>> Author: sam >>>> Date: Mon Mar 2 02:28:22 2009 >>>> New Revision: 189263 >>>> URL: http://svn.freebsd.org/changeset/base/189263 >>>> >>>> Log: >>>> update to 0.6.8 >>>> >>>> Reviewed by:thompsa >>>> >>>> Modified: >>>> head/usr.sbin/wpa/Makefile.inc >>>> head/usr.sbin/wpa/hostapd/Makefile >>>> head/usr.sbin/wpa/hostapd/driver_freebsd.c >>>> head/usr.sbin/wpa/hostapd_cli/Makefile >>>> head/usr.sbin/wpa/wpa_cli/Makefile >>>> head/usr.sbin/wpa/wpa_supplicant/Makefile >>>> head/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c >>>> head/usr.sbin/wpa/wpa_supplicant/driver_wired.c >>>> Modified: head/usr.sbin/wpa/hostapd/Makefile >>>> == >>>> --- head/usr.sbin/wpa/hostapd/MakefileMon Mar 2 02:26:53 2009 >>>>(r189262) >>>> +++ head/usr.sbin/wpa/hostapd/MakefileMon Mar 2 02:28:22 2009 >>>>(r189263) >>> >>>> .if !empty(CFLAGS:M*-DEAP_SERVER) >>>> -SRCS+= eap.c eap_methods.c eap_identity.c >>>> +#SRCS+= eap.c eap_methods.c eap_identity.c >>> >>> EAP_SERVER functionality removed. Why? >> >> EAP support is only removed if -DEAP_SERVER isn't in CFLAGS (which >> seems like a bad idea because it should really be a bsd.own.mk knob). > > Sorry, I don't understand. > Some time ago I have in src.conf HOSTAPD_CFLAGS=-DEAP_TLS -DEAP_SERVER > and got hostapd witch support EAP metods. Now this is don't work: > > ===> hostapd (all) > make: don't know how to make eap_tls.c. Stop > > How I can build hostapd witch support EAP metods? Missed the commenting out part of the commit. Yeah, that might not work. Thanks, -Garrett___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Mon, Dec 19, 2011 at 10:20 PM, Bruce Evans wrote: > On Mon, 19 Dec 2011, Warner Losh wrote: > >> On Nov 29, 2011, at 1:53 PM, Garrett Cooper wrote: >> >>> 2011/11/29 Doug Barton : >>>> >>>> On 11/29/2011 12:47, Gábor Kövesdán wrote: >>>>> >>>>> On 2011.11.29. 20:46, Max Khon wrote: >>>>>> >>>>>> Log: >>>>>> Turn off profiled libs build by default. >>>>>> Can be enabled back using WITH_PROFILE=yes in /etc/src.conf >>>>> >>>>> I think it was useful. Profiling is useful for developing any piece of >>>>> software that builds on libc or other common libs, even for software >>>>> that is not directly related to FreeBSD. I think it should be reverted. >>>> >>>> >>>> Since we ask users to read -current, it would be useful if our >>>> developers did too. :) >>>> >>>> As Max pointed out in his message about this, the profiled libs are only >>>> really useful to a tiny percentage of developers. If you need them, >>>> twist the knob. Building them should be off by default. >>> >>> >>> +1. The needs of the many outweigh the needs of the few. As suggested >>> elsewhere, I think it would also be a good idea to enable it in >>> tinderbox builds. >> >> >> -1. The needs of the many? Please. Let's break a useful feature because >> some people don't understand it and are impatient? That's lame. > > Don't be silly. Building profiled libraries takes as much as 1 minute. > Many would not want to wait that long (if they noticed how long it takes). > This is not 1994 when building of profiling libraries was left in because > it only took an extra hour or or so. The assumption (that isn't clearly stated) is that I am building things on suped up x86 hardware, not arm CPUs, Intel Atoms, etc. On those platforms building superfluous things still do matter (in particular because cross-building some things still isn't doable 100% of the time, but also because flash, some platter media, etc is slow). But I suppose I digress... Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Tue, Dec 20, 2011 at 2:18 AM, Andriy Gapon wrote: > on 20/12/2011 12:05 David Chisnall said the following: >> On 20 Dec 2011, at 06:20, Bruce Evans wrote: >> >>> Don't be silly. Building profiled libraries takes as much as 1 minute. >>> Many would not want to wait that long (if they noticed how long it takes). >>> This is not 1994 when building of profiling libraries was left in because >>> it only took an extra hour or or so. >> >> One of the platforms I use has an 800MHz ARM processor. Building LLVM (even >> a release build with asserts disabled and with all of the cross-compile >> targets disabled) is an overnight job. On my main laptop, a release build >> of LLVM takes about 5 minutes. >> >> Please don't assume that just because fast computers exist that they are the >> only things people are using. A lot of the more interesting platforms these >> days are significantly slower. > > I wonder if all the software that runs on the embedded stuff or mobile phones > is > built on the said hardware. world doesn't need to be built on the hardware, but ports still do. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Tue, Dec 20, 2011 at 9:40 AM, Warner Losh wrote: > > On Dec 20, 2011, at 2:21 AM, Garrett Cooper wrote: > > > The assumption (that isn't clearly stated) is that I am building > things on suped up x86 hardware, not arm CPUs, Intel Atoms, etc. On > those platforms building superfluous things still do matter (in > particular because cross-building some things still isn't doable 100% > of the time, but also because flash, some platter media, etc is slow). > But I suppose I digress... > > > When is cross building not doable? Please, give examples, not fud. ports. -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Tue, Dec 20, 2011 at 11:21 AM, Garrett Cooper wrote: > On Tue, Dec 20, 2011 at 9:40 AM, Warner Losh wrote: >> >> On Dec 20, 2011, at 2:21 AM, Garrett Cooper wrote: >> >> >> The assumption (that isn't clearly stated) is that I am building >> things on suped up x86 hardware, not arm CPUs, Intel Atoms, etc. On >> those platforms building superfluous things still do matter (in >> particular because cross-building some things still isn't doable 100% >> of the time, but also because flash, some platter media, etc is slow). >> But I suppose I digress... >> >> >> When is cross building not doable? Please, give examples, not fud. > > ports. Of course, now that I mention it, that's less relevant to this particular discussion. Please ignore above fud if you have access to fast Intel hardware. -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Tue, Dec 20, 2011 at 11:36 AM, Warner Losh wrote: > > On Dec 20, 2011, at 12:21 PM, Garrett Cooper wrote: > >> On Tue, Dec 20, 2011 at 9:40 AM, Warner Losh wrote: >>> >>> On Dec 20, 2011, at 2:21 AM, Garrett Cooper wrote: >>> >>> >>> The assumption (that isn't clearly stated) is that I am building >>> things on suped up x86 hardware, not arm CPUs, Intel Atoms, etc. On >>> those platforms building superfluous things still do matter (in >>> particular because cross-building some things still isn't doable 100% >>> of the time, but also because flash, some platter media, etc is slow). >>> But I suppose I digress... >>> >>> >>> When is cross building not doable? Please, give examples, not fud. >> >> ports. > > Which affects profiled libraries how? Please see later comment :/. -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Tue, Dec 20, 2011 at 8:55 PM, Steve Kargl wrote: > On Tue, Dec 20, 2011 at 06:45:07PM -0800, Doug Barton wrote: >> On 12/20/2011 18:29, Ben Kaduk wrote: >> > 2011/12/20 Doug Barton : >> >> On 12/20/2011 06:08, John Baldwin wrote: >> >>> The defaults for src.conf should be for the common case >> >> >> >> Agreed. The problem we seem to be missing here is that developers are >> >> not even statistically significant in measuring "the common case." >> > >> > "The common case" of what, though? "People using src.conf", or >> > "people rebuilding world", or just "people using FreeBSD"? >> >> The latter of course. The overwhelming majority of FreeBSD users will >> never use profiled libs, and in fact don't even know what they are. It's >> just useless space being taken up on every install. The defaults should >> be sensible for our users. > > OK, Doug, we get it! You don't like profiled libraries. > You don't use them, and by extension the 'common user' > does not use them. The point that I was trying to drive home (that I think Doug is as well) is: - How many FreeBSD users are developers/performance/test engineers who care about this stuff being compiled into the base system? - How many developers use gprof / profiled libraries? - How many developers reroll their world by turning on WITH_PROFILE ? - How often do you use gprof to profile binaries? Smart defaults and better tuning are what we ultimately should be striving for, because again, WITH_PROFILE is a developer and not a end-user / administrator convenience. Those are the individuals we should be tailoring FreeBSD for -- not developers. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r228990 - in head/usr.sbin: IPXrouted adduser bluetooth/btpand bluetooth/sdpd bootparamd/bootparamd bsnmpd/modules/snmp_bridge bsnmpd/modules/snmp_hostres bsnmpd/modules/snmp_wlan bsnm
2011/12/30 Alexey Dokuchaev : > On Fri, Dec 30, 2011 at 02:43:22PM -0500, Ben Kaduk wrote: >> On Fri, Dec 30, 2011 at 5:58 AM, Ulrich Spoerlein wrote: >> > - * is 11 bit wide that gives us upto 2048 chunks. >> > + * is 11 bit wide that gives us up to 2048 chunks. >> >> Should be "11 bits", no? > > I'm not a native speaker, but I think "11 bit wide" is correct here. I > could have probably got into specifics, but simple googling for "16 ton shit > dropped on me" yielded 525M results, while the same phrase with "tons" only > 18,9M. :-^ bits is correct because it's the plural form of the word, but the sentence sounds off even with that change. This sounds better: "is 11-bits wide, which gives us up to 2048 chunks" The only question that lingers in my mind, is what does "chunks" qualify (buffer chunks? chunks of gold? chunks of rocca chocolate bars? etc)? Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r228711 - head/sys/dev/usb/controller
On Mon, Dec 19, 2011 at 7:35 AM, Hans Petter Selasky
wrote:
> Author: hselasky
> Date: Mon Dec 19 15:35:05 2011
> New Revision: 228711
> URL: http://svn.freebsd.org/changeset/base/228711
>
> Log:
> Add code to wait for USB shutdown to be executed at system shutdown.
> Add sysctl which can be used to skip this waiting.
>
> MFC after: 3 days
>
> Modified:
> head/sys/dev/usb/controller/usb_controller.c
>
> Modified: head/sys/dev/usb/controller/usb_controller.c
> ==
> --- head/sys/dev/usb/controller/usb_controller.c Mon Dec 19 14:55:14
> 2011 (r228710)
> +++ head/sys/dev/usb/controller/usb_controller.c Mon Dec 19 15:35:05
> 2011 (r228711)
> @@ -87,7 +87,12 @@ SYSCTL_INT(_hw_usb_ctrl, OID_AUTO, debug
> static int usb_no_boot_wait = 0;
> TUNABLE_INT("hw.usb.no_boot_wait", &usb_no_boot_wait);
> SYSCTL_INT(_hw_usb, OID_AUTO, no_boot_wait, CTLFLAG_RDTUN,
> &usb_no_boot_wait, 0,
> - "No device enumerate waiting at boot.");
> + "No USB device enumerate waiting at boot.");
> +
> +static int usb_no_shutdown_wait = 0;
> +TUNABLE_INT("hw.usb.no_shutdown_wait", &usb_no_shutdown_wait);
> +SYSCTL_INT(_hw_usb, OID_AUTO, no_shutdown_wait, CTLFLAG_RDTUN,
> &usb_no_shutdown_wait, 0,
> + "No USB device waiting at system shutdown.");
>
> static devclass_t usb_devclass;
>
> @@ -277,11 +282,20 @@ usb_shutdown(device_t dev)
> return (0);
> }
>
> + device_printf(bus->bdev, "Controller shutdown\n");
> +
> USB_BUS_LOCK(bus);
> usb_proc_msignal(&bus->explore_proc,
> &bus->shutdown_msg[0], &bus->shutdown_msg[1]);
> + if (usb_no_shutdown_wait == 0) {
> + /* wait for shutdown callback to be executed */
> + usb_proc_mwait(&bus->explore_proc,
> + &bus->shutdown_msg[0], &bus->shutdown_msg[1]);
> + }
> USB_BUS_UNLOCK(bus);
>
> + device_printf(bus->bdev, "Controller shutdown complete\n");
> +
These printouts are a bit chatty. Could they be put under USB_DEBUG ?
Thanks!
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r229430 - in head/sys: conf dev/sound/pci modules/sound/driver/emu10k1
On Tue, Jan 3, 2012 at 2:16 PM, Pedro Giffuni wrote: > Hi; > > --- Mar 3/1/12, John Baldwin ha scritto: > ... >> On Tuesday, January 03, 2012 4:04:54 >> pm Pedro F. Giffuni wrote: >> > Author: pfg >> > Date: Tue Jan 3 21:04:54 2012 >> > New Revision: 229430 >> > URL: http://svn.freebsd.org/changeset/base/229430 >> > >> > Log: >> > Replace a GPL'd header in the emu10k1 >> snd driver code. >> > >> > This brings in the emuxkireg.h from >> NetBSD (dev/pci) which >> > is used for the same purpose but is >> smaller. The emu10k1 >> > is now free from the GPL. >> >> Is this a common-enough chipset to enable in GENERIC now >> that it is safe to do so? >> > > It's probably very common in PC emulators so it will be > important to MFC into stable. > > FWIW, two other cards (maestro3 and csaimg) are based on > headers from OSS that are now under a BSD license. > > The maestro3 is done (kern/153920) and is next in my > list but it's getting difficult to find testers for > this old stuff. Can the same be done for emu10kx ? Someday it would be nice to have xfi support in the tree, but that's a missing driver that even the OSS maintainer was scared to touch because of the complexity of the code. Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r229430 - in head/sys: conf dev/sound/pci modules/sound/driver/emu10k1
On Tue, Jan 3, 2012 at 2:44 PM, Pedro Giffuni wrote: > > > --- Mar 3/1/12, Garrett Cooper ha scritto: > ... >> >> Can the same be done for emu10kx ? >> > No :(. The two extra headers are GPL'd and the author doesn't > want to hear about BSDs. > >> Someday it would be nice to have xfi support in the tree, >> but that's a missing driver that even the OSS maintainer >> was scared to touch because of the complexity of the code. >> > > Apparently Creative released a GPLd driver for linux(ALSA), > but it was not in working shape. The ALSA driver worked back when I tried it out 2 years ago. I asked for them to release an OSS version, but of course they ignored by request, then some months later released an ALSA version. There's a preliminary xfi driver in OSS 4.x (and OSS still has a BSD compatible license), but it's far from complete [and the author is aware of this :)]. Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r229430 - in head/sys: conf dev/sound/pci modules/sound/driver/emu10k1
On Wed, Jan 4, 2012 at 6:43 AM, Alexander Motin wrote: > On 01/04/12 16:25, Pedro Giffuni wrote: >> >> --- Mer 4/1/12, Alexey Dokuchaev ha scritto: >> ... The only issue is getting rid of the remaining >>> >>> (small) GPL'd headers. Alternatively this driver is already >>> >>> available as a port (audio/emu10kx). >>> >>> >>> Yes, I am aware of the port existence. My point was >>> to leave just one, BSD licensed, full featured emu10k >>> driver in the base (i.e. merge emu10k1 and >>> emu10kx into one). Good to know that you're up to >>> this; I hope we'll get there eventually. :-) >> >> >> Well, when I made the changes for emu10k1 it was easy >> to do them for emu10kx too but I don't have the card so I >> am not really up to it (sorry). >> >> I will be glad to help if someone else is interested. > > > I have Audigy2ZS (model SB0350) in my table if any help with testing needed, > but I've never looked into emu10k code, preferring to hack more widespread > and documented HDA. I have an Audigy 4 I can slap into the machine at work. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r229667 - head/usr.sbin/daemon
On Thu, Jan 5, 2012 at 6:58 PM, Doug Barton wrote: > On 01/05/2012 14:48, Guy Helmer wrote: >> Allow daemon(8) to run pidfile_open() before relenquishing privileges >> so pid files can be written in /var/run when started as root. > > I'm not sure how useful this is since when daemon is exiting it won't be > able to remove the pid file (unless I'm missing something). > > Isn't it better to pre-create the pid file with the proper permissions > for the unprivileged user? As another aside, the file descriptor never has fcntl(, FD_CLOEXEC) run on it, so it leaks the file descriptors across execs.. that's not good... Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r228939 - head/sys/dev/mps
2012/1/9 Alexander Motin :
> On 09.01.2012 20:54, Maksim Yevmenkin wrote:
>>
>> On Wed, Dec 28, 2011 at 2:49 PM, Alexander Motin wrote:
>>
>>> Author: mav
>>> Date: Wed Dec 28 22:49:28 2011
>>> New Revision: 228939
>>> URL: http://svn.freebsd.org/changeset/base/228939
>>>
>>> Log:
>>> Set maximum I/O size for mps(4) to MAXPHYS. Looking into the code, I see
>>> no reason why it should be limited to 64K of DFLTPHYS. DMA data tag is
>>> any
>>> way set to allow MAXPHYS, S/G lists (chain elements) are sufficient and
>>> overflows are also handled. On my tests even 1MB I/Os are working fine.
>>>
>>> Reviewed by: ken@
>>>
>>> Modified:
>>> head/sys/dev/mps/mps_sas.c
>>>
>>> Modified: head/sys/dev/mps/mps_sas.c
>>>
>>> ==
>>> --- head/sys/dev/mps/mps_sas.c Wed Dec 28 22:18:53 2011 (r228938)
>>> +++ head/sys/dev/mps/mps_sas.c Wed Dec 28 22:49:28 2011 (r228939)
>>> @@ -937,6 +937,7 @@ mpssas_action(struct cam_sim *sim, union
>>> cpi->transport_version = 0;
>>> cpi->protocol = PROTO_SCSI;
>>> cpi->protocol_version = SCSI_REV_SPC;
>>> + cpi->maxio = MAXPHYS;
>>> cpi->ccb_h.status = CAM_REQ_CMP;
>>> break;
>>> }
>>
>>
>> sorry for the late reply, but can we make in into tunable please? i
>> have in local tree
>>
>> --- mps_sas.c.orig 2011-11-17 02:05:04.0 -0800
>> +++ mps_sas.c 2011-12-28 16:05:10.0 -0800
>> @@ -121,6 +121,11 @@
>>
>> MALLOC_DEFINE(M_MPSSAS, "MPSSAS", "MPS SAS memory");
>>
>> +int mps_maxio = MAXPHYS;
>> +TUNABLE_INT("hw.mps.maxio",&mps_maxio);
>> +SYSCTL_INT(_hw_mps, OID_AUTO, maxio, CTLFLAG_RD,&mps_maxio, 0,
>> + "CAM maxio override\n");
>> +
>> static __inline int mpssas_set_lun(uint8_t *lun, u_int ccblun);
>> static struct mpssas_target * mpssas_alloc_target(struct mpssas_softc *,
>> struct mpssas_target *);
>> @@ -938,6 +943,7 @@
>>
>> cpi->protocol = PROTO_SCSI;
>> cpi->protocol_version = SCSI_REV_SPC;
>> cpi->ccb_h.status = CAM_REQ_CMP;
>> + cpi->maxio = mps_maxio;
>> break;
>> }
>> case XPT_GET_TRAN_SETTINGS:
>
>
> We can. but could you explain why? Have you found any problems this change?
It would make it nice when dealing with different controllers -- a
similar example is that mfi(4) has a tunable called hw.mfi.max_cmds
which controls the I/O command queue size as not all MegaRAID cards
have the same I/O queue size capabilities.
Thanks,
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r229667 - head/usr.sbin/daemon
On Tue, Jan 10, 2012 at 1:01 PM, Guy Helmer wrote: > On Jan 6, 2012, at 12:00 AM, Garrett Cooper wrote: > >> On Thu, Jan 5, 2012 at 6:58 PM, Doug Barton wrote: >>> On 01/05/2012 14:48, Guy Helmer wrote: >>>> Allow daemon(8) to run pidfile_open() before relenquishing privileges >>>> so pid files can be written in /var/run when started as root. >>> >>> I'm not sure how useful this is since when daemon is exiting it won't be >>> able to remove the pid file (unless I'm missing something). >>> >>> Isn't it better to pre-create the pid file with the proper permissions >>> for the unprivileged user? >> >> As another aside, the file descriptor never has fcntl(, >> FD_CLOEXEC) run on it, so it leaks the file descriptors across execs.. >> that's not good... > > I just added an fcntl(…, FD_CLOEXEC) call to pidfile_open() so this > particular problem should be resolved. I saw -- thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r229981 - in head/sys: conf dev/sound/pci gnu/dev/sound/pci modules/sound/driver/emu10kx
On Jan 12, 2012, at 11:33 AM, Pedro Giffuni wrote: > Hello; > > --- Gio 12/1/12, John Baldwin ha scritto: > >> Da: John Baldwin >> Oggetto: Re: svn commit: r229981 - in head/sys: conf dev/sound/pci >> gnu/dev/sound/pci modules/sound/driver/emu10kx >> A: "Pedro F. Giffuni" >> Cc: src-committ...@freebsd.org, svn-src-...@freebsd.org, >> svn-src-head@freebsd.org, j...@freebsd.org >> Data: Giovedì 12 gennaio 2012, 07:43 >> On Wednesday, January 11, 2012 >> 4:17:14 pm Pedro F. Giffuni wrote: >>> Author: pfg >>> Date: Wed Jan 11 21:17:14 2012 >>> New Revision: 229981 >>> URL: http://svn.freebsd.org/changeset/base/229981 >>> > ... >>>The emu10kx driver is now free from the GPL. >>> >>>PR:153901 >>>Tested by:mav, joel >>>Approved by:jhb (mentor) >>>MFC after:2 weeks >> >> Is the emu10kx driver a superset of em10k1 now (meaning >> does it support all >> the em10k1 devices and should em10k1 be retired)? >> > > Both device drivers seem to have diverged significantly > and while emu10kx seems to be superior, some people still > have problems with it: > > http://docs.freebsd.org/cgi/mid.cgi?201201100024.q0A0OF24069073 > > so I suggest we keep both at least for a while. > >> Also, it seems we should definitely add 'snd_emu10kx' to >> GENERIC on x86 and possible 'snd_emu10k1'. >> SB Audigy chipsets are also treated differently for both cases. My Audigy 4 card for instance is detected with both drivers, but only the 10kx driver works with the card; similarly IIRC there are some things that work with the 10k1 driver that don't work the same with the 10kx. So while this would be nice to have, I'm not sure if it's an effective use of FreeBSD's time to invest in as these chipsets are effectively obsolete. Thanks! -Garrett___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r230103 - head/etc
On Jan 14, 2012, at 1:18 AM, Andriy Gapon wrote: > on 14/01/2012 11:17 Doug Barton said the following: >> On 01/14/2012 01:10, Andriy Gapon wrote: >>> on 14/01/2012 10:59 Doug Barton said the following: Author: dougb Date: Sat Jan 14 08:59:02 2012 New Revision: 230103 URL: http://svn.freebsd.org/changeset/base/230103 Log: Now that its callers have been udpated, remove set_rcvar(). The concept of set_rcvar() was nice in theory, but the forks it creates are a drag on the startup process, which is especially noticeable on slower systems, such as embedded ones. >>> >>> Will this break ports that install rc.d scripts? >> >> Please see my HEADS UP message to -current. > > Thank you. Adding an entry to UPDATING would be appreciated though… Thanks, -Garrett___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r230353 - head/usr.sbin/makefs
On Tue, Jan 24, 2012 at 9:35 PM, Andreas Tobler wrote: > ... > It is actually r230354, this is the commit which shows the failure. > And I reverted back to 230353 and onfirmed that it 'works'. > > I additionally built with -O0 -g, see below. > > If you need more details, I'll be out the next 15h but later on I can > continue. > > Thank you very much! > Andreas > > Here the output from the binary built with "-g": > -- > [andreast@tcx58] /export/home/andreast/> printf "run -t cd9660 -o chrp-boot > -o rockridge -o label=pseries -B4321 p.iso /export/netboot/powerpc64/\nbt\nf > 1\n f 2\n" | gdb -x /dev/stdin -batch /usr/sbin/makefs ... > delete_chars); 1. What does 'list' say for that frame (the line numbers are misleading)? 2. What compiler are you using to compile the binary? Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r221604 - head/usr.sbin/usbdump
On Sat, May 7, 2011 at 10:13 AM, wrote: > On Sat, May 7, 2011 at 9:36 AM, Hans Petter Selasky wrote: >> On Saturday 07 May 2011 18:28:24 Hans Petter Selasky wrote: >>> - Use memcpy() instead of bcopy(). >> >> - Use memset() instead of bzero(). > > Why? It usually falls through to the same code in libc. Is there > some standardization on memfoo versus bfoo here? bfoo is marked legacy per POSIX 2001.1; example: http://pubs.opengroup.org/onlinepubs/009695399/functions/bcopy.html . A lot of folks (Linux leading the charge) are actively working to deprecate the APIs. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r221789 - in head/sys/dev: ahci ata ata/chipsets ichsmb ichwd sound/pci/hda
On May 11, 2011, at 4:31 PM, Jack F Vogel wrote:
> +#define HDA_INTEL_PPT1 HDA_MODEL_CONSTRUCT(INTEL, 0x1e20)
Is this a typo?
> #define HDA_INTEL_82801F HDA_MODEL_CONSTRUCT(INTEL, 0x2668)
> #define HDA_INTEL_63XXESB HDA_MODEL_CONSTRUCT(INTEL, 0x269a)
> #define HDA_INTEL_82801G HDA_MODEL_CONSTRUCT(INTEL, 0x27d8)
> @@ -495,6 +496,7 @@ static const struct {
> } hdac_devices[] = {
> { HDA_INTEL_CPT, "Intel Cougar Point", 0 },
> { HDA_INTEL_PATSBURG,"Intel Patsburg", 0 },
> + { HDA_INTEL_PPT, "Intel Panther Point", 0 },
> { HDA_INTEL_82801F, "Intel 82801F",0 },
> { HDA_INTEL_63XXESB, "Intel 631x/632xESB", 0 },
> { HDA_INTEL_82801G, "Intel 82801G",0 },
Thanks,
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r222051 - in head/sys/dev: sound/usb usb usb/input usb/storage
On Wed, May 18, 2011 at 4:20 AM, Hans Petter Selasky wrote: > On Wednesday 18 May 2011 09:40:12 Andriy Gapon wrote: >> Author: avg >> Date: Wed May 18 07:40:12 2011 >> New Revision: 222051 >> URL: http://svn.freebsd.org/changeset/base/222051 >> >> Log: >> usb: change to one-pass probing of device drivers >> >> This brings USB bus more in line with how newbus is supposed to be used. >> Also, because of the two-pass probing the following message was produced >> by devd in default configuration when almost any USB device was >> connected: >> Unknown USB device: vendor <> product <> bus <> >> This should be fixed now. >> >> Note that many USB device drivers pass some information from probe >> method to attach method via ivars. For this to continue working we rely >> on the fact that the subr_bus code calls probe method of a winning driver >> again before calling its attach method in the case where multiple >> drivers claim to support a device. This is done because device >> description is set in successful probe methods and we want to get a >> correct device description from a winning driver. So now this logic is >> re-used for setting ivars too. >> >> Reviewed by: hselasky >> MFC after: 1 month >> >> Modified: >> head/sys/dev/sound/usb/uaudio.c >> head/sys/dev/usb/input/uhid.c >> head/sys/dev/usb/input/ukbd.c >> head/sys/dev/usb/input/ums.c >> head/sys/dev/usb/storage/umass.c >> head/sys/dev/usb/storage/ustorage_fs.c >> head/sys/dev/usb/usb_device.c >> head/sys/dev/usb/usbdi.h >> > > Looks like you missed ng_ubt.c. Just do a "grep -r" for the replaced fields. The patch I sent offline to you guys was the only affected file based on a grep around /sys/... ; I based my patch on other code patterns in this commit. Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r222078 - head/usr.sbin/pc-sysinstall/backend
On Wed, May 18, 2011 at 1:29 PM, Josh Paetzel wrote:
> Author: jpaetzel
> Date: Wed May 18 20:29:07 2011
> New Revision: 222078
> URL: http://svn.freebsd.org/changeset/base/222078
>
> Log:
> Extracting optional components requires mounting devfs
>
> Submitted by: Kris Moore
> Approved by: kib (mentor)
> Sponsored by: iXsystems
>
> Modified:
> head/usr.sbin/pc-sysinstall/backend/functions-installcomponents.sh
>
> Modified: head/usr.sbin/pc-sysinstall/backend/functions-installcomponents.sh
> ==
> --- head/usr.sbin/pc-sysinstall/backend/functions-installcomponents.sh Wed
> May 18 19:49:39 2011 (r222077)
> +++ head/usr.sbin/pc-sysinstall/backend/functions-installcomponents.sh Wed
> May 18 20:29:07 2011 (r222078)
> @@ -120,9 +120,11 @@ COMPTMPDIR=\"${COMPTMPDIR}\"
> export COMPTMPDIR
> CFILE=\"${CFILE}\"
> export CFILE
> +mount -t devfs devfs /dev
>
> sh ${COMPTMPDIR}/install.sh
>
> +umount /dev
> " >${FSMNT}/.componentwrapper.sh
> chmod 755 ${FSMNT}/.componentwrapper.sh
Is pc-sysinstall run with set -e anywhere?
Thanks!
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r222094 - head/share/misc
On May 19, 2011, at 6:09 AM, Edwin Groothuis wrote: > Author: edwin > Date: Thu May 19 13:09:39 2011 > New Revision: 222094 > URL: http://svn.freebsd.org/changeset/base/222094 > > Log: > Put AN back after finding out that tzsetup(1) will complain that > it doesn't exist. It will be removed again once the tzdata distribution > files have been updated with the replacements for AN. > > Modified: > head/share/misc/iso3166 > > Modified: head/share/misc/iso3166 > == > --- head/share/misc/iso3166Thu May 19 11:41:12 2011(r222093) > +++ head/share/misc/iso3166Thu May 19 13:09:39 2011(r222094) > @@ -176,6 +176,7 @@ NANAM516Namibia > NRNRU520Nauru > NPNPL524Nepal > NLNLD528Netherlands > +ANANT530Netherlands Antilles > NCNCL540New Caledonia > NZNZL554New Zealand > NINIC558Nicaragua Thanks! -Garrett___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r222511 - head/lib/libc/gen
On Mon, May 30, 2011 at 2:41 PM, Jilles Tjoelker wrote: > Author: jilles > Date: Mon May 30 21:41:06 2011 > New Revision: 222511 > URL: http://svn.freebsd.org/changeset/base/222511 > > Log: > posix_spawn(): Do not fail when trying to close an fd that is not open. > > As noted in Austin Group issue #370 (an interpretation has been issued), > failing posix_spawn() because an fd specified with > posix_spawn_file_actions_addclose() is not open is unnecessarily harsh, and > there are existing implementations that do not fail posix_spawn() for this > reason. ... The manpage should probably be updated: 5. If the file_actions argument is not NULL, and specifies any close, dup2, or open actions to be performed, and if posix_spawn() or posix_spawnp() fails for any of the reasons that would cause close(), dup2(), or open() to fail, an error value is returned as described by close(), dup2(), and open(), respectively (or, if the error occurs after the calling process successfully returns, the child process exits with exit status 127). An open file action may, by itself, result in any of the errors described by close() or dup2(), in addition to those described by open(). ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r222537 - in head/sys: kern sys
On Tue, May 31, 2011 at 2:00 PM, wrote: > On Tue, May 31, 2011 at 10:29 AM, Kenneth D. Merry wrote: >> Author: ken >> Date: Tue May 31 17:29:58 2011 >> New Revision: 222537 >> URL: http://svn.freebsd.org/changeset/base/222537 >> >> Log: >> Fix apparent garbage in the message buffer. >> >> While we have had a fix in place (options PRINTF_BUFR_SIZE=128) to fix >> scrambled console output, the message buffer and syslog were still getting >> log messages one character at a time. While all of the characters still >> made it into the log (courtesy of atomic operations), they were often >> interleaved when there were multiple threads writing to the buffer at the >> same time. > > This seems to panic my box with "lock "msgbuf" 0xfe0127e0 > already initialized". > > Unfortunately, though I booted with a fresh CURRENT this morning > successfully, both /boot/kernel and /boot/kernel.old give this panic. > To add insult to injury, when the kernel drops into the debugger, my > keyboard input no longer works so I can't get a stack, etc. > > So: > > 1) Is there anything else I can do to help debug this? 1. sysctl debug.debugger_on_panic=1 ? > 2) how can I resurrect this box without a reinstall? 2. Best way is to probably to use the bsdinstall CD, use the LiveCD mode, setup the system as usual (mount /, mount devfs, chroot, mount -a), rewind to an earlier version of svn (shouldn't be too hard if you run /etc/rc.d/network restart from inside the chroot), rebuild the kernel (and potentially world), and install the kernel to the chroot, then exit and reboot (this is a method I picked up from installing Gentoo Linux multiple times, but it should work for FreeBSD as well). This is part of the reason why I'm an avid using of make installkernel INSTKERNNAME=$KERNCONF.$SVN_REVISION , symlink /boot/kernel to the latest one I want to boot, and I only go through every once in a blue moon to reap the kernels I don't need anymore -- I don't know until after a few weeks soak on my workstation whether or not a regression is present in the kernel. > I will try to repro on a virtual machine so I have a snapshot to come back to. HTH! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r222537 - in head/sys: kern sys
On Tue, May 31, 2011 at 2:14 PM, Garrett Cooper wrote: > On Tue, May 31, 2011 at 2:00 PM, wrote: >> On Tue, May 31, 2011 at 10:29 AM, Kenneth D. Merry wrote: >>> Author: ken >>> Date: Tue May 31 17:29:58 2011 >>> New Revision: 222537 >>> URL: http://svn.freebsd.org/changeset/base/222537 >>> >>> Log: >>> Fix apparent garbage in the message buffer. >>> >>> While we have had a fix in place (options PRINTF_BUFR_SIZE=128) to fix >>> scrambled console output, the message buffer and syslog were still getting >>> log messages one character at a time. While all of the characters still >>> made it into the log (courtesy of atomic operations), they were often >>> interleaved when there were multiple threads writing to the buffer at the >>> same time. >> >> This seems to panic my box with "lock "msgbuf" 0xfe0127e0 >> already initialized". >> >> Unfortunately, though I booted with a fresh CURRENT this morning >> successfully, both /boot/kernel and /boot/kernel.old give this panic. >> To add insult to injury, when the kernel drops into the debugger, my >> keyboard input no longer works so I can't get a stack, etc. >> >> So: >> >> 1) Is there anything else I can do to help debug this? > > 1. sysctl debug.debugger_on_panic=1 ? Sorry.. I meant 'debug.debugger_on_panic=0'. >> 2) how can I resurrect this box without a reinstall? > > 2. Best way is to probably to use the bsdinstall CD, use the LiveCD > mode, setup the system as usual (mount /, mount devfs, chroot, mount > -a), rewind to an earlier version of svn (shouldn't be too hard if you > run /etc/rc.d/network restart from inside the chroot), rebuild the > kernel (and potentially world), and install the kernel to the chroot, > then exit and reboot (this is a method I picked up from installing > Gentoo Linux multiple times, but it should work for FreeBSD as well). > > This is part of the reason why I'm an avid using of make installkernel > INSTKERNNAME=$KERNCONF.$SVN_REVISION , symlink /boot/kernel to the > latest one I want to boot, and I only go through every once in a blue > moon to reap the kernels I don't need anymore -- I don't know until > after a few weeks soak on my workstation whether or not a regression > is present in the kernel. > >> I will try to repro on a virtual machine so I have a snapshot to come back >> to. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r222732 - in head: sys/netinet usr.sbin/rtadvd usr.sbin/rtsold
On Mon, Jun 6, 2011 at 1:21 PM, Warner Losh wrote: > > On Jun 6, 2011, at 8:02 AM, Jaakko Heinonen wrote: > >> On 2011-06-06, Hiroki Sato wrote: >>> di> > -WARNS?= 1 >>> di> > +WARNS?= 6 >> >> Shouldn't you just remove the WARNS line because the default for >> usr.sbin/ is 6? > > No, the change should be reverted, since it breaks ARM. ... and ia64. Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r222801 - in head/sys: ddb kern sys
On Mon, Jun 6, 2011 at 6:28 PM, Marcel Moolenaar wrote: > Author: marcel > Date: Tue Jun 7 01:28:12 2011 > New Revision: 222801 > URL: http://svn.freebsd.org/changeset/base/222801 > > Log: > Fix making kernel dumps from the debugger by creating a command > for it. Do not not expect a developer to call doadump(). Calling > doadump does not necessarily work when it's declared static. Nor > does it necessarily do what was intended in the context of text > dumps. The dump command always creates a core dump. > > Move printing of error messages from doadump to the dump command, > now that we don't have to worry about being called from DDB. > > Modified: > head/sys/ddb/db_command.c > head/sys/kern/kern_shutdown.c > head/sys/sys/conf.h You rock Marcel! Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r222515 - in head/etc: . defaults
On Mon, May 30, 2011 at 5:25 PM, Bjoern A. Zeeb wrote: > Author: bz > Date: Tue May 31 00:25:52 2011 > New Revision: 222515 > URL: http://svn.freebsd.org/changeset/base/222515 > > Log: > No logner set an IPv4 loopback address by default in defaults/rc.conf. > If not specified, network.subr will add it automatically if we have > INET support (1). > > In network.subr only call the address family up/down functions > if the respective AF is available. > > Switch to new kern.features variables for inet and inet6 as the > inet sysctl tree is also available for IPv6-only kernels leading > to unexpected results. Please document this change in UPDATING (requiring ifconfig_lo0 in rc.conf). It breaks standard IPv4 only configurations out of the box. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r222515 - in head/etc: . defaults
On Sat, Jun 11, 2011 at 3:22 AM, Garrett Cooper wrote:
> On Mon, May 30, 2011 at 5:25 PM, Bjoern A. Zeeb wrote:
>> Author: bz
>> Date: Tue May 31 00:25:52 2011
>> New Revision: 222515
>> URL: http://svn.freebsd.org/changeset/base/222515
>>
>> Log:
>> No logner set an IPv4 loopback address by default in defaults/rc.conf.
>> If not specified, network.subr will add it automatically if we have
>> INET support (1).
>>
>> In network.subr only call the address family up/down functions
>> if the respective AF is available.
>>
>> Switch to new kern.features variables for inet and inet6 as the
>> inet sysctl tree is also available for IPv6-only kernels leading
>> to unexpected results.
>
> Please document this change in UPDATING (requiring ifconfig_lo0 in
> rc.conf). It breaks standard IPv4 only configurations out of the box.
Oh that's right... feature_present("inet") doesn't work for me for
some bloody reason -_-...
Arg.
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r223056 - head/etc/periodic/daily
On Mon, Jun 13, 2011 at 12:45 PM, Josh Paetzel wrote: > Author: jpaetzel > Date: Mon Jun 13 19:45:01 2011 > New Revision: 223056 > URL: http://svn.freebsd.org/changeset/base/223056 > > Log: > Convert the allowed characters '-', '.', and ':' in a ZFS pool name to _ > to avoid causing errors in the shell script. This could be done like: sed -E -e 's/[-\.:]/_/g' to avoid the need for pipelining multiple tr calls. Example: $ echo :-. | sed -E -e 's/[-\.:]/_/g' ___ $ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r223139 - head/lib/libstand
On Thu, Jun 16, 2011 at 12:14 AM, Tai-hwa Liang wrote:
> Author: avatar
> Date: Thu Jun 16 07:14:55 2011
> New Revision: 223139
> URL: http://svn.freebsd.org/changeset/base/223139
>
> Log:
> Unbreaking build on sparc64.
>
> Submitted by: Garrett Cooper
>
> Modified:
> head/lib/libstand/zalloc.c
>
> Modified: head/lib/libstand/zalloc.c
> ==
> --- head/lib/libstand/zalloc.c Thu Jun 16 05:26:03 2011 (r223138)
> +++ head/lib/libstand/zalloc.c Thu Jun 16 07:14:55 2011 (r223139)
> @@ -154,7 +154,7 @@ zfree(MemPool *mp, void *ptr, iaddr_t by
> if ((char *)ptr < (char *)mp->mp_Base ||
> (char *)ptr + bytes > (char *)mp->mp_End ||
> ((iaddr_t)ptr & MEMNODE_SIZE_MASK) != 0)
> - panic("zfree(%p,%d): wild pointer", ptr, bytes);
> + panic("zfree(%p,%ju): wild pointer", ptr, bytes);
All of those need to be cast to (uintmax_t). Sorry :(..
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r223139 - head/lib/libstand
On Thu, Jun 16, 2011 at 12:19 AM, Garrett Cooper wrote:
> On Thu, Jun 16, 2011 at 12:14 AM, Tai-hwa Liang wrote:
>> Author: avatar
>> Date: Thu Jun 16 07:14:55 2011
>> New Revision: 223139
>> URL: http://svn.freebsd.org/changeset/base/223139
>>
>> Log:
>> Unbreaking build on sparc64.
>>
>> Submitted by: Garrett Cooper
>>
>> Modified:
>> head/lib/libstand/zalloc.c
>>
>> Modified: head/lib/libstand/zalloc.c
>> ==
>> --- head/lib/libstand/zalloc.c Thu Jun 16 05:26:03 2011 (r223138)
>> +++ head/lib/libstand/zalloc.c Thu Jun 16 07:14:55 2011 (r223139)
>> @@ -154,7 +154,7 @@ zfree(MemPool *mp, void *ptr, iaddr_t by
>> if ((char *)ptr < (char *)mp->mp_Base ||
>> (char *)ptr + bytes > (char *)mp->mp_End ||
>> ((iaddr_t)ptr & MEMNODE_SIZE_MASK) != 0)
>> - panic("zfree(%p,%d): wild pointer", ptr, bytes);
>> + panic("zfree(%p,%ju): wild pointer", ptr, bytes);
>
> All of those need to be cast to (uintmax_t). Sorry :(..
And you need to add #include to stand.h in order to get
uintmax_t. Here's a proper patch for amd64..
Let me run this through make universe first though..
Thanks,
-Garrett
Index: lib/libstand/zalloc.c
===
--- lib/libstand/zalloc.c (revision 223140)
+++ lib/libstand/zalloc.c (working copy)
@@ -154,7 +154,7 @@
if ((char *)ptr < (char *)mp->mp_Base ||
(char *)ptr + bytes > (char *)mp->mp_End ||
((iaddr_t)ptr & MEMNODE_SIZE_MASK) != 0)
- panic("zfree(%p,%ju): wild pointer", ptr, bytes);
+ panic("zfree(%p,%ju): wild pointer", ptr, (uintmax_t)bytes);
/*
* free the segment
@@ -178,7 +178,8 @@
* range check
*/
if ((char *)ptr + bytes > (char *)mn)
- panic("zfree(%p,%ju): corrupt memlist1",ptr, bytes);
+ panic("zfree(%p,%ju): corrupt memlist1", ptr,
+ (uintmax_t)bytes);
/*
* merge against next area or create independant area
@@ -209,7 +210,8 @@
/* NOT REACHED */
}
if ((char *)ptr < (char *)mn + mn->mr_Bytes)
- panic("zfree(%p,%ju): corrupt memlist2", ptr, bytes);
+ panic("zfree(%p,%ju): corrupt memlist2", ptr,
+ (uintmax_t)bytes);
}
/*
* We are beyond the last MemNode, append new MemNode. Merge against
Index: lib/libstand/stand.h
===
--- lib/libstand/stand.h (revision 223140)
+++ lib/libstand/stand.h (working copy)
@@ -65,6 +65,7 @@
#include
#include
#include
+#include
#include
#define CHK(fmt, args...) printf("%s(%d): " fmt "\n", __func__, __LINE__ , ##args)
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r223139 - head/lib/libstand
On Thu, Jun 16, 2011 at 7:06 AM, Bruce Evans wrote:
> On Thu, 16 Jun 2011, Tai-hwa Liang wrote:
>
>> On Thu, 16 Jun 2011, Bruce Evans wrote:
>>
>>> On Thu, 16 Jun 2011, Garrett Cooper wrote:
>>>>
>>>> And you need to add #include to stand.h in order to get
>>>> uintmax_t. Here's a proper patch for amd64..
>>>
>>> This would add namespace pollution. stand.h doesn't use anything in
>>> . It depends on normal namespace pollution in an XXX section
>>> in for the declaration of uintptr_t. It and other headers
>>> should use __uintptr_t instead. Strangely, declares
>>> uintptr_t but not uintmax_t.
>>
>> What about casting to __uintmax_t instead?
>>
>> Index: zalloc.c
>> ===
>> --- zalloc.c (revision 223146)
>> +++ zalloc.c (working copy)
>> @@ -154,7 +154,7 @@
>> if ((char *)ptr < (char *)mp->mp_Base ||
>> (char *)ptr + bytes > (char *)mp->mp_End ||
>> ((iaddr_t)ptr & MEMNODE_SIZE_MASK) != 0)
>> - panic("zfree(%p,%ju): wild pointer", ptr, bytes);
>> + panic("zfree(%p,%ju): wild pointer", ptr, (__uintmax_t)bytes);
>> ...
>
> zalloc.c is not the (header) implementation, so it should not use the
> implementation detail (anything beginning with __).
>
> The latest tinderbox errors for this are hard to understand. For amd64
> they say:
>
>> /src/lib/libstand/zalloc.c: In function 'zfree':
>> /src/lib/libstand/zalloc.c:157: warning: format '%ju' expects type
>> 'uintmax_t', but argument 3 has type 'iaddr_t'
>
> but amd64 seems to be just like sparc64 -- both seem to declare all the
> types as `unsigned long' at the lowest level. I would expect all 64-bit
> arches to do this, although this is logically wrong (it makes the largest
> integral type uintmax_t logically smaller than the standard bogus type
> unsigned long long). This logic error is partly intentional (it detects
> different type mismatches than uintmax_t = `unsigned long long' combined
> with uint64_t = `unsigned long' would).
My second patch when applied gets one past tinderbox on powerpc..
waiting for powerpc64 and sparc64 to complete. Namespace pollution is
one thing, but stdint.h isn't that bad IMHO -- I just find it funny
that iaddr_t had to be typedef'ed to uintptr_t in the first place.
Thanks!
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r223139 - head/lib/libstand
On Thu, Jun 16, 2011 at 8:12 AM, Garrett Cooper wrote:
> On Thu, Jun 16, 2011 at 7:06 AM, Bruce Evans wrote:
>> On Thu, 16 Jun 2011, Tai-hwa Liang wrote:
>>
>>> On Thu, 16 Jun 2011, Bruce Evans wrote:
>>>
>>>> On Thu, 16 Jun 2011, Garrett Cooper wrote:
>>>>>
>>>>> And you need to add #include to stand.h in order to get
>>>>> uintmax_t. Here's a proper patch for amd64..
>>>>
>>>> This would add namespace pollution. stand.h doesn't use anything in
>>>> . It depends on normal namespace pollution in an XXX section
>>>> in for the declaration of uintptr_t. It and other headers
>>>> should use __uintptr_t instead. Strangely, declares
>>>> uintptr_t but not uintmax_t.
>>>
>>> What about casting to __uintmax_t instead?
>>>
>>> Index: zalloc.c
>>> ===
>>> --- zalloc.c (revision 223146)
>>> +++ zalloc.c (working copy)
>>> @@ -154,7 +154,7 @@
>>> if ((char *)ptr < (char *)mp->mp_Base ||
>>> (char *)ptr + bytes > (char *)mp->mp_End ||
>>> ((iaddr_t)ptr & MEMNODE_SIZE_MASK) != 0)
>>> - panic("zfree(%p,%ju): wild pointer", ptr, bytes);
>>> + panic("zfree(%p,%ju): wild pointer", ptr, (__uintmax_t)bytes);
>>> ...
>>
>> zalloc.c is not the (header) implementation, so it should not use the
>> implementation detail (anything beginning with __).
>>
>> The latest tinderbox errors for this are hard to understand. For amd64
>> they say:
>>
>>> /src/lib/libstand/zalloc.c: In function 'zfree':
>>> /src/lib/libstand/zalloc.c:157: warning: format '%ju' expects type
>>> 'uintmax_t', but argument 3 has type 'iaddr_t'
>>
>> but amd64 seems to be just like sparc64 -- both seem to declare all the
>> types as `unsigned long' at the lowest level. I would expect all 64-bit
>> arches to do this, although this is logically wrong (it makes the largest
>> integral type uintmax_t logically smaller than the standard bogus type
>> unsigned long long). This logic error is partly intentional (it detects
>> different type mismatches than uintmax_t = `unsigned long long' combined
>> with uint64_t = `unsigned long' would).
>
> My second patch when applied gets one past tinderbox on powerpc..
> waiting for powerpc64 and sparc64 to complete. Namespace pollution is
> one thing, but stdint.h isn't that bad IMHO -- I just find it funny
> that iaddr_t had to be typedef'ed to uintptr_t in the first place.
This needs to be committed to unbreak ia64 and mips64*. Still waiting
to see what happens with sparc64, but amd64 and powerpc64 were oddly
happy without this, even though they should have failed along with
ia64 and mips64* (the format string should have been %zu for a size_t
type).
Will rerun universe once it completes on amd64, ia64 and sparc64
though later on today..
Thanks!
-Garrett
Index: lib/libstand/zalloc_malloc.c
===
--- lib/libstand/zalloc_malloc.c (revision 223140)
+++ lib/libstand/zalloc_malloc.c (working copy)
@@ -110,7 +110,7 @@
return;
}
if (*((signed char *)res + res->ga_Bytes - 1) != -2)
- panic("free: guard2 fail @ %p + %d from %s:%d", ptr, res->ga_Bytes - MALLOCALIGN, file, line);
+ panic("free: guard2 fail @ %p + %zu from %s:%d", ptr, res->ga_Bytes - MALLOCALIGN, file, line);
*((signed char *)res + res->ga_Bytes - 1) = -1;
#endif
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r223151 - head/lib/libstand
On Thu, Jun 16, 2011 at 8:53 AM, Warner Losh wrote: > > On Jun 16, 2011, at 9:35 AM, Tai-hwa Liang wrote: > >> Author: avatar >> Date: Thu Jun 16 15:35:12 2011 >> New Revision: 223151 >> URL: http://svn.freebsd.org/changeset/base/223151 >> >> Log: >> Using the correct format string(%zu) for size_t type. This should fix 64 >> bits builds. >> >> Submitted by: Garrett Cooper > > How about we hold all fixes until it *ACTUALLY* builds on all universe > platforms? > > I hate to be cranky, but build breakage costs a lot of time. And for stupid > stuff like this? I'm inclined to force WARNS=0 until people can actually fix > it right. This was stupid breakage on my part for not running this through universe first. The patch that builds upon this that I submitted in the other thread so far _does_ unbreak universe on ia64 and mips*. Still working on getting it to pass through amd64, i386, and sparc64 at least, which is going to be a few more hours because for some magic reason make -j doesn't work for me with universe. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r223151 - head/lib/libstand
On Thu, Jun 16, 2011 at 11:24 AM, John Baldwin wrote: > On Thursday, June 16, 2011 1:40:36 pm Garrett Cooper wrote: >> On Thu, Jun 16, 2011 at 8:53 AM, Warner Losh wrote: >> > >> > On Jun 16, 2011, at 9:35 AM, Tai-hwa Liang wrote: >> > >> >> Author: avatar >> >> Date: Thu Jun 16 15:35:12 2011 >> >> New Revision: 223151 >> >> URL: http://svn.freebsd.org/changeset/base/223151 >> >> >> >> Log: >> >> Using the correct format string(%zu) for size_t type. This should fix > 64 >> >> bits builds. >> >> >> >> Submitted by: Garrett Cooper >> > >> > How about we hold all fixes until it *ACTUALLY* builds on all universe > platforms? >> > >> > I hate to be cranky, but build breakage costs a lot of time. And for > stupid stuff like this? I'm inclined to force WARNS=0 until people can > actually fix it right. >> >> This was stupid breakage on my part for not running this through >> universe first. The patch that builds upon this that I submitted in >> the other thread so far _does_ unbreak universe on ia64 and mips*. >> Still working on getting it to pass through amd64, i386, and sparc64 >> at least, which is going to be a few more hours because for some magic >> reason make -j doesn't work for me with universe. > > You probably want to do 'make JFLAG=-j6 tinderbox' rather than 'make -j6 > tinderbox'. Yeah, that works better :). It doesn't instantly bomb out like with make -j universe . Well, here goes to the all comprehensive take 3 (take 2 seems to have gone ok). Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r223262 - in head: cddl/contrib/opensolaris/lib/libdtrace/common contrib/binutils/bfd contrib/binutils/gas contrib/binutils/gas/config contrib/binutils/ld contrib/binutils/opcodes cont
On Jun 19, 2011, at 4:26 AM, Bruce Evans wrote:
> On Sun, 19 Jun 2011, TAKAHASHI Yoshihiro wrote:
>
>> In article <201106181356.p5iduxhw044...@svn.freebsd.org>
>> Ben Laurie writes:
>>>
>>> Log:
>>> Fix clang warnings.
>>>
>>> Modified: head/sys/sys/diskpc98.h
>>> ==
>>> --- head/sys/sys/diskpc98.hSat Jun 18 13:54:36 2011(r223261)
>>> +++ head/sys/sys/diskpc98.hSat Jun 18 13:56:33 2011(r223262)
>>> @@ -36,8 +36,11 @@
>>> #include
>>>
>>> #defineDOSBBSECTOR0/* DOS boot block relative sector number */
>>> +#undef DOSPARTOFF
>>> #defineDOSPARTOFF0
>>> +#undef DOSPARTSIZE
>>> #defineDOSPARTSIZE32
>>> +#undef NDOSPART
>>> #defineNDOSPART16
>>> #defineDOSMAGICOFFSET510
>>> #defineDOSMAGIC0xAA55
>>> @@ -52,6 +55,7 @@
>>>
>>> #defineDOSMID_386BSD(PC98_MID_386BSD | PC98_MID_BOOTABLE)
>>> #defineDOSSID_386BSD(PC98_SID_386BSD | PC98_SID_ACTIVE)
>>> +#undef DOSPTYP_386BSD
>>> #defineDOSPTYP_386BSD(DOSSID_386BSD << 8 | DOSMID_386BSD)
>>>
>>> struct pc98_partition {
>>>
>>
>> I wonder why this is needed, and why only for diskpc98.h, not
>> diskmbr.h.
>
> This is needed to break the warning even more. There are are enormous
> number of layers of brokenness:
>
> o These header files unfortunately define some ioctls (just 1), so
> kdump/mkioctls generates an include of both in ioctl.c. This causes
> conflicts. The conflicts should cause errors (though the conflicting
> definitions aren't actually used in ioctl.c), but they only generates
> warnings.
>
> o If you compile ioctl.c standalone to test this, then it compiles with
> no warnings with both gcc and clang, since -Wno-system-headers is the
> default for gcc and apparently for clang too. However, for world builds
> there is magic that results in being
> $(realpath /usr/obj)/src/tmp/usr/include/sys instead of just
> /usr/include/sys. I'm not sure if clang only is confused by this so
> that -Wno-system-headers doesn't break the warnings for clang only,
> or if the warnings have always been happening and they are just more
> obvious with clang colorizing them.
>
> o The build system knows about -Wno-system-headers breaking warnings, so
> it puts -Wsystem-headers in CFLAGS to turn this off. But it only does
> this at WARNS >= 1, and kdump still uses WARNS = 0.
>
> o Poor structuring of the disk headers. I've always thought that
> diskmbr.h shouldn't exist. It doesn't describe "the" disk mbr
> structure, but only the "i386" one. It should have been named
> something like diski386.h. The current problem shows that these
> files should have been purely MD so that they can be kept separate.
> Their names should have been something like .
> Or for simplicity, keep all of their definitions with ifdefs in
> like they used to be as recently as FreeBSD-4.
> disklabel.h still has some ugly unsorted MD ifdefs (just 2, for
> LABELSECTOR and LABELOFFSET). Of course, definitions for MBRs
> should never have been in disklabel.h. For simplicity with fewer
> hacks, put all the MBR definitions with ifdefs in .
> The current problem shows that many ifdefs are needed with the
> current structuring anyway. We only escape having to ifdef everything
> in both of the files (or complications in mkioctls) because some names
> are different (e.g., struct pc98_partition instead of struct
> dos_partition, and more importantly, DIOCSPC98 instead of DIOCSMBR --
> the latter allows both ioctls to be defined in ioctl.c, though only
> the pc98 is normally used on pc98. BTW, can pc98 handle i386-formatted
> disks? MacOS supports i386-mbr formatted USB drives better than
> WinXP does -- WinXP can only mount FAT32 partitions in MBR slot 1,
> though it can recognize them in any slot. Such support is easiest
> if all the mbr ioctls are available in all arches. But I now think
> that depending on any disk ioctl in an application like fdisk or
> newfs is a bug. Such applications should be able to work on any
> "direct addressable" file (including regular files and foreign
> disks). Some Linux disk applications now work better on FreeBSD than
> FreeBSD ones do, since they don't depend so much on ioctls :-().
>
> This is only "needed" for diskpc98.h because 'm' is less than 'p', so
> diskmbr.h is always included before diskpc98.h. I thought at first
> that the order of the includes could not be depended on, because the
> find(1) in mkioctls produced output in (unsorted) tree traversal order.
> But the find is actually on "*" in each directory in the include path,
> so the shell will sort the includes alphabetically within each directory.
> I now remember that this is intentional, to get the same breakage as
> an application which complies with style(9) will get if there are any
> bogus ordering requirements for directories that are not accidentally
> satisif
Re: svn commit: r209772 - head/usr.bin/getopt
On Wed, Jul 7, 2010 at 10:58 AM, Anonymous wrote: > Doug Barton writes: > >> On 7/7/2010 10:44 AM, Benedict Reuschling wrote: >>> Author: bcr (doc committer) >> >>> -for i >>> +while true; >>> do >> >> If this is intended to be an sh scripting example a better way to write >> that is: >> >> while : ; >> >> You can't guarantee that "true" will always be available and do what you >> expect, whereas the ':' operator is a shell builtin. > > Isn't `true' shell builtin as well? > > $ type true > true is a shell builtin `true' is the new way. `:' is the old Bourne way as I've been told (but you're right, it is a built-in now as of at least 7.1 -- not sure about 6.x though)... -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r214118 - in head: sbin/geom/class/eli sys/geom/eli
On Thu, Oct 21, 2010 at 1:55 AM, Pawel Jakub Dawidek wrote:
> On Thu, Oct 21, 2010 at 07:25:53AM +0100, Rui Paulo wrote:
>> Great work. Might be worth adding the geli commands to /etc/rc.suspend &
>> /etc/rc.resume.
>>
>> You could do something that requires the minimum user configuration, like:
>>
>> ---
>> geli list 2>&1 > /dev/null
>> if [ $? -eq 0 ]; then
>> geli suspend -a
>> fi
>
> Well, this is not always safe. As I mentioned in the commit message this
> will cause deadlock if geli(8) command is stored on encrypted file
> system (you won't be able to resume). Good example of such situation is
> when you encrypt even your root file system.
I think it's pretty safe to say that if the user understands this
limitation that they can add the relevant code to the end of
rc.resume. Maybe rc.{resume,suspend}.local script hooks should be
added for user-defined commands like this?
Thanks,
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r214279 - in head: share/man/man4 sys/cam sys/cam/ata sys/kern
On Sun, Oct 24, 2010 at 10:03 AM, Alexander Motin wrote: > Bruce Cran wrote: >> On Sunday 24 October 2010 17:31:58 Bruce Cran wrote: >> >>> Log: >>> Mostly revert r203420, and add similar functionality into ada(4) since >>> the existing code caused problems with some SCSI controllers. > > Proper way would be IMHO to fix polling in aac driver. > >>> A new sysctl kern.cam.ada.spindown_shutdown has been added that controls >>> whether or not to spin-down disks when shutting down. >>> Spinning down the disks unloads/parks the heads - this is >>> much better than removing power when the disk is still >>> spinning because otherwise an Emergency Unload occurs which may cause >>> damage to the actuator. >> >> The FLUSH CACHE + STANDBY IMMEDIATE commands are issued (instead of just >> SLEEP) following the procedure documented in Fujitsu's MHW series product >> documentation under section 1.10.1, "Recommended power-off sequence". > > Not instead of "just SLEEP", but instead of FLUSH CACHE (by respective > peripheral driver) + SLEEP (by xpt). It should probably be the same. > > Just for the note, SCSI specification states that STOP automatically > implies FLUSH CACHE. ATA - doesn't. I could be wrong, but I think the ANSI ATA<->SCSI spec states otherwise (taken from ANSI INCITS 431-2007 page 62 -- see steps 1-4): 9.11.3 START STOP UNIT START bit LOEJ bit combinations The SATL shall perform the actions shown in table 40 in response to a START STOP UNIT command. Table 40 — Definition of START and LOEJ bits in the START STOP UNIT CDB START LOEJ Definition 0 0 The SATL shall: 1) If the IMMED bit is set to one, then return GOOD status; 2) Issue an ATA flush command (see 3.1.11) to the ATA device; 3) If the ATA flush command completes with any error, then process ending status according to the IMMED bit (see 9.11.2) with the additional sense code set to COMMAND SEQUENCE ERROR; 4) If the ATA flush command completes without error, then issue an ATA STANDBY IMMEDIATE command to the ATA Sector Count set to zero; 5) If the ATA STANDBY IMMEDIATE command completes with any error, then process ending status according to the IMMED bit (see 9.11.2) with the additional sense code set to COMMAND SEQUENCE ERROR; and 6) If the ATA STANDBY IMMEDIATE command completes without error and the IMMED bit is set to zero, then return GOOD status (see 9.11.2) a. Not sure about the ATA spec standalone... might be present in the ATA8 spec. Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r214279 - in head: share/man/man4 sys/cam sys/cam/ata sys/kern
On Sun, Oct 24, 2010 at 10:55 AM, Alexander Motin wrote: > Garrett Cooper wrote: >> On Sun, Oct 24, 2010 at 10:03 AM, Alexander Motin wrote: >>> Bruce Cran wrote: >>>> On Sunday 24 October 2010 17:31:58 Bruce Cran wrote: >>>> >>>>> Log: >>>>> Mostly revert r203420, and add similar functionality into ada(4) since >>>>> the existing code caused problems with some SCSI controllers. >>> Proper way would be IMHO to fix polling in aac driver. >>> >>>>> A new sysctl kern.cam.ada.spindown_shutdown has been added that controls >>>>> whether or not to spin-down disks when shutting down. >>>>> Spinning down the disks unloads/parks the heads - this is >>>>> much better than removing power when the disk is still >>>>> spinning because otherwise an Emergency Unload occurs which may cause >>>>> damage to the actuator. >>>> The FLUSH CACHE + STANDBY IMMEDIATE commands are issued (instead of just >>>> SLEEP) following the procedure documented in Fujitsu's MHW series product >>>> documentation under section 1.10.1, "Recommended power-off sequence". >>> Not instead of "just SLEEP", but instead of FLUSH CACHE (by respective >>> peripheral driver) + SLEEP (by xpt). It should probably be the same. >>> >>> Just for the note, SCSI specification states that STOP automatically >>> implies FLUSH CACHE. ATA - doesn't. >> >> I could be wrong, but I think the ANSI ATA<->SCSI spec states >> otherwise (taken from ANSI INCITS 431-2007 page 62 -- see steps 1-4): >> >> 9.11.3 START STOP UNIT START bit LOEJ bit combinations >> The SATL shall perform the actions shown in table 40 in response to a >> START STOP UNIT command. >> Table 40 — Definition of START and LOEJ bits in the START STOP UNIT CDB >> START LOEJ Definition >> 0 0 The SATL shall: >> 1) If the IMMED bit is set to one, then return GOOD status; >> 2) Issue an ATA flush command (see 3.1.11) to the ATA device; >> 3) If the ATA flush command completes with any error, then process ending >> status >> according to the IMMED bit (see 9.11.2) with the additional sense code set to >> COMMAND SEQUENCE ERROR; >> 4) If the ATA flush command completes without error, then issue an ATA >> STANDBY >> IMMEDIATE command to the ATA Sector Count set to zero; >> 5) If the ATA STANDBY IMMEDIATE command completes with any error, then >> process ending status according to the IMMED bit (see 9.11.2) with the >> additional >> sense code set to COMMAND SEQUENCE ERROR; and >> 6) If the ATA STANDBY IMMEDIATE command completes without error and the >> IMMED bit is set to zero, then return GOOD status (see 9.11.2) a. >> >> Not sure about the ATA spec standalone... might be present in the ATA8 >> spec. > > As I understand, this just confirms what I have said: > SCSI STOP == ATA FLUSH CACHE + STANDBY IMMEDIATE. > So SCSI STOP implies flush, while ATA STANDBY IMMEDIATE doesn't. Looking at it from that perspective, I agree. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r214303 - in head/sys: conf netinet
On Oct 24, 2010, at 4:36 PM, Julian Elischer wrote: > On 10/24/10 3:02 PM, Bjoern A. Zeeb wrote: >> Author: bz >> Date: Sun Oct 24 22:02:36 2010 >> New Revision: 214303 >> URL: http://svn.freebsd.org/changeset/base/214303 >> >> Log: >> Add initial inet DDB support for show in_ifaddr and show sin commands which >> proved to be useful while debugging address list problems. > > sin commands? really? "Covet thy neighbor's wife!" >> >> As long as DDB doesn't hold false WITNESS (LOR), we should be ok :)...___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r214409 - head/sys/kern
On Tue, Oct 26, 2010 at 7:32 PM, David Xu wrote:
> Author: davidxu
> Date: Wed Oct 27 02:32:54 2010
> New Revision: 214409
> URL: http://svn.freebsd.org/changeset/base/214409
>
> Log:
> If input parameter cpusetsize is zero, give userland size of cpuset mask
> kernel is using.
>
> Modified:
> head/sys/kern/kern_cpuset.c
>
> Modified: head/sys/kern/kern_cpuset.c
> ==
> --- head/sys/kern/kern_cpuset.c Wed Oct 27 02:07:25 2010 (r214408)
> +++ head/sys/kern/kern_cpuset.c Wed Oct 27 02:32:54 2010 (r214409)
> @@ -889,6 +889,10 @@ cpuset_getaffinity(struct thread *td, st
> int error;
> size_t size;
>
> + if (uap->cpusetsize == 0) {
> + td->td_retval[0] = sizeof(cpuset_t);
> + return (0);
> + }
> if (uap->cpusetsize < sizeof(cpuset_t) ||
> uap->cpusetsize > CPU_MAXSIZE / NBBY)
> return (ERANGE);
Isn't this requirement partly broken now?
[ERANGE] The cpusetsize was either preposterously large or
smaller than the kernel set size.
Why should cpuset(2) be broken in favor of people not passing valid values?
Thanks,
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r214409 - head/sys/kern
On Wed, Oct 27, 2010 at 3:49 AM, David Xu wrote:
> Garrett Cooper wrote:
>>
>> On Tue, Oct 26, 2010 at 7:32 PM, David Xu wrote:
>>>
>>> Author: davidxu
>>> Date: Wed Oct 27 02:32:54 2010
>>> New Revision: 214409
>>> URL: http://svn.freebsd.org/changeset/base/214409
>>>
>>> Log:
>>> If input parameter cpusetsize is zero, give userland size of cpuset mask
>>> kernel is using.
>>>
>>> Modified:
>>> head/sys/kern/kern_cpuset.c
>>>
>>> Modified: head/sys/kern/kern_cpuset.c
>>>
>>> ==
>>> --- head/sys/kern/kern_cpuset.c Wed Oct 27 02:07:25 2010 (r214408)
>>> +++ head/sys/kern/kern_cpuset.c Wed Oct 27 02:32:54 2010 (r214409)
>>> @@ -889,6 +889,10 @@ cpuset_getaffinity(struct thread *td, st
>>> int error;
>>> size_t size;
>>>
>>> + if (uap->cpusetsize == 0) {
>>> + td->td_retval[0] = sizeof(cpuset_t);
>>> + return (0);
>>> + }
>>> if (uap->cpusetsize < sizeof(cpuset_t) ||
>>> uap->cpusetsize > CPU_MAXSIZE / NBBY)
>>> return (ERANGE);
>>
>> Isn't this requirement partly broken now?
>>
>> [ERANGE] The cpusetsize was either preposterously large or
>> smaller than the kernel set size.
>>
>> Why should cpuset(2) be broken in favor of people not passing valid
>> values?
>
> I really hate to see such a problem that userland can not figure out
> what kernel is using, I try hardly to guess, but still can not find
> what it is using. yes, I think the doc may need to be fixed or
> another syscall is needed.
Well... Jeff's code in cpuset(1) does some trivial sizeof(mask)
's, but it just passes in cpuset_t for mask. I've seen different
calling conventions at the kernel level when I tried to get my brain
in sync with that for a bug I was looking at a few weeks ago (and
sadly, failed to some degree).
These syscalls are a bit confusing though, and apart from
cpuset(1) there aren't any really good examples in the sourcebase on
how to use them (at least not the last time I checked)...
Thanks,
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r214409 - head/sys/kern
On Wed, Oct 27, 2010 at 9:37 AM, David Xu wrote: > Pawel Jakub Dawidek wrote: >> >> On Wed, Oct 27, 2010 at 10:49:12AM +, David Xu wrote: >>> >>> I really hate to see such a problem that userland can not figure out >>> what kernel is using, I try hardly to guess, but still can not find >>> what it is using. yes, I think the doc may need to be fixed or >>> another syscall is needed. >> >> Maybe you could just add sysctl and eventually put it into sysconf(3)? > > I just found a dirty method, use sizeof(long) and kern.smp.maxcpus > 32 to figure out the size the kernel is using, because it is how > cpuset_t is constructed, wish it will never be changed. ;-) Pawel's suggestion makes more sense to be honest. If this should be added to sysconf(3) and is worthy of abstracting out into a more generalized concept, then it might be a good idea to get into POSIX. However, it would need to be hashed out because the current implementation is very FreeBSD centric of course :). ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r214412 - in head: lib/libthr/thread sys/kern
On Wed, Oct 27, 2010 at 2:29 AM, David Xu wrote:
> Author: davidxu
> Date: Wed Oct 27 09:29:03 2010
> New Revision: 214412
> URL: http://svn.freebsd.org/changeset/base/214412
>
> Log:
> - Revert r214409.
> - Use long word to figure out sizeof kernel cpuset, hope it works.
>
> Modified:
> head/lib/libthr/thread/thr_attr.c
> head/sys/kern/kern_cpuset.c
>
> Modified: head/lib/libthr/thread/thr_attr.c
> ==
> --- head/lib/libthr/thread/thr_attr.c Wed Oct 27 07:14:46 2010
> (r214411)
> +++ head/lib/libthr/thread/thr_attr.c Wed Oct 27 09:29:03 2010
> (r214412)
> @@ -574,13 +574,14 @@ _get_kern_cpuset_size(void)
>
> if (kern_cpuset_size == 0) {
> size_t len;
> + int maxcpus;
>
> - len = sizeof(kern_cpuset_size);
> - if (sysctlbyname("kern.smp.maxcpus", &kern_cpuset_size,
> - &len, NULL, 0))
> + len = sizeof(maxcpus);
> + if (sysctlbyname("kern.smp.maxcpus", &maxcpus, &len, NULL, 0))
> PANIC("failed to get sysctl kern.smp.maxcpus");
> -
> - kern_cpuset_size = (kern_cpuset_size + 7) / 8;
> + int nbits_long = sizeof(long) * NBBY;
> + int num_long = (maxcpus + nbits_long - 1) / nbits_long;
> + kern_cpuset_size = num_long * sizeof(long);
> }
>
> return (kern_cpuset_size);
>
> Modified: head/sys/kern/kern_cpuset.c
> ==
> --- head/sys/kern/kern_cpuset.c Wed Oct 27 07:14:46 2010 (r214411)
> +++ head/sys/kern/kern_cpuset.c Wed Oct 27 09:29:03 2010 (r214412)
> @@ -889,10 +889,6 @@ cpuset_getaffinity(struct thread *td, st
> int error;
> size_t size;
>
> - if (uap->cpusetsize == 0) {
> - td->td_retval[0] = sizeof(cpuset_t);
> - return (0);
> - }
> if (uap->cpusetsize < sizeof(cpuset_t) ||
> uap->cpusetsize > CPU_MAXSIZE / NBBY)
> return (ERANGE);
Are you sure this won't break 32-bit on 64-bit architectures, i.e.
amd64, mips, powerpc64, sparc64?
Thanks,
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r214409 - head/sys/kern
On Wed, Oct 27, 2010 at 5:56 AM, David Xu wrote: > Robert Watson wrote: >> >> On Wed, 27 Oct 2010, David Xu wrote: >> > I really hate to see such a problem that userland can not figure out > what kernel is using, I try hardly to guess, but still can not find what > it > is using. yes, I think the doc may need to be fixed or another syscall is > needed. Well... Jeff's code in cpuset(1) does some trivial sizeof(mask) 's, but it just passes in cpuset_t for mask. I've seen different calling conventions at the kernel level when I tried to get my brain in sync with that for a bug I was looking at a few weeks ago (and sadly, failed to some degree). These syscalls are a bit confusing though, and apart from cpuset(1) there aren't any really good examples in the sourcebase on how to use them (at least not the last time I checked)... Thanks, -Garrett >>> The problem is that the size of cpuset is not fixed, it is tunable by the >>> recompiling kernel with different parameter, so if you have a program which >>> you want to adapt it to use any size of cpuset, it should be able to get the >>> size the kernel is using, if you don't have source code of the program, you >>> can not compile it with new parameter, then there is trouble. >> >> Yay, it's fd_set all over again :-). >> >> It sounds like we might just need to add a sysctl and a few wrapper >> functions in userspace along the lines of (hand-wave): >> >> cpuset_t *cpuset_alloc(); >> void cpuset_free(); >> >> And perhaps some sort of API that abstracts manipulation of the set (or >> doesn't but allows the user to easily query its bounds). >> >> Robert >> > Problem is who will use the non-standard interface ? The > pthread_attr_getaffinity_np pthread_attr_setaffinity_np > and others are from glibc, which let you specify arbitrary > cpuset size but kernel only accept one size. :-) > > Though it is not POSIX, but some software start to use it, AFAIK, > Erlang language's VM start to use it for binding its scheduler > thread to cpu, we have to live with it. We still lack of some functions > to let it compile without modification, one is it wants to know > cpu topology, and other crappy functions it wants to use is: > sched_getaffinity, sched_setaffinity, which one guy thought each > thread is just a process which has a PID. :-) > I don't know how it uses Solaris processor binding interface. I brought this up a while back over the Austin Group list, but it looks like I need to file an Aardvark ticket for it and attend the meetings so the OpenGroup folks actually take the issue to heart. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r214409 - head/sys/kern
On Wed, Oct 27, 2010 at 9:22 AM, Andriy Gapon wrote:
>
> [patch attachment was lost]
Ugh... Mailman hates me I guess :(...
> on 27/10/2010 19:07 Garrett Cooper said the following:
>> How about this patch? I implemented this as a readonly tunable and
>
> I don't think that it's correct to call it a tunable or use CTLFLAG_RDTUN.
> As I understand it is a read-only sysctl.
Converted to CTLFLAG_RD.
>> sysconf tunable, because (AFAIK) the value that is being tested
>> shouldn't change during runtime after the system has been booted up,
>> and figuring that the value wasn't going to change it was better to
>> lose 4/8 bytes on the kernel stack instead of having to recompute the
>> value every time in a function call, with the associated lost heap /
>> stack memory in the process, as the assumption is that this libcall
>> was going to be called frequently by some programs.
Thanks!
-Garrett
Index: include/unistd.h
===
--- include/unistd.h (revision 214413)
+++ include/unistd.h (working copy)
@@ -288,6 +288,7 @@
#if __BSD_VISIBLE
#define _SC_NPROCESSORS_CONF 57
#define _SC_NPROCESSORS_ONLN 58
+#define _SC_CPUSET_SIZE 122
#endif
/* Extensions found in Solaris and Linux. */
Index: lib/libc/gen/sysconf.c
===
--- lib/libc/gen/sysconf.c (revision 214413)
+++ lib/libc/gen/sysconf.c (working copy)
@@ -597,6 +597,15 @@
return (lvalue);
#endif
+#ifdef _SC_CPUSET_SIZE
+ case _SC_CPUSET_SIZE:
+ len = sizeof(lvalue);
+ if (sysctlbyname("kern.sched.cpusetsize", &lvalue, &len, NULL,
+ 0) == -1)
+ return (-1);
+ return (lvalue);
+#endif
+
default:
errno = EINVAL;
return (-1);
Index: sys/kern/sched_ule.c
===
--- sys/kern/sched_ule.c (revision 214413)
+++ sys/kern/sched_ule.c (working copy)
@@ -2712,6 +2712,8 @@
sbuf_delete(topo);
return (err);
}
+
+static size_t _kern_cpuset_size = sizeof(cpuset_t);
#endif
SYSCTL_NODE(_kern, OID_AUTO, sched, CTLFLAG_RW, 0, "Scheduler");
@@ -2748,6 +2750,15 @@
SYSCTL_PROC(_kern_sched, OID_AUTO, topology_spec, CTLTYPE_STRING |
CTLFLAG_RD, NULL, 0, sysctl_kern_sched_topology_spec, "A",
"XML dump of detected CPU topology");
+
+/*
+ * Return the size of cpuset_t at the kernel level
+ *
+ * XXX (gcooper): replace ULONG with SIZE once CTLTYPE_SIZE is implemented.
+ */
+SYSCTL_ULONG(_kern_sched, OID_AUTO, cpusetsize, CTLFLAG_RD,
+&_kern_cpuset_size, 0, "Kernel-level cpuset_t struct size");
+
#endif
/* ps compat. All cpu percentages from ULE are weighted. */
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r214409 - head/sys/kern
On Thu, Oct 28, 2010 at 2:54 AM, David Xu wrote: > Garrett Cooper wrote: >> >> On Wed, Oct 27, 2010 at 9:22 AM, Andriy Gapon wrote: >>> >>> [patch attachment was lost] >> >> Ugh... Mailman hates me I guess :(... >> >>> on 27/10/2010 19:07 Garrett Cooper said the following: >>>> >>>> How about this patch? I implemented this as a readonly tunable and >>> >>> I don't think that it's correct to call it a tunable or use >>> CTLFLAG_RDTUN. >>> As I understand it is a read-only sysctl. >> >> Converted to CTLFLAG_RD. >> >>>> sysconf tunable, because (AFAIK) the value that is being tested >>>> shouldn't change during runtime after the system has been booted up, >>>> and figuring that the value wasn't going to change it was better to >>>> lose 4/8 bytes on the kernel stack instead of having to recompute the >>>> value every time in a function call, with the associated lost heap / >>>> stack memory in the process, as the assumption is that this libcall >>>> was going to be called frequently by some programs. > > The patch looks fine to me. ;-) If no one opposes the change, could you please commit the patch for me David? Thanks! -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r214510 - in head: include lib/libc/gen sys/kern
On Fri, Oct 29, 2010 at 3:21 PM, Pawel Jakub Dawidek wrote:
> On Fri, Oct 29, 2010 at 01:31:10PM +, David Xu wrote:
>> Author: davidxu
>> Date: Fri Oct 29 13:31:10 2010
>> New Revision: 214510
>> URL: http://svn.freebsd.org/changeset/base/214510
>>
>> Log:
>> Add sysctl kern.sched.cpusetsize to export the size of kernel cpuset,
>> also add sysconf() key _SC_CPUSET_SIZE to get sysctl value.
>>
>> Submitted by: gcooper
> [...]
>> +#ifdef _SC_CPUSET_SIZE
>> + case _SC_CPUSET_SIZE:
>> + len = sizeof(lvalue);
>> + if (sysctlbyname("kern.sched.cpusetsize", &lvalue, &len, NULL,
>> + 0) == -1)
>> + return (-1);
>> + return (lvalue);
>> +#endif
> [...]
>> +static size_t _kern_cpuset_size = sizeof(cpuset_t);
> [...]
>> +/*
>> + * Return the size of cpuset_t at the kernel level
>> + *
>> + * XXX (gcooper): replace ULONG with SIZE once CTLTYPE_SIZE is implemented.
>> + */
>> +SYSCTL_ULONG(_kern_sched, OID_AUTO, cpusetsize, CTLFLAG_RD,
>> + &_kern_cpuset_size, 0, "Kernel-level cpuset_t struct size");
>> +
>
> Because it is used via sysconf(3), I don't think it should be converted
> to CTLTYPE_SIZE at all. I even think it would be safer to make
> _kern_cpuset_size a long (sysconf's lvalue is long) and (just for
> consistency) use SYSCTL_LONG().
size_t is synonymous with long though (minus the fact that size_t is
unsigned and long is signed).
cperciva came up with same question, and the thing that I noted is
that SYSCTL_SIZE, etc was going to be implemented in the not so
distant future (I have the tunables done; I was going to finish off
the sysctl(9) analogs all in one shot to avoid having to bump
__FreeBSD_version__ twice, but was waiting for all of the parts to
come in for my router box so I could get my test box online, but
that's a sidenote :)..).
des preferred the semantics of SIZE and POINTER, etc in the tunables
because of the concept it implies over a long (even though they're
basically synonyms at one level or another). The comment was there as
a reminder to me to get the work done quicker :).
> Also note, that on i386 long is 32bit and on amd64 long is 64bit, so
> 32bit process running on 64bit system won't be able to read this sysctl.
> Or do we detect 32bit processes on 64bit systems and convert such types
> in the kernel?
There are two things I've been thinking about with this work though:
1. sysctls truncate output over 64-bit with certain datatypes, like
LONGs (SIZE, POINTER, etc would apply as well in the above example). I
thought this was an undesirable loss of precision, but I'd need to
talk to someone else about this.
2. It might be convenient if there was a lookup table for certain
types like FDSET (like Robert brought up) where userland and kernel
space types can vary like with cpuset_t. Just an idea to ponder over
in my free time that I might bring up to more senior folks for more
thorough consideration because it would be a cleaner interface to
determining datatypes widths like this.
Thanks for the comments though :)!
-Garrett
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r214510 - in head: include lib/libc/gen sys/kern
On Sat, Oct 30, 2010 at 3:08 AM, Bruce Evans wrote:
> On Sat, 30 Oct 2010, Pawel Jakub Dawidek wrote:
>
>> On Fri, Oct 29, 2010 at 01:31:10PM +, David Xu wrote:
>>>
>>> Log:
>>> Add sysctl kern.sched.cpusetsize to export the size of kernel cpuset,
>>> also add sysconf() key _SC_CPUSET_SIZE to get sysctl value.
>>>
>>> Submitted by: gcooper
>>
>> [...]
>>>
>>> +#ifdef _SC_CPUSET_SIZE
>>> + case _SC_CPUSET_SIZE:
>>> + len = sizeof(lvalue);
>>> + if (sysctlbyname("kern.sched.cpusetsize", &lvalue, &len,
>>> NULL,
>>> + 0) == -1)
>>> + return (-1);
>>> + return (lvalue);
>>> +#endif
>>
>> [...]
>>>
>>> +static size_t _kern_cpuset_size = sizeof(cpuset_t);
>
> No need for this or its bogus type, since it is a small compile-time
> constant value.
>
>> [...]
>>>
>>> +/*
>>> + * Return the size of cpuset_t at the kernel level
>>> + *
>>> + * XXX (gcooper): replace ULONG with SIZE once CTLTYPE_SIZE is
>>> implemented.
>>> + */
>>> +SYSCTL_ULONG(_kern_sched, OID_AUTO, cpusetsize, CTLFLAG_RD,
>>> + &_kern_cpuset_size, 0, "Kernel-level cpuset_t struct size");
>>> +
>
> Just use:
>
> SYSCTL_INT(_kern_sched, OID_AUTO, cpusetsize, CTLFLAG_RD,
> 0, sizeof(cpuset_t), "sizeof(cpuset_t) in the kernel");
>
> the same as for all debugging sizeofs in kern_mib.c. (I also changed the
> style of the message to be more like the ones there. (sysctl -ad | greo
> sizeof on ref9-i386 shows only 1 other inconsistency: the banal description
> is missing for debug.sizeof.namecache.))
Yeah... it was silly of me to do it that way, in hindsight :(...
>> Because it is used via sysconf(3), I don't think it should be converted
>> to CTLTYPE_SIZE at all. I even think it would be safer to make
>> _kern_cpuset_size a long (sysconf's lvalue is long) and (just for
>> consistency) use SYSCTL_LONG().
>>
>> Also note, that on i386 long is 32bit and on amd64 long is 64bit, so
>> 32bit process running on 64bit system won't be able to read this sysctl.
>> Or do we detect 32bit processes on 64bit systems and convert such types
>> in the kernel?
>
> Just use int. 16-bit ints are only large enough for 8*32767 CPUs, but
> 32-bit ints are large enough for 8*2147482647 CPUs, which should be
> enough for anyone. Also use 'int value' instead of 'long lvalue' in
> sysconf.c.
That won't really do much good, otherwise it would oppose the POSIX
API definition :/...
> Using u_long is also bogus. Because the value is returned by sysconf(3),
> u_long won't actually work if it is actually needed, because if the
> value exceeds LONG_MAX then `return (lvalue)' will blindly overflow.
> But the value is very far from exeeding even INT_MAX, so there is no
> problem. (Overflow would actually occur earlier, via the type pun of
> using sysctl for a u_long variable to read the variable into a plain
> long. It is unclear that this type pun is safe even when there is no
> overflow.)
>
> The kernel isn't going to be having any data structures larger than
> 2147482647 bytes any time soon, so 32-bit ints are plenty large enough
> for returning the size of any data structure in the kernel. However,
> 16-bit ints wouldn't be. Careful code might use size_t to avoid
> assuming anything about sizeof(int), but with 32-bit ints this mainly
> gives bloat when size_t is 64 bits.
Ok.
Thanks!
-Garrett
Index: sys/kern/sched_ule.c
===
--- sys/kern/sched_ule.c (revision 214554)
+++ sys/kern/sched_ule.c (working copy)
@@ -2712,8 +2712,6 @@
sbuf_delete(topo);
return (err);
}
-
-static size_t _kern_cpuset_size = sizeof(cpuset_t);
#endif
SYSCTL_NODE(_kern, OID_AUTO, sched, CTLFLAG_RW, 0, "Scheduler");
@@ -2751,13 +2749,9 @@
CTLFLAG_RD, NULL, 0, sysctl_kern_sched_topology_spec, "A",
"XML dump of detected CPU topology");
-/*
- * Return the size of cpuset_t at the kernel level
- *
- * XXX (gcooper): replace ULONG with SIZE once CTLTYPE_SIZE is implemented.
- */
-SYSCTL_ULONG(_kern_sched, OID_AUTO, cpusetsize, CTLFLAG_RD,
-&_kern_cpuset_size, 0, "Kernel-level cpuset_t struct size");
+/* Return the size of cpuset_t at the kernel level */
+SYSCTL_INT(_kern_sched, OID_AUTO, cpusetsize, CTLFLAG_RD,
+0, sizeof(cpuset_t), "sizeof(cpuset_t)");
#endif
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r214596 - head/bin/rm
On Mon, Nov 1, 2010 at 6:40 PM, Alexander Best wrote: > On Mon Nov 1 10, Ken Smith wrote: >> On Sun, 2010-10-31 at 20:11 +0100, Ulrich Spoerlein wrote: >> > On Sun, 31.10.2010 at 17:06:03 +0100, Pawel Jakub Dawidek wrote: >> > > On Sun, Oct 31, 2010 at 09:21:28AM +, Ulrich Spoerlein wrote: >> > > > Author: uqs >> > > > Date: Sun Oct 31 09:21:27 2010 >> > > > New Revision: 214596 >> > > > URL: http://svn.freebsd.org/changeset/base/214596 >> > > > >> > > > Log: >> > > > Elaborate some more on the non-security implications of using -P >> > > [...] >> > > > +.Pp >> > > > +N.B.: The >> > > > +.Fl P >> > > > +flag is not considered a security feature >> > > > +.Pq see Sx BUGS . >> > > >> > > I'm sorry for jumping so late into the subject, but if it is not a >> > > security feature than what other purpose has left? >> > > >> > > Really guys, this option is useless. >> > > >> > > There is no reliable way to verify if the blocks are really overwritten. >> > > Period. >> > > >> > > If it is not used for security, then I see no other use for it (except >> > > for [1]). >> > > >> > > If it is used for security then we better have a way to give the user >> > > the right answer to the question "is my data really gone?" and don't >> > > make false assumptions or giving answers "we hope so". >> > > >> > > Why there is no reliable way to verify this? >> > > 1. Check file system type (UFS, ZFS). >> > > 2. Check file system configuration (UFS with snapshots?). >> > > 3. Be sure sync(2) the file system and send BIO_FLUSH to all the media >> > > involved (some cheap flash disks lie about BIO_FLUSH support). >> > > 4. Check underlying media (GLABEL provider - no modification to the >> > > data). >> > > 5. Check underlying media (ZVOL - data won't be overwritten, but...). >> > > 6. Check ZFS vdevs (on which providers ZVOL's pool is based on). >> > > 7. Check vdevs (GELI - cool, we have encryption). >> > > 8. Check GELI configuration (maybe NULL encryption algorithm?). >> > > 9. Check underlying media (HDD, SSD, swap-backed md(4) device? goto 3). >> > > 10. Check if the sectors weren't remapped while we were overwriting. >> > > >> > > In other words this is s complicated that it would simply be too >> > > hard to explain to regular user or implement in rm(1). >> > > >> > > IMHO this option should be removed and rm(1) should fail when a user is >> > > trying to use it. >> > >> > No, this is a POLA violation for no apparent gain. The flag has been in >> > FreeBSD since at least '94. Remember, that we are in the rope-selling >> > business. We empower the users to shoot themselves in the foot. >> >> Just playing Devils' Advocate... If the removal of -P were done as >> part of a new branch the POLA argument is moot if it's judged you >> are a bit off on the "no apparent gain" aspect. And the rope selling >> argument also only applies so far. One could argue having our installer >> by default leave a machine set up so SSH was enabled, remote root logins >> were allowed, and no initial password set up for root is fine because >> we're in the rope-selling business and for some portion of the user >> base that's just fine. I know that's extreme but that's the point, >> I'm saying it's hard to figure out exactly where the line is between >> activities that are ill-advised versus those that are just plain >> stupid sometimes. >> >> So, please, given all the attention being given to the security aspects >> of users properly erasing data they should erase I'd prefer we focus on >> whether providing -P at all is flat out lying and base the decision >> about whether it should go based on that. Lots of things we thought >> were OK back in 1994 we've changed our minds about since then. >> >> > I, for one, am using the -P option in a certain case where I can be sure >> > that ~99% of the data will be obliterated and I'm fine with that. For >> > all other cases I'm using geli or gbde (where I can make sure, that data >> > is lost). >> >> This strongly backs up Pawel's argument that the existence of -P is a >> lie. >> >> > So we can either fix -P for all cases (impossible), or at least document >> > its shortcomings. Documenting them clearly is better than what we had a >> > couple of days before. >> >> As I said above, with re@ hat on since the claim of POLA above is >> slightly based on branch/release guidelines, I think removal of -P >> is also still an option if it's decided -P is a lie. > > how about a compromise then? let's leave the -P switch in rm, but make it a no > op! in addition to that add a new rm(1) entry explaining what the -P switch > did > and why exactly it was turned into a no op. let's be really eloborate on this > issue and tell the user exactly every tiny detail that lead to the conclusion > that currently the -P switch serves no purpose and thus it was turned into a > no > op. also a statement should be added to rm(1) that makes clear that the -P > flag > *will* come back to rm, once the low level work
