Re: svn commit: r316591 - head/sys/dev/tpm
On Fri, Apr 07, 2017 at 11:02:06AM -0700, Ngie Cooper wrote: > Bah. I missed the nested FreeBSD in OpenBSD comment.. nevermind the part > about enabling power support. It's too early for me to be thinking critically > I guess.. But you are helping support my case for https://reviews.freebsd.org/D10321 :-) -- -- David(obr...@freebsd.org) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r316591 - head/sys/dev/tpm
On Thu, Apr 06, 2017 at 10:19:48PM -0700, Ngie Cooper (yaneurabeya) wrote: > > On Apr 6, 2017, at 15:21, David E. O'Brien wrote: > Hi David, > I think you meant to delete the other piece of code (__FreeBSD__ is > always defined). Hi Ngie, I removed 100% dead code. This was a block of code that could never be active. The code supported two cases: 1. __FreeBSD__ being defined 2. __FreeBSD__ not being defined. No attention was paid to any other (such as __OpenBSD__). The code I deleted could never be activated. So it was an obvious thing to remove even if the OpenBSD support is kept. I have a patch to unifdef(1) the code at: https://reviews.freebsd.org/D10321 > Also, why delete lines that might make it harder to backport changes > from OpenBSD? It is hard to read this code and follow its flow with the multiple versions of the same functions. I ported this driver to Junos on MIPS and it was much simpler to read, enhance, and debug without the OpenBSD bits. Also, there is no evidence this still works on OpenBSD. OpenBSD never accepted this driver, and instead wrote their own minimal driver (sys/dev/acpi/tpm.c for suspending the device). OpenBSD has no interest in this driver. So we're carrying around needless baggage. -- -- David(obr...@freebsd.org) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r255187 - in head/sys: conf crypto/aesni modules/aesni
On Mon, Sep 09, 2013 at 11:41:49PM -0700, John-Mark Gurney wrote: > David O'Brien wrote this message on Mon, Sep 09, 2013 at 23:01 -0700: > Please back that out until you have an understand of what the real > problem is... Folks use FreeBSD for real work -- I have a window of opportunity to install a new world + kernel. When I tried updating this laptop in early August the kernel build was broken. It appeared broken again this time. The issue is you added a new feature to the GCC compiler (r255185 2013-09-03), and then immediately consumed it in the kernel build (r255187 2013-09-03 11:31:23). You did not put anything in UPDATING warning folks of this. Robert Watson used to often remind folks that when we add features to the toolchain we give a reasonable amount of time for them to work their way into folks userland before using them in the kernel build. My userland sources are from Sunday September 1st when I started my 'make buildworld' + 'mergemaster -p' + 'make installworld' + 'mergemaster -i' sequence. Sorry it takes so long to build world with clang on a T60. I updated my kernel sources and tried to build a new kernel before rebooting. I had no reason to not expect a 2 day old compiler could not build a kernel during a code freeze. I've backed out r255440 as r255452. Please add a note to UPDATING. -- -- David (obr...@freebsd.org) ___ 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: r255187 - in head/sys: conf crypto/aesni modules/aesni
On Tue, Sep 03, 2013 at 06:31:23PM +, John-Mark Gurney wrote: > Log: > Use the fact that the AES-NI instructions can be pipelined to improve > performance... Use SSE2 instructions for calculating the XTS tweek > factor... Let the compiler do more work and handle register allocation > by using intrinsics, now only the key schedule is in assembly... Hi John-Mark, Unfortunately this does not work with /usr/bin/gcc (which I still use as /usr/bin/cc on this old IBM T60 laptop due to clang's enormous pestimation on 'make world' and build times. Please fix this ASAP or back it out out of 10-CURRENT as it does not work with /usr/bin/gcc: 1. /usr/bin/gcc cannot handle the "-maes" option. I committed r255440 to address this. 2. /usr/src/sys/modules/aesni/../../crypto/aesni/aesencdec.h:30:23: error: wmmintrin.h: No such file or directory and then a cascade of errors follow. For now, I've sent a patch to re@ for approval to remove the 'aesni' module from the build if not using clang. But the LINT build is still broken with /usr/bin/gcc. > Replace .byte hard coded instructions w/ the proper instructions now > that both clang and gcc support them... Is this out-of-tree latest GCC that supports this? thanks, -- -- David (obr...@freebsd.org) ___ 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: r253996 - in head: . sys/cddl/compat/opensolaris/sys sys/cddl/dev/dtrace sys/conf sys/modules/cyclic sys/modules/dtrace/dtio sys/modules/dtrace/dtmalloc sys/modules/dtrace/dtnfscl sys/
On Tue, Aug 06, 2013 at 03:51:56PM +, Andriy Gapon wrote: > Log: .. > Also, meaning of DEBUG was overloaded to enable WITNESS support for some > OpenSolaris (primarily ZFS) locks. Now this overloading is removed and > that use of DEBUG is replaced with a new option OPENSOLARIS_WITNESS. You state there is little value in witness tracking for ZFS in UPDATING. Is there no reasonable way to gain useful lock tracking for ZFS? At a minimum, shouldn't this also be added to sys/conf/NOTES in the "# SMP Debugging Options:" section? -- -- David (obr...@freebsd.org) ___ 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: r253786 - in head/sys: dev/random modules/padlock_rng modules/rdrand_rng modules/yarrow_rng
On Wed, Jul 31, 2013 at 05:58:43AM +0400, Andrey Chernov wrote: > On 31.07.2013 4:07, David O'Brien wrote: > > I believe you're talking about this code in > > sys/libkern/arc4random.c:arc4rand() > > > > if (atomic_cmpset_int(&arc4rand_iniseed_state, ARC4_ENTR_HAVE, > > ARC4_ENTR_SEED) || reseed || > >(arc4_numruns > ARC4_RESEED_BYTES) || > >(tv.tv_sec > arc4_t_reseed)) > > arc4_randomstir(); > > > > Without setting 'arc4rand_iniseed_state' from ARC4_ENTR_NONE -> > > ARC4_ENTR_HAVE, we would still call arc4_randomstir() periodically due > > to (tv.tv_sec > arc4_t_reseed) and (arc4_numruns > ARC4_RESEED_BYTES). > > The whole problem is that arc4 is poorly initialized right after boot, > but immediately used in many places like tcp. It reseeds again only > after 5 minutes after boot making vulnerability window at this interval. I realize the motivation for your r249631 change. But as it relates to the change I committed, there is no change in behavior in this. If one is using a hardware RNG, yarrow is not initialized and so the ARC4_ENTR_NONE -> ARC4_ENTR_HAVE transition does not happen. -- -- David (obr...@freebsd.org) ___ 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: r253786 - in head/sys: dev/random modules/padlock_rng modules/rdrand_rng modules/yarrow_rng
On Tue, Jul 30, 2013 at 05:07:46PM -0700, David O'Brien (@FreeBSD) wrote: > I believe you're talking about this code in > sys/libkern/arc4random.c:arc4rand() > > if (atomic_cmpset_int(&arc4rand_iniseed_state, ARC4_ENTR_HAVE, > ARC4_ENTR_SEED) || reseed || > (arc4_numruns > ARC4_RESEED_BYTES) || > (tv.tv_sec > arc4_t_reseed)) > arc4_randomstir(); Looking at this, seems to me that it would be more optimized if we tested the things that are most likely to be TRUE first instead of those things most likely to be FALSE? ARC4_ENTR_HAVE->ARC4_ENTR_SEED can only happen once per boot, and the 'reseed' flag is '0' in the majority of the arc4rand() callers. -- -- David(obr...@freebsd.org) ___ 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: r253786 - in head/sys: dev/random modules/padlock_rng modules/rdrand_rng modules/yarrow_rng
On Tue, Jul 30, 2013 at 01:37:47AM +0400, Andrey Chernov wrote: > On 30.07.2013 0:58, David E. O'Brien wrote: > > Decouple yarrow from random(4) device. .. > > We currently have 3 random_adaptors: > > + yarrow > > + rdrand (ivy.c) > > + nehemeiah > > After this commit we again have a problem with badly initialized arc4 > (for rdrand and nehemiah cases, when yarrow isn't loaded), because only > yarrow have reinit code. I believe you're talking about this code in sys/libkern/arc4random.c:arc4rand() if (atomic_cmpset_int(&arc4rand_iniseed_state, ARC4_ENTR_HAVE, ARC4_ENTR_SEED) || reseed || (arc4_numruns > ARC4_RESEED_BYTES) || (tv.tv_sec > arc4_t_reseed)) arc4_randomstir(); Without setting 'arc4rand_iniseed_state' from ARC4_ENTR_NONE -> ARC4_ENTR_HAVE, we would still call arc4_randomstir() periodically due to (tv.tv_sec > arc4_t_reseed) and (arc4_numruns > ARC4_RESEED_BYTES). The lacking part is forcing a arc4_randomstir() call the next arc4rand()/arc4random() call after the PRNG is initialized. However, I don't think this has a large impact. But, this situation isn't the big issue. We have an existing bug where if one is using a hardware RNG, read_random() never gets changed from simply being read_random_phony() due to random_modevent() not calling random_yarrow_init_harvester() thru '(*random_systat->init)()'. Thus arc4random() has been weak for thus using the Intel RDRAND or Via Padlock. This is something we're going to address, but this commit is an infrastructure improvement commit (decoupling one thing from another), not addressing existing bugs or short comings. thoughts? -- -- David (obr...@freebsd.org) ___ 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: r253786 - in head/sys: dev/random modules/padlock_rng modules/rdrand_rng modules/yarrow_rng
On Tue, Jul 30, 2013 at 11:24:00PM +0400, Andrey Chernov wrote: > > Do you have any specific concerns? > > What about arc4rand_iniseed_state code dead without yarrow loaded? I am look at that now. -- -- David (obr...@freebsd.org) ___ 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: r253786 - in head/sys: dev/random modules/padlock_rng modules/rdrand_rng modules/yarrow_rng
On Tue, Jul 30, 2013 at 11:50:34AM -0700, David O'Brien (@FreeBSD) wrote: > Please see if you cannot review the code within the tree with doing > a whiplash backout-recommit. s/with/without/ Please let me know if you're OK with taking this route. -- -- David (obr...@freebsd.org) ___ 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: r253618 - head/sys/dev/usb/gadget
On Wed, Jul 24, 2013 at 03:29:34PM -0400, John Baldwin wrote:
> On Wednesday, July 24, 2013 2:32:15 pm David E. O'Brien wrote:
> > per style(9):
> > Kernel include files (i.e. sys/*.h) come first; normally, include
> > OR , but not both. includes
> > , and it is okay to depend on that.
>
> This is not fully correct. The consistent style throughout the tree when
> using _FBSDID() is:
>
> #include
> __FBSDID()
>
> #include
> ...
>
> Please fix these to match that. It might not be a bad idea to document the
> __FBSDID() practice in style.9 while you are at it.
Hi John,
As BDE mentioned, the text [still] says it is OK to depend on
and including .
I was one of the ones that put __FBSDID() in much of our code. I used
a script to add the two lines:
#include
__FBSDID("$FreeBSD$");
I did it this way so as to not break the "but not both" rule for
and . In otherwords my script wasn't
smart enough to see if or was already
being included and put the '__FBSDID("$FreeBSD$");' right below it.
I don't feel
#include
__FBSDID("$FreeBSD$");
#include
is against style(9).
Should explicit language be added that one of ,
, or should be included first
followed by '__FBSDID("$FreeBSD$");' (when used). Followed
by all other headers.
--
-- David (obr...@freebsd.org)
___
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: r253786 - in head/sys: dev/random modules/padlock_rng modules/rdrand_rng modules/yarrow_rng
On Mon, Jul 29, 2013 at 02:43:15PM -0700, Steve Kargl wrote: > On Mon, Jul 29, 2013 at 08:58:10PM +, David E. O'Brien wrote: > > Author: obrien > > Date: Mon Jul 29 20:58:09 2013 > > New Revision: 253786 > > URL: http://svnweb.freebsd.org/changeset/base/253786 > > > > Log: > > > > * If the kernel doesn't have any random_adaptor adapters present > > then the creation of /dev/random is postponed until next > > random_adaptor is kldload'ed. > > I don't use modules. What is the magic I need to add to my > kernel config files? Perhaps, an entry in src/UPDATING is > needed. Hi Steve, >From the src/UPDATING entry :-) For example, to use Yarrow, add "options YARROW_RNG" to your kernel config. For hardware backed RNGs, use either "RDRAND_RNG" or "PADLOCK_RNG" options. -- -- David (obr...@freebsd.org) ___ 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: r253786 - in head/sys: dev/random modules/padlock_rng modules/rdrand_rng modules/yarrow_rng
On Tue, Jul 30, 2013 at 02:23:53PM +0200, Dag-Erling Smrgrav wrote: > "David E. O'Brien" writes: > > Log: > > Decouple yarrow from random(4) device. > > We've had a policy for several years now that all changes to the PRNG > code in the kernel and libc must be reviewed by so@. Hi DES, Where was this policy published or communicated? There is no MAINTAINER line in sys/dev/random/, nor an entry in /usr/src/MAINTAINERS. It is hard to follow some policy that cannot be found. > Please revert > this commit and submit your patch to sect...@freebsd.org for review. There was a lot of work put into this patch. 'make tenderbox', and much boot testing of various kernel configs on both i386, amd64, both IvyBridge and non-IvyBridge systems, ARM (Beaglebone) with both statically compiled in random(4) and loaded via modules. This change does not change any of the PRNG algorithms. Please see if you cannot review the code within the tree with doing a whiplash backout-recommit. Do you have any specific concerns? -- -- David (obr...@freebsd.org) ___ 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: r242102 - in head: contrib/bmake usr.bin/bmake
On Thu, Oct 25, 2012 at 11:18:06PM +, Simon J. Gerraty wrote: > Log: > Merge bmake-20121010 Hi Simon, I was kicking the tires on this and noticed bmake is dynamically linked. Can you change it to being statically linked? This issue most recently came up in freebsd-current. See thread pieces http://lists.freebsd.org/pipermail/freebsd-current/2012-April/033460.html http://lists.freebsd.org/pipermail/freebsd-current/2012-April/033472.html http://lists.freebsd.org/pipermail/freebsd-current/2012-April/033473.html -- -- David (obr...@freebsd.org) ___ 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: r240494 - in head: contrib/pf/man contrib/pf/pfctl include sbin/pfctl sbin/pfctl/missing share/man/man4 share/man/man5 sys/conf sys/contrib/pf sys/modules/dummynet sys/modules/ipfw sys
On Fri, Sep 14, 2012 at 11:51:51AM +, Gleb Smirnoff wrote: > Log: > o Create directory sys/netpfil, where all packet filters should > reside, and move there ipfw(4) and pf(4). > o Move most modified parts of pf out of contrib. Why didn't contrib/ipfilter/ move to sys/netpfil/ as well? Having 1/3 of our packet filters not there (sys/netpfil) might suggest we shouldn't create sys/netpfil/ -- -- David (obr...@freebsd.org) ___ 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: r241933 - head/sys/conf
On Mon, Nov 12, 2012 at 04:29:07PM -0800, David O'Brien (@FreeBSD) wrote: > $ diff -Bbw files.mips.r241680,sorted files.mips.r241933,sorted | egrep -v > '^(\+|-|@@)' | wc -l > 43 Sorry, should have better ensured all input lines appeared in the output. $ diff -u999 -Bbw files.mips.r241680,sorted files.mips.r241933,sorted | egrep -v '^(\+|-|@@)' | wc -l 61 Using your immediate r241936 follow on commit: $ diff -u999 -Bbw files.mips.r241680,sorted files.mips.r241936,sorted | egrep -v '^(\+|-|@@)' | wc -l 68 And by end of the day (r242031, all your commits to this file on the 23rd): $ diff -u999 -Bbw files.mips.r241680,sorted files.mips.r241986,sorted | egrep -v '^(\+|-|@@)' | wc -l 84 -- -- David (obr...@freebsd.org) ___ 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: r241933 - head/sys/conf
On Tue, Oct 23, 2012 at 02:58:25PM +, Warner Losh wrote: > Log: > Start a clean-room implementation of files.mips. This is sufficient > for SWARM64 and SWARM64_SMP to compile. Other kernels will be layered > in. > Modified: > head/sys/conf/files.mips ... > -# Copyright (c) 2001, 2004-2005, Juniper Networks, Inc. > -# All rights reserved. > -# JNPR: files.mips,v 1.11 2007/08/09 12:25:35 katta Hi Warner, What is the purpose of this? $ diff -Bbw files.mips.r241680,sorted files.mips.r241933,sorted | egrep -v '^(\+|-|@@)' | wc -l 43 So some of the content did "filter through" the clean room. Who did the "clean-room" implementation? If you, is it really a clean-room reimplementation? You're so familiar with this file are you really able to do such a thing? -- -- David (obr...@freebsd.org) ___ 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: r239730 - head/sys/i386/include
On Mon, Aug 27, 2012 at 01:22:28PM +, Dag-Erling Smrgrav wrote: > Author: des > Date: Mon Aug 27 13:22:27 2012 > New Revision: 239730 > URL: http://svn.freebsd.org/changeset/base/239730 > > Log: > Parly revert r239255: reinstate a default maxswzone on i386, where KVA is > scarce, but set it slightly higher so we can handle 8 GB of swap. Thank you for dealing with this issue. I had a diff addressing this I had prepared but had yet to send to alc for review. The comment below says to me the target swap size is 16GB, not 8GB. >From recent 10-CURRENT experience where I hit the VM_SWZONE_SIZE_MAX limit many times I think shooting for 16GB is more realistic with today's desktop application mix. Or at least 12GB if KVA usage for supporting 16GB is a concern. All it took to hit this was a 2GB tmpfs and running two web browsers with many tabs open. > + * 276 is sizeof(struct swblock), but we do not always have a definition > + * in scope for struct swblock, so we have to hardcode it. Each struct > + * swblock holds metadata for 32 pages, so in theory, this is enough for > + * 16 GB of swap. In practice, however, the usable amount is considerably > + * lower due to fragmentation. The old definition from r102738 (dillon 2002-08-31) was "32 * 1024 * 1024" or 32MB. This allowed for 7GB of swap from a 16GB swap partition, per top(8)'s "Swap total" reporting of swap usage when I would get kernel: swap zone exhausted, increase kern.maxswzone kernel: pid 81073 (firefox-bin), uid 1765, was killed: out of swap space every couple of days. > +#define VM_SWZONE_SIZE_MAX (276 * 128 * 1024) Will 34.5MB, really allow 16GB swap? On the machine you tested this on, what did top(8) report when the swap partition was say 20GB? thanks, -- -- David (obr...@freebsd.org) ___ 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: r239568 - head/etc/rc.d
On Wed, Aug 22, 2012 at 02:37:37PM -0700, Doug Barton wrote: > Were these changes discussed somewhere and I missed it? They were not discussed. I did not see the need. This is simple functionality. If securelevel is raised > 0, one cannot start up a firewall nor make major changes to time. Thus these components are required to be done before raising securelevel. > I'm not opposed per se, but the security aspects should be discussed on > freebsd-security@, I'm sorry, I didn't feel that ensuring the software follows the published specification of its functionality to have such a security aspect. > and it's preferable that significant changes to > rcorder be looked at on freebsd-rc@ as well. I don't consider this to be a significant change. I do have some significant changes that I do want freebsd-rc@ to review I will be sending soon. > Can you hold off on MFC'ing any of this until it's been reviewed more > thoroughly? Yes. -- -- David (obr...@freebsd.org) ___ 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: r237624 - in head: cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize cddl/contrib/opensolaris/lib/libdtrace/common sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/
On Mon, Jul 02, 2012 at 04:10:26PM -0700, Pedro Giffuni wrote:
> --- Lun 2/7/12, David O'Brien ha scritto:
> I tend to agree with the Illumos community on that however
> we may still be seeing some movement in that area. Oracle
> has a linux distribution and commercial interests are
> always strong in unpredicable ways.
>
> Oracle has been porting Dtrace to Linux. Apparently they
> will be adopting dual GPLv2/CDDL for some few kernel
> stuff and CDDL only for the main code, but just the same
> there may be some stuff we want to take from them.
That may be the case -- but what is the likelihood there would be code
from that effort we would want? Vs. the real brain-share of DTrace
which commits into Illumos? Isn't it much more likely we would want
their innovations?
> > It may be conceptually cleaner to import into
> > '^/vendor{,-sys}/illumos', but I believe that will cause
> > issues with importing updates to existing files
> > (e.g., r237458) as the 'svn merge'
> > from '^/vendor{,-sys}' will get messy.? I believe we
> > may have to resort
> > to a three-way merge using "--ignore-ancestry" -- something
> > I don't believe we want to do.
>
> I think Martin Matuska did exactly the right thing:
> he created the illumos vendor branch starting from
> the opensolaris branch.
I don't disagree in principle, but I feel it should have been an
'svn rename' not 'svn copy'.
You didn't suggest or comment on the SCM operations having two
"vendors" puts us in. I don't think you can make precise statements
about an illumos vendor branch without considering those.
> Concerning ZFS: the main developer of the encryption stuff
> did stay at Oracle. At this time that code will not be seen
> in the open (apparently there was a Solaris 11 source leak
> but that's not something we can touch), but we just never
> know.
We can always figure out something *if* it comes to pass that
there is a code drop from Oracle that we want to consume.
I believe the question which code base are we *most likely*
to pull technology from. The proof to date in an 'svn log'
of our repo is Illumos.
> > Doesn't this commit of yours which brought in new DTrace
> > work by Joyent
> > (likely Brendan Gregg or Bryan Cantrill) show this point?
> >
> > Perhaps we should do an 'svn move' of
> > '^/vendor{,-sys}/opensolaris'
> > to '^/vendor{,-sys}/illumos'?
>
> Illumos is a fork so svn copy works just fine for this, plus
> copying is a very cheap operation in SVN.
That misses my point. Yes, copying is a very cheap operation in SVN.
(so is 'svn rename')
The issue is should we have _two_ vendors that we are attempting to
merge into the same files within HEAD?
--
-- David (obr...@freebsd.org)
___
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: r237624 - in head: cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize cddl/contrib/opensolaris/lib/libdtrace/common sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/
On Sun, Jul 01, 2012 at 08:32:41PM -0700, Doug Barton wrote: > On 06/29/2012 10:58, Pedro Giffuni wrote: > > Now .. David pointed out I am not respecting the code > > provenance since I didn't add them to the opensolaris > > vendor area, but these files are copyrighted Joyent > > Inc (not even Illumos) so I cannot put them there > > unless we create a new vendor for Joyent > > Creating a new vendor area would be the right solution, yes. I totally disagree -- it will cause a real pain merging. Think about it -- if we import a new code drop of uts/common/fs/zfs/*.c into '^/vendor-sys/illumos', how do we merge that to HEAD? I don't believe 'svn merge -c ' will work because we already have a different uts/common/fs/zfs/*.c from ^/vendor-sys/opensolaris. I think we either need to just call Illumos OpenSolaris for these purposes, or 'svn move opensolaris illumos'. I think this needs to be discussed with the Repo Meisters. -- -- David (obr...@freebsd.org) ___ 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: r237624 - in head: cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize cddl/contrib/opensolaris/lib/libdtrace/common sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/
On Fri, Jun 29, 2012 at 10:09:08AM -0700, Pedro Giffuni wrote:
> You are absolutely right. However I am not sure we should
> bring Illumos enhancements under the opensolaris vendor
> branch. The reason is that this files are CDDL'd but are
> there was no property assignment done to the OpenSolaris
> copyright owner. [1]
I've closely followed the Illumos project (if you're every visiting the
Silicon Valley at the right time they have some good usergroup talks).
At this point Illumos is the continuation of OpenSolaris.
When Solaris 11 came out there was a discussion about if Oracle will
fulfill the statement in their leaked email about publishing sources
again. There is little to no hope in the Illumos community this will
ever happen.
[http://www.listbox.com/member/archive/182180/2011/11/sort/thread/page/1/
"Solaris 11 released -- chances of source code to follow?"]
[https://blogs.oracle.com/orasysat/entry/summary_of_the_solaris_11
"Any plans to release Solaris 11 source code? i.e. opensolaris?"
So I am comfortable with using the Illumos repository as the master
source for '^/vendor{,-sys}/opensolaris'. But I recognize not everyone
may feel this way. So we should discuss how to handle
OpenSolaris-derived Intellectual Property.
It may be conceptually cleaner to import into
'^/vendor{,-sys}/illumos', but I believe that will cause issues with
importing updates to existing files (e.g., r237458) as the 'svn merge'
from '^/vendor{,-sys}' will get messy. I believe we may have to resort
to a three-way merge using "--ignore-ancestry" -- something I don't
believe we want to do.
Thus I think this needs to be discussed with the repo Meisters.
> If somehow Oracle decides to relicense Dtrace or ZFS we
> still must keep these changes isolated from the code
> provided in the vendor branch.
I don't quite follow.
Lets suppose we don't import anything from Illumos, but wait for the
Solaris 11 code drop. Should DTrace or ZFS be relicensed, IMHO it
should still get imported into '^/vendor{,-sys}/opensolaris' as that
is the progression of that Intellectual Property.
'^/vendor{,-sys}/opensolaris' states no license. What we would have to
do is 'svn move' the resulting merge outside of 'head/{,sys}/cddl/'.
> I think we have to decide if we are going to consider
> Illumos a vendor on it's own. For ZFS it would seem
> the right thing to do, for Dtrace I am not sure: at
> least I am not considering bringing any other feature
> at this time.
Given the number of primary authors & architects of both ZFS and
DTrace that have left Oracle/Sun, the works of those folks are the
things I believe FreeBSD is interested in. In fact the ZFS Working
Group is external to Oracle and Solaris.
Doesn't this commit of yours which brought in new DTrace work by Joyent
(likely Brendan Gregg or Bryan Cantrill) show this point?
Perhaps we should do an 'svn move' of '^/vendor{,-sys}/opensolaris'
to '^/vendor{,-sys}/illumos'?
What are your thoughts?
--
-- David (obr...@freebsd.org)
___
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: r237624 - in head: cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize cddl/contrib/opensolaris/lib/libdtrace/common sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/
On Wed, Jun 27, 2012 at 04:39:30AM +, Pedro F. Giffuni wrote: > Log: > Bring llquantize support into Dtrace. > Bryan Cantrill implemented the equivalent of semi-log graph > paper for Dtrace so llquantize will use one logarithmic and > one linear scale. ... > Obtained from: Illumos ... > Added: > head/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize/err.D_LLQUANT_FACTOREVEN.nodivide.d > == > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ > head/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize/err.D_LLQUANT_FACTOREVEN.nodivide.d >Wed Jun 27 04:39:30 2012(r237624) > @@ -0,0 +1,29 @@ > +/* > + * CDDL HEADER START > + * > + * The contents of this file are subject to the terms of the > + * Common Development and Distribution License (the "License"). > + * You may not use this file except in compliance with the License. ... > +/* > + * Copyright (c) 2011, Joyent, Inc. All rights reserved. > + */ Pedro, It looks like you simply 'svn add'ed this file, rather than importing it into '^/vendor/opensolaris/dist'. Please correct me if I am wrong. We've become rather sloppy in the past 1-2 years in our handling of 3rd-party externally developed code. Something we need to return to our older ways good ways of handling. This is something that is especially important with GPL, CDDL, and similar licenses. Commercial entities that base products on FreeBSD have to worry about code provenance for various intellectual property legal reasons and we muddy the waters when we make it harder to track who and where code came from. [Please see http://www.osgeo.org/incubator/process/codereview.html & http://wiki.osgeo.org/wiki/Code_Provenance_Review to better understand this issue.] Not following our established procedure also means that the average developer(committer) and commercial consumer will have their expectations fail. One expects to be able to find the stock vendor sources in ssh://svn.freebsd.org/base/vendor/ and to be able to find FreeBSD local changes to the sources thru 'svn diff' against 'ssh://svn.freebsd.org/base/head'. Please correct this by properly importing the sources, 'svn delete'ing the files you 'svn add'ed, and do an 'svn copy' of the new files. thanks, -- -- David (obr...@freebsd.org) ___ 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: r236593 - head/share/man/man4
On Tue, Jun 05, 2012 at 11:07:48AM +1200, Andrew Thompson wrote: > Does the race have to be managed between the parent SET_PID ioctl and > the child doing something? Thank you for catching that. I committed an older version of that. (had copies of this on multiple machines...) -- -- David (obr...@freebsd.org) ___ 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: r236338 - head/usr.bin/make
On Thu, May 31, 2012 at 08:35:54PM -0600, Warner Losh wrote: > What are your MFC plans for 9.x and 8.x? I'd like to commit to both 8 and 9 for the next release of each. > > .It Cm :L > > Converts variable to lower-case letters. > > +(deprecated) ... > > +The use of the > > +.Cm :L > > +and > > +.Cm :U > > +modifiers are deprecated > > +in > > +.Fx 10.0 Though I am wondering if the man page language should be tweaked to not say "deprecated" given it would go into 9.1 and 8.3 -- i.e., mid-stream releases. Thoughts? -- -- David ___ 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: r236255 - head/contrib/groff/tmac
On Wed, May 30, 2012 at 07:34:33AM +0400, Sergey Kandaurov wrote: > On 29 May 2012 23:49, David E. O'Brien wrote: ... > > Modified: head/contrib/groff/tmac/doc-common ... > > +.ds doc-operating-system-FreeBSD-8.3 ? ? 8.3 > > +.ds doc-operating-system-FreeBSD-9.1 ? ? 9.1 > > +.ds doc-operating-system-FreeBSD-10.0 ? ?10.0 > This should be imported from savannah.gnu.org repository, > and not changed directly. Unfortunately we cannot do that per r217595: This is a direct commit to contrib/ as we will no longer import any newer groff snapshots, due to licensing issues. > For local changes not found in the (latest) contrib doc-common > you should use gnu/usr.bin/groff/tmac/mdoc.local I followed r217595, was that commit the wrong approach? -- -- David (obr...@freebsd.org) ___ 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: r235797 - head/contrib/gcc
On Tue, May 22, 2012 at 02:07:22PM -0700, m...@freebsd.org wrote: > We run with the following at Isilon, which is somewhat bogus because > it allows a bit of sloppiness in types, but is also terribly > convenient since it means no casting on printf arguments is needed: ... > If there's no objections, I (or David or anyone else) can commit to > the FreeBSD repository. Unfortunately I don't like this change -- it promotes type sloppiness that flies in the face of ISO/IEC 9899:1999 (E). the mixed definition of [u]_?int64_t as it catches improper code -- such as assuming you can printf an int64_t with "%lld" when that is against the standard. -- -- David (obr...@freebsd.org) ___ 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: r235797 - head/contrib/gcc
On Wed, May 23, 2012 at 01:49:45PM +0200, Dimitry Andric wrote: > On 2012-05-22 20:18, David E. O'Brien wrote: > > Log: > > Do not incorrectly warn when printing a quad_t using "%qd" on 64-bit > > platforms. ... > Until all the additional warnings this causes have been fixed, can this > commit please be reverted for now? Yes. I cannot believe we've been abusing "%q" this badly. -- -- David (obr...@freebsd.org) ___ 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: r235623 - in head/contrib/gcc: . config/rs6000 config/sparc
On Fri, May 18, 2012 at 07:02:40PM +, Pedro F. Giffuni wrote: > Log: > Bring in a subset of gcc fixes that were back ported to > the GCC 4.1 branch and are available under GPLv2. I do not understand this -- We're using GCC 4.2.1 @r127959, but you are bringing in patches that are against 4.1. What version of GCC were the changes back ported from if not 4.2.0 or 4.2.1? BTW, these also should have been imported into ^/vendor/gcc/ and then merged into ^/head/contrib/gcc as there are commercial users of FreeBSD that have to modify their compiler to be able to consume FreeBSD source code. And provenance and licensing matters to these folks. -- -- David (obr...@freebsd.org) ___ 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: r228153 - head/usr.sbin/config
On Wed, Nov 30, 2011 at 01:33:09PM +, Max Khon wrote:
> Log:
> Generate ${NORMAL_CTFCONVERT} invocation without '@' modifier:
> - ${NORMAL_CC} is also invoked without '@'
> - Userland CTF support was changed previously to echo ctfconvert
> invocations too
Thank you for your work on cleaning up the CTF part of the build.
Enabling WITH_CTF has been too different (and conflicting) from our
other knobs.
I also had local patches to not hide ctfconvert so one could easily see
when they didn't have WITH_CTF enabled in the right magical incantations.
Will you be MFC'ing the CTF build work? Please. :-)
--
-- David (obr...@freebsd.org)
___
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: r228196 - in head: share/mk tools/build/options
On Fri, Dec 02, 2011 at 09:09:54AM +, Max Khon wrote: > Log: > Revert to conservative defaults. WITH_PROFILE is a default now. Thank you. > NO_PROFILE overrides in Makefile.inc1 and bsd.own.m are left intact > so that the reversal to the WITHOUT_PROFILE will be easier in future. As I mentioned, it may make sense to not build profiled libs by default in -stable. But if you do that, please add logic to 'make release' to build profiled libs -- putting them in either base.txz or proflibs.txz (or however you find tasteful). -- -- David (obr...@freebsd.org) ___ 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: r226090 - head/sys/sys
On Fri, Oct 07, 2011 at 02:14:46PM +0300, Andriy Gapon wrote: > > Increase MSGBUF_SIZE. > > The previous size lead to truncated /var/run/dmesg.boot when booted with > > "-v". ... > Heck, I am going to five! :-) Do you know of a machine that needs "* 5"? I went with the miniumum increase that gave a full /var/run/dmesg.boog on a particlar machine. But I know this machine more probably isn't the one that produces the largest output during boot. Bump it higher than "* 3"? -- -- David (obr...@freebsd.org) ___ 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: r226089 - in head: share/man/man7 sys/kern
On Fri, Oct 07, 2011 at 02:14:08PM +0300, Andriy Gapon wrote: > > Log: > > Disallow various debug.kdb sysctl's when securelevel is raised. .. > Maybe the same would also be a good idea for sysctls defined at the top of > sys/kern/kern_shutdown.c? Thanks for pointing those out. I'll take a look. -- -- David (obr...@freebsd.org) ___ 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: r225617 - in head/sys: amd64/amd64 amd64/linux32 arm/arm cddl/contrib/opensolaris/uts/common/dtrace cddl/contrib/opensolaris/uts/sparc/dtrace compat/freebsd32 compat/linux compat/svr4
On Fri, Sep 16, 2011 at 01:58:51PM +, Kip Macy wrote: > Author: kmacy > Date: Fri Sep 16 13:58:51 2011 > New Revision: 225617 > Log: > In order to maximize the re-usability of kernel code in user space this > patch modifies makesyscalls.sh to prefix all of the non-compatibility > calls (e.g. not linux_, freebsd32_) with sys_ and updates the kernel > entry points and all places in the code that use them. It also Hi Kip, __FreeBSD_version does not seem to have been bumped for this. Unfortunately this change has made a kernel module we use at work unbuildable, and I don't have a __FreeBSD_version value to #ifdef on. If ever there was a change that needed __FreeBSD_version this is one. Can you please get __FreeBSD_version bumped in 9-STABLE along with 9-RELENG? thanks, -- -- David (obr...@freebsd.org) ___ 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: r225868 - head/bin/ps
On Sat, Oct 01, 2011 at 12:43:23PM +, Alexander Best wrote: > we could then add an envar $PS, so users can set PS=-k to restore the Should be spelled "PS_OPTIONS" please. Many of us likely have "export PS=_" in order to have dot files that support multiple OS's. This is also in-line with FreeBSD's existing "MALLOC_OPTIONS", "DIFF_OPTIONS", "GREP_OPTIONS", "GCC_OPTIONS", etc... -- -- David (obr...@freebsd.org) ___ 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: r221071 - in head: . sys/amd64/conf sys/arm/conf sys/cam sys/cam/ata sys/conf sys/geom sys/i386/conf sys/mips/conf sys/modules/cam sys/pc98/conf
On Tue, Apr 26, 2011 at 05:01:49PM +, Alexander Motin wrote: > Log: >- Add shim to simplify migration to the CAM-based ATA. For each new adaX > device in /dev/ create symbolic link with adY name, trying to mimic old ATA > numbering. Imitation is not complete, but should be enough in most cases to > mount file systems without touching /etc/fstab. >- To know what behavior to mimic, restore ATA_STATIC_ID option in cases > where it was present before. >- Add some more details to UPDATING. [picking a random ata(4) CAM commit] Alexander, What are your plans on updating the ata.4 man page for 9.0-RELEASE? It still speaks of the old world order and doesn't provide help for folks trying to convert over. thanks, -- -- David (obr...@freebsd.org) ___ 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: r221053 - head/usr.bin/rlogin
On Tue, Apr 26, 2011 at 07:27:11AM -0600, Warner Losh wrote: > I read the test log as "not really tested, feel free to back it out if > it fails on a different architecture" Irregardless of the reasons for a build break -- one should feel free to fix or back the change out until the change can be revisited. > :) :-)) -- -- David (obr...@freebsd.org) ___ 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: r221053 - head/usr.bin/rlogin
On Wed, Apr 27, 2011 at 10:48:33AM -0400, John Baldwin wrote: > For changing WARNS, 'make universe' works well I have to disagree. Due to its silent failing, it is only suitable for what PHK added it for -- "what if" changes. [Message-ID: <13101.1227520...@critter.freebsd.dk>] One has to do all the various greps of the output in order to be confident of their belief of the results. We really need a new target that builds more normal (fails on first error) and makes it obvious when there is a failure. -- -- David (obr...@freebsd.org) ___ 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: r221053 - head/usr.bin/rlogin
On Tue, Apr 26, 2011 at 09:32:44AM -0400, John Baldwin wrote: > On Tuesday, April 26, 2011 12:09:20 am David E. O'Brien wrote: > > Author: obrien > > Date: Tue Apr 26 04:09:20 2011 > > New Revision: 221053 > > URL: http://svn.freebsd.org/changeset/base/221053 > > > > Log: > > This builds OK using the parent dir's WARNS=6. > > [built on both AMD64 and i386] > > This breaks the tinderbox on at least arm, ia64, mips, and sparc64. Sigh. Do we yet have ARM, MIPS, or Sparc64 test machines in the cluster? http://www.freebsd.org/internal/machines.html doesn't list any, but maybe some have been added? -- -- David (obr...@freebsd.org) ___ 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: r220497 - head/lib/libcrypt
On Sat, Apr 09, 2011 at 02:02:04PM +, Mark Murray wrote:
> Log:
> Add SHA256/512 ($5$ and $6$) to crypt(3). Used in linux-world, doesn't
> hurt us.
Would you mind if I committed this to be a more consistent with the
existing naming?
Index: crypt.c
===
--- crypt.c (revision 221053)
+++ crypt.c (working copy)
@@ -64,12 +64,12 @@ static const struct {
},
{
"sha256",
- sha256_crypt,
+ crypt_sha256,
"$5$"
},
{
"sha512",
- sha512_crypt,
+ crypt_sha512,
"$6$"
},
{
Index: crypt-sha512.c
===
--- crypt-sha512.c (revision 221053)
+++ crypt-sha512.c (working copy)
@@ -60,7 +60,7 @@ static const char sha512_rounds_prefix[]
#define ROUNDS_MAX 9
static char *
-sha512_crypt_r(const char *key, const char *salt, char *buffer, int buflen)
+crypt_sha512_r(const char *key, const char *salt, char *buffer, int buflen)
{
u_long srounds;
int n;
@@ -280,12 +280,12 @@ sha512_crypt_r(const char *key, const ch
/* This entry point is equivalent to crypt(3). */
char *
-sha512_crypt(const char *key, const char *salt)
+crypt_sha512(const char *key, const char *salt)
{
/* We don't want to have an arbitrary limit in the size of the
* password. We can compute an upper bound for the size of the
* result in advance and so we can prepare the buffer we pass to
-* `sha512_crypt_r'. */
+* `crypt_sha512_r'. */
static char *buffer;
static int buflen;
int needed;
@@ -305,7 +305,7 @@ sha512_crypt(const char *key, const char
buflen = needed;
}
- return sha512_crypt_r(key, salt, buffer, buflen);
+ return crypt_sha512_r(key, salt, buffer, buflen);
}
#ifdef TEST
@@ -482,7 +482,7 @@ main(void)
}
for (cnt = 0; cnt < ntests2; ++cnt) {
- char *cp = sha512_crypt(tests2[cnt].input, tests2[cnt].salt);
+ char *cp = crypt_sha512(tests2[cnt].input, tests2[cnt].salt);
if (strcmp(cp, tests2[cnt].expected) != 0) {
printf("test %d: expected \"%s\", got \"%s\"\n",
Index: crypt.h
===
--- crypt.h (revision 221053)
+++ crypt.h (working copy)
@@ -36,8 +36,8 @@ char *crypt_des(const char *pw, const ch
char *crypt_md5(const char *pw, const char *salt);
char *crypt_nthash(const char *pw, const char *salt);
char *crypt_blowfish(const char *pw, const char *salt);
-char *sha256_crypt (const char *pw, const char *salt);
-char *sha512_crypt (const char *pw, const char *salt);
+char *crypt_sha256 (const char *pw, const char *salt);
+char *crypt_sha512 (const char *pw, const char *salt);
extern void _crypt_to64(char *s, u_long v, int n);
extern void b64_from_24bit(uint8_t B2, uint8_t B1, uint8_t B0, int n, int
*buflen, char **cp);
Index: crypt-sha256.c
===
--- crypt-sha256.c (revision 221053)
+++ crypt-sha256.c (working copy)
@@ -60,7 +60,7 @@ static const char sha256_rounds_prefix[]
#define ROUNDS_MAX 9
static char *
-sha256_crypt_r(const char *key, const char *salt, char *buffer, int buflen)
+crypt_sha256_r(const char *key, const char *salt, char *buffer, int buflen)
{
u_long srounds;
int n;
@@ -268,12 +268,12 @@ sha256_crypt_r(const char *key, const ch
/* This entry point is equivalent to crypt(3). */
char *
-sha256_crypt(const char *key, const char *salt)
+crypt_sha256(const char *key, const char *salt)
{
/* We don't want to have an arbitrary limit in the size of the
* password. We can compute an upper bound for the size of the
* result in advance and so we can prepare the buffer we pass to
-* `sha256_crypt_r'. */
+* `crypt_sha256_r'. */
static char *buffer;
static int buflen;
int needed;
@@ -293,7 +293,7 @@ sha256_crypt(const char *key, const char
buflen = needed;
}
- return sha256_crypt_r(key, salt, buffer, buflen);
+ return crypt_sha256_r(key, salt, buffer, buflen);
}
#ifdef TEST
@@ -459,7 +459,7 @@ main(void)
}
for (cnt = 0; cnt < ntests2; ++cnt) {
- char *cp = sha256_crypt(tests2[cnt].input, tests2[cnt].salt);
+ char *cp = crypt_sha256(tests2[cnt].input, tests2[cnt].salt);
if (strcmp(cp, tests2[cnt].expected) != 0) {
printf("test %d: expected \"%s\", got \"%s\"\n",
___
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-unsub
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 Sun, Apr 24, 2011 at 08:58:58AM +, Alexander Motin wrote: > Log: > Switch the GENERIC kernels for all architectures to the new CAM-based ATA > stack. It means that all legacy ATA drivers are disabled and replaced by > respective CAM drivers. If you are using ATA device names in /etc/fstab or > other places, make sure to update them respectively (adX -> adaY, > acdX -> cdY, afdX -> daY, astX -> saY, where 'Y's are the sequential > numbers for each type in order of detection, unless configured otherwise > with tunables, see cam(4)). I apologize if I missed a past discussion... but wasn't CAM designed so that all disk-like things would be 'da' (direct access) irregardless of underling protocol (SCSI/SAS/PATA/SATA)? "afdX -> daY" above helps suggest this. Wasn't that the reason we moved from 'sd' to 'da'? At least this was the impression on freebsd-current@ back when we when thru this in 1999 (e.g., <36eff7c2.41c67...@whistle.com>, <4714.920569...@verdi.nethelp.no>, <29382.921672...@verdi.nethelp.no>, <199903172035.paa07...@khavrinen.lcs.mit.edu>). Now ATA-CAM is the default, why aren't disks devices named by the established CAM names? If we're not going to call CAM controlled ATA disks "da", then why not keep the existing "ad" and "ar" given "ad" stood for "ATA-Disk" and "ATA-RAID" -- you're still calling the subsystem "ata". Otherwise, we can just recycle email from 1999 where folks didn't see much value in the sd->da change. -- -- David (obr...@freebsd.org) ___ 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: r220370 - in head: etc/mtree include lib/libedit lib/libedit/edit lib/libedit/edit/readline sbin/gvinum usr.sbin/ntp/ntpdc usr.sbin/ntp/ntpq usr.sbin/wpa/wpa_cli
On Tue, Apr 05, 2011 at 03:47:56PM -0400, John Baldwin wrote: > On Tuesday, April 05, 2011 2:41:01 pm David E. O'Brien wrote: > > URL: http://svn.freebsd.org/changeset/base/220370 > > Log: > > * Add the readline(3) API to libedit. The libedit versions of [..] > > Obtained from:NetBSD > > Sponsored by: Juniper Networks > > Should libedit move to contrib? Possibly -- it would make sense as Christos Zoulas is the original author and has been actively maintaining it since conception. Other than the jilles added in the past year, we haven't really made much creative changes to it since 4.4BSD. But we have made a lot of changes to it over the years. Many of our "syncs" just took snippets from NetBSD -- right now 'svn diff ^/vendor/NetBSD/libedit/dist ^/head/lib/libedit | wc -l' reports 12717 lines; or "51 files changed, 871 insertions, 2113 deletions, 3382 modifications" according to diffstat(1). So maybe hold the question until the diff is smaller?? -- -- David (obr...@freebsd.org) ___ 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: r216473 - head/sbin/geom/class/eli
On Thu, Dec 16, 2010 at 12:27:04PM -0800, Xin LI wrote: > On 12/16/10 12:23, Ulrich Sp??rlein wrote: > > Shamless plug: the attached, crude expect(1) script allows you to do > > $ cd /usr/src && universe-build sbin/geom WARNS=6 > > > > with the minimal amount of compilation (you have to build the toolchain > > once, though). I found it invaluable. > > I think we could probably put that in src/tools/somewhere... Ulrich, Yes, please. -- -- David (obr...@freebsd.org) ___ 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: r216473 - head/sbin/geom/class/eli
On Thu, Dec 16, 2010 at 12:25:31PM -0500, John Baldwin wrote: > On Wednesday, December 15, 2010 7:36:10 pm David E. O'Brien wrote: > > Author: obrien > > Date: Thu Dec 16 00:36:10 2010 > > New Revision: 216473 > > URL: http://svn.freebsd.org/changeset/base/216473 > > > > Log: > > Bump WARNS to 6. > > > > Modified: > > head/sbin/geom/class/eli/Makefile > > FYI, this broke the tinderbox on arm, ia64, mips, and sparc64. Errr. Reverted. I built it on the architectures I had access to... -- -- David (obr...@freebsd.org) ___ 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: r214961 - head/usr.bin/yacc
On Sun, Nov 07, 2010 at 05:54:20PM -0800, Juli Mallett wrote: > On Sun, Nov 7, 2010 at 15:22, David E. O'Brien wrote: > > Author: obrien > > Date: Sun Nov ?7 23:22:42 2010 > > New Revision: 214961 > > URL: http://svn.freebsd.org/changeset/base/214961 > > > > Log: > > ?Directly use memory allocation functions and remove needless casts in > > ?their usage. ?Also use associated modern types instead of k&r ones. > > You do know that changing skeleton.c affects the generated files, > right? Yes Juli, I know how byacc works. > I'm wondering if whatever sed script you're > judiciously-applying knows that. C++ does not do implicit conversions > from "void *" so you need the casts on the mallocs there. The changes I made were tested on building several other applications. > With a C++ compiler: But as you indirectly point out -- they were all C applications. -- -- David (obr...@freebsd.org) ___ 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: r213744 - head/bin/sh
On Wed, Oct 13, 2010 at 09:07:59AM -0400, John Baldwin wrote: > To be honest, I think changing STATIC is excessive churn. At this point I'm just making everything consistently "static" so that folks that add to ash won't need to realize that "STATIC" exists. Some of the folks making various FreeBSD changes did not realize this and created inconsistencies. Surely this inconsistency isn't desired. > The "right" fix > is to use 'make DEBUG_FLAGS="-g -DDEBUG=2 -fno-inline"'. I often use > 'make DEBUG_FLAGS="-g -fno-inline"' to workaround excessive inlining when I've added "-fno-inline" to DEBUG_FLAGS and will leave it up to others if that spelling isn't accepted by clang, Intel C, or what ever compiler someone may want to use. -- -- David (obr...@freebsd.org) ___ 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: r213744 - head/bin/sh
On Wed, Oct 13, 2010 at 03:29:27PM +1100, Bruce Evans wrote: > Add __noinline or whatever attributes to STATIC (but keep static in > it) for the DEBUG >= 3 case if you are going that far. __noinline > should be a syntax error for variables, so this should also find any > STATICs still on variables. The spelling fix of changing STATIC to > what it actually means > (ASSORTED_HACKS_FOR_DEBUGGING_BUT_NOW_ONLY_FOR_FUNCTIONS) goes too far > for me. I've make all uses "static". Otherwise we have some of the functions and variable "STATIC" (if from 4.4BSD), and some others "static" (added later by FreeBSD). Surely this inconsistency isn't desired. -- -- David (obr...@freebsd.org) ___ 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: r213744 - head/bin/sh
On Wed, Oct 13, 2010 at 02:18:33PM +1100, Bruce Evans wrote: > On Tue, 12 Oct 2010, David E. O'Brien wrote: >> Log: >> If DEBUG is 3 or greater, disable STATICization of functions. >> Also correct the documented location of the trace file. > > Private functions should always be static, which no `#define STATIC static' [..] > In theory, the debugging info should make it possible for debuggers > to restore the semantics of not-explictly-inline functions by virtualizing > them, but gdb's debugging info and/or gdb are too primitive to do this > (gdb doesn't allow putting a breakpoint at a deleted static function, This is actually what my motivation is -- trying to set breakpoints and finding GDB was unable to. > Of course, debugging and profiling are magic, > but I don't want to have to adorn all functions with STATICs and > __attributes() (and pragmas for othercc...) to recover historical/normal > or variant debugging or profiling of them. I agree, and would not add STATIC's to a program's code that didn't already have them. But in this case we inherited it from 4.4BSD. I'm just making it actually do something other than being a gratuitous spelling change. I believe I've made things more consistent with r213760. -- -- David (obr...@freebsd.org) ___ 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: r212904 - in head: contrib/llvm contrib/llvm/autoconf contrib/llvm/autoconf/m4 contrib/llvm/bindings/ada/llvm contrib/llvm/bindings/ocaml/llvm contrib/llvm/include/llvm contrib/llvm/in
On Mon, Sep 20, 2010 at 04:43:19PM +, Dimitry Andric wrote: > Author: dim > Date: Mon Sep 20 16:43:17 2010 > New Revision: 212904 > Log: > Upgrade our Clang in base to r114020, from upstream's release_28 branch. .. > head/contrib/llvm/tools/llvmc/examples/ > - copied from r212799, vendor/llvm/dist/tools/llvmc/examples/ .. > head/contrib/llvm/tools/llvmc/example/Hello/Hello.cpp We seem to now have contrib/llvm/tools/llvmc/example and contrib/llvm/tools/llvmc/examples Can one be svn rm'ed? Or preferably, both? -- -- David (obr...@freebsd.org) ___ 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: r212374 - head/usr.bin/printf
On Thu, Sep 16, 2010 at 09:36:43PM +1000, Bruce Evans wrote:
> On Thu, 16 Sep 2010, David O'Brien wrote:
>> Is a sentence or two a burden to the man page vs. saving someone the time
>> I spent trying to figure out why printf(1) kept throwing up errors?
>
> WHat about the lesser burder on a character or two for putting -- in the
> synopsis where it is more visible:
>
> printf [--] format [arguments ...]
>
> POSIX doesn't do this, and it doesn't seem to say anything about the
> problem of a leading - in the format either. Presumably its general
> utilities specs require _all_ utilities to support "--".
That would be fine for me too, if its prefered that way.
Index: printf.1
===
--- printf.1(revision 212773)
+++ printf.1(working copy)
@@ -43,6 +43,7 @@
.Nd formatted output
.Sh SYNOPSIS
.Nm
+.Op Fl -
.Ar format Op Ar arguments ...
.Sh DESCRIPTION
The
@@ -51,6 +52,13 @@ utility formats and prints its arguments
of the
.Ar format .
The
+.Fl -
+option prevents any interpretation of a leading dash ("-") character in
+.Ar format
+as a
+.Nm
+program option.
+The
.Ar format
is a character string which contains three types of objects: plain characters,
which are simply copied to standard output, character escape sequences which
@@ -355,10 +363,3 @@ Multibyte characters are not recognized
a problem if
.Ql %
can appear inside a multibyte character).
-.Pp
-Trying to print a dash ("-") as the first character causes
-.Nm
-to interpet the dash as a program argument.
-.Nm --
-must be used before
-.Ar format .
> I wonder if
> there are any utilities that don't use getopt(3) and as a result aren't
> POSIX conformant since they don't support "--" and also need to support
> a first argument starting with "-" (which won't cause problems because
dd(1) is the only thing coming to mind, but it doesn't need to handle
argments starting with "-".
I believe our find(1) has a problem:
$ cd /tmp
$ mkdir ./-
$ touch ./-/foo
$ find -- - -name foo
find -- - -name foo
usage: find [-H | -L | -P] [-EXdsx] [-f path] path ... [expression]
find [-H | -L | -P] [-EXdsx] -f path [path ...] [expression]
--
-- David (obr...@freebsd.org)
___
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: r212374 - head/usr.bin/printf
On Thu, Sep 09, 2010 at 09:53:02PM +0200, Jilles Tjoelker wrote:
> On Thu, Sep 09, 2010 at 07:27:40PM +, David E. O'Brien wrote:
> > +.Pp
> > +Trying to print a dash ("-") as the first character causes
> > +.Nm
> > +to interpet the dash as a program argument.
> > +.Nm --
> > +must be used before
> > +.Ar format .
>
> I do not consider this a bug.
[..]
> A caveat could be added,
OK, if not a bug, then can you suggest other language (and position in
the man page) to give a warning or hint against something I think goes
against POLA?
For something that does not claim to have any command line arguments, I
would not have expected getopt() to be used and thus need to escape out
of its processing.
> POSIX requires printf to recognize -- and
> pretty much all current implementations conform to this.
Please provide a reference. I am looking at 'The Open Group Base
Specifications Issue 6 IEEE Std 1003.1, 2004 Edition'
(susv3/utilities/printf.html), and I am not seeing such language.
susv3 has the synopsis as:
SYNOPSIS
printf format [argument...]
OPERANDS
The following operands shall be supported:
format
A string describing the format to use to write the remaining
operands. See the EXTENDED DESCRIPTION section.
argument
The strings to be written to standard output, under the control
of format. See the EXTENDED DESCRIPTION section.
Interestingly, we may not be compliant with susv3 if I am reading this
correctly:
The printf utility is required to notify the user when conversion
errors are detected while producing numeric output; thus, the
following results would be expected on an implementation with 32-bit
twos-complement integers when %d is specified as the format operand:
Argument Standard Output Diagnostic Output
5a5 printf: "5a" not completely converted
992147483647printf: "99" arithmetic overflow
-99 -2147483648 printf: "-99" arithmetic overflow
ABC 0 printf: "ABC" expected numeric value
$ uname -m
i386
$ for A in 5a 99 -99 ABC do /usr/bin/printf "%d\n" $A ; done
printf: 5a: not completely converted
5
99
-99
printf: ABC: expected numeric value
0
Though this is in the "informative" section, so maybe this is just one
set of compliant output. Though It is my read that printf(1) should
behave like printf(3), which the above does not for these long long int
values.
#include
int
main(void)
{
printf("%d\n", 99);
printf("%d\n", -99);
return 0;
}
--
-- David (obr...@freebsd.org)
___
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: r212374 - head/usr.bin/printf
On Thu, Sep 09, 2010 at 12:51:11PM -0700, Juli Mallett wrote: > On Thu, Sep 9, 2010 at 12:27, David E. O'Brien wrote: > > Author: obrien > > Date: Thu Sep ?9 19:27:40 2010 > > New Revision: 212374 > > URL: http://svn.freebsd.org/changeset/base/212374 > > > > Log: > > ?Note bug in trying to printf(1) things like: '-%s\n' "foo" > > Should we also add something like this note to every manual page for a > program that operates on files as command line arguments after options > w.r.t. operating on files whose names begin with '-'? No. Because most programs have a synopsis like: ls [-ABCFGHILPRSTUWZabcdfghiklmnopqrstuwx1] [-D format] [file ...] However, printf(1)'s is printf format [arguments ...] Which does not say it takes ANY command-line options. Thus why should one expect to have to trick out any command-line arguments "--" as one would with 'grep -- --i *.c'? Is a sentence or two a burden to the man page vs. saving someone the time I spent trying to figure out why printf(1) kept throwing up errors? -- -- David (obr...@freebsd.org) ___ 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: r205014 - in head: . sys/amd64/amd64 sys/amd64/conf sys/amd64/include sys/amd64/linux32 sys/compat/freebsd32 sys/compat/ia32 sys/conf sys/fs/procfs sys/ia64/conf sys/ia64/ia64 sys/ia64
On Fri, Mar 12, 2010 at 10:52:27PM +0900, Rui Paulo wrote: > On 12 Mar 2010, at 21:36, Carlos A. M. dos Santos wrote: >> On Thu, Mar 11, 2010 at 11:49 AM, Nathan Whitehorn >> wrote: >>> Author: nwhitehorn >>> Date: Thu Mar 11 14:49:06 2010 >>> New Revision: 205014 >>> URL: http://svn.freebsd.org/changeset/base/205014 >>> >>> Log: >>> Provide groundwork for 32-bit binary compatibility on non-x86 platforms, >>> for upcoming 64-bit PowerPC and MIPS support. This renames the >>> COMPAT_IA32 >>> option to COMPAT_FREEBSD32, removes some IA32-specific code from MI >>> parts >>> of the kernel and enhances the freebsd32 compatibility code to support >>> big-endian platforms. >> >> COMPAT_FREEBSD32 is an unfortunate choice. It can be easily >> interpreted as "compatible with FreeBSD 3.2". Something like >> "COMPAT_32BIT" would be more meaningful. > > There's a lengthy discussion about this on another mailing list. > > This is unlikely to be changed and emailing the committer who provided > valuable time on this code wastes his time and everyone else's. $ cd /usr/src/sys $ wcfind . -type f | xargs sed -i '' -e 's/COMPAT_FREEBSD32/COMPAT_32BIT/g' really doesn't take much developer time. I can whip up the patch for review. -- -- David (obr...@freebsd.org) ___ 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: r204902 - in head/sys: net netinet
On Wed, Mar 10, 2010 at 01:01:06PM -0500, John Baldwin wrote: > On Wednesday 10 March 2010 11:08:58 am David O'Brien wrote: > > On Wed, Mar 10, 2010 at 10:50:46AM -0500, John Baldwin wrote: > > > On Wednesday 10 March 2010 10:23:39 am David O'Brien wrote: > > > > This change doesn't seem to work in the common case, and has made the > > > > kernel toxic - with folks unable to connect to 127.0.0.1. Please back > > > > this out or adjust the change. > > > > > > Did you try the route.h patch he posted to curr...@? > > > > I looked at it, and at the diff of his original commit. The changes were > > large enough that I don't want to assume his patch takes care of all the > > issues given that patch hasn't been committed verbatim. > > > > We also have reports of the patch not working in freebsd-curr...@. > > The reports have all said that the patch fixes pinging 127.0.0.1. The one > problem report is a different situation involving a VPN tunnel. Just patch > your system with the route.h patch for now. I guess I don't get it - we have got reports of this badly affecting basic functionallity for several people and yet we wont fix stock sources? This is serving users well? Folks could have applied my patch sent to newvers.sh, but that was calmed to be so bad that the commit was backed out. Wow. -- -- David (obr...@freebsd.org) ___ 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: r204902 - in head/sys: net netinet
On Wed, Mar 10, 2010 at 09:46:49AM -0800, Qing Li wrote: > > > > I looked at it, and at the diff of his original commit. ?The changes were > > large enough that I don't want to assume his patch takes care of all the > > issues given that patch hasn't been committed verbatim. > > The change itself is not a huge change but if you disagree, then > please be specific. I'm not disagreeing. I'm saying you and others that have worked in the routing code are the best judge. > The current mechanism and code is broken according to the original > design intention. But able to ping 127.0.0.1. :-) > When you say > "... made the kernel toxic" and "...I don't want to assume ...", well, > again, be specific instead about what you mean and give me details. A stock kernel cannot ping 127.0.0.1. It is claimed there is no route to 127.0.0.1. David Wolfskill has the same problem, as have others in the freebsd-current@ mailing list. I don't know about others, but not being able to connect to 127.0.0.1 totally breaks my installation. -- -- David (obr...@freebsd.org) ___ 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: r204902 - in head/sys: net netinet
On Wed, Mar 10, 2010 at 10:50:46AM -0500, John Baldwin wrote: > On Wednesday 10 March 2010 10:23:39 am David O'Brien wrote: > > Hi Qing, > > > > This change doesn't seem to work in the common case, and has made the > > kernel toxic - with folks unable to connect to 127.0.0.1. Please back > > this out or adjust the change. > > Did you try the route.h patch he posted to curr...@? I looked at it, and at the diff of his original commit. The changes were large enough that I don't want to assume his patch takes care of all the issues given that patch hasn't been committed verbatim. We also have reports of the patch not working in freebsd-curr...@. -- -- David (obr...@freebsd.org) ___ 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: r204902 - in head/sys: net netinet
Hi Qing, This change doesn't seem to work in the common case, and has made the kernel toxic - with folks unable to connect to 127.0.0.1. Please back this out or adjust the change. thanks, -- -- David (obr...@freebsd.org) ___ 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: r204824 - head/sys/conf
On Tue, Mar 09, 2010 at 08:18:25PM -0700, M. Warner Losh wrote: > In message: <20100310024553.ga13...@dragon.nuxi.org> > "David O'Brien" writes: .. > PLEASE DO NOT CHANGE newvers.sh FROM WHAT IT IS NOW. Please talk > about your proposed changes in -hackers@ or -current@ first. When I wrote that Doug's change had not made it thru my svnsync. It wasn't Doug's place to back out my change. Geez, you're acting like this is making the kernel toxic (like the now route to 127.0.0.1). PLEASE CLALM DOWN WARNER. -- -- David (obr...@freebsd.org) ___ 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: r204824 - head/sys/conf
On Tue, Mar 09, 2010 at 07:35:12PM -0700, M. Warner Losh wrote:
>
> I'd recommend something similar to the following change:
> Index: newvers.sh
..
> +S=sys
..
> -*/sys/*)
> +*/$S/*)
> SRCDIR=${d##*obj}
> if [ -n "$MACHINE" ]; then
> SRCDIR=${SRCDIR##/$MACHINE}
> fi
> - SRCDIR=${SRCDIR%%/sys/*}
> + SRCDIR=${SRCDIR%%/$S/*}
Why not make it simpler as my patch did? Do you not trust that
newvers.sh (e.g. "$0") is within the kernel directory?
> which would allow people that move sys to somewhere else to change one
> line and still have everything work. They are going to have to make
> changes anyway to support that, since it isn't supported by FreeBSD
> out of the box.
Eh? 'svn co svn://svn.freebsd.org/base/head/sys syshead' works as-is.
Using "$0" requires no one to have to change a single line.
--
-- David (obr...@freebsd.org)
___
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: r204824 - head/sys/conf
On Mon, Mar 08, 2010 at 09:06:59AM -0700, M. Warner Losh wrote:
> In message: <20100308010125.ga6...@dragon.nuxi.org>
> "David O'Brien" writes:
> : On Sun, Mar 07, 2010 at 02:36:19PM -0700, M. Warner Losh wrote:
> : > Please back out this change. It is unwise, I think.
> :
> : Instead I'd rather fix it for the use case you mention.
>
> I'd still rather you back it out because it introduces a significant
> regression in speed, see below...
Can you please apply this diff:
Index: conf/kern.post.mk
===
--- conf/kern.post.mk (revision 204912)
+++ conf/kern.post.mk (working copy)
@@ -247 +247 @@ vers.c: $S/conf/newvers.sh $S/sys/param.
- MAKE=${MAKE} sh $S/conf/newvers.sh ${KERN_IDENT}
+ MAKE=${MAKE} sh -x $S/conf/newvers.sh ${KERN_IDENT}
and send me the output of:
rm /usr/obj/MM/test/sys/GENERIC/vers*
make -DNOCLEAN buildkernel
I would like to understand and fix how my patch causes you longer build
times than r197433.
Attached are my typescripts for r197433 and the patch I sent you. The
diff of which is:
--- typescript,r197433 2010-03-09 20:11:35.0 -0800
+++ typescript,new 2010-03-09 20:11:50.0 -0800
@@ -104,17 +104,16 @@ MAKE=make sh -x /MM/test/sys/conf/newver
+ cat version
+ pwd
+ date
-+ v=1 u=rootk d=/usr/obj/MM/test/sys/GENERIC h=dragon t='Tue Mar 9 20:06:11
PST 2010'
++ v=6 u=rootk d=/usr/obj/MM/test/sys/GENERIC h=dragon t='Tue Mar 9 20:20:33
PST 2010'
+ make -V KERN_IDENT
+ i=GENERIC
-+ SRCDIR=/MM/test/sys/GENERIC
-+ [ -n i386 ]
-+ SRCDIR=/MM/test/sys/GENERIC
-+ SRCDIR=/MM/test
++ dirname /MM/test/sys/conf/newvers.sh
++ realpath /MM/test/sys/conf/..
++ SRCDIR=/MM/test/sys
+ [ -d /MM/test/sys/.svn -a -x /bin/svnversion ]
-+ [ -d /MM/test/.git -a -x /bin/git ]
++ [ -d /MM/test/sys/.git -a -x /bin/git ]
+ [ -d /MM/test/sys/.svn -a -x /usr/bin/svnversion ]
-+ [ -d /MM/test/.git -a -x /usr/bin/git ]
++ [ -d /MM/test/sys/.git -a -x /usr/bin/git ]
+ [ -d /MM/test/sys/.svn -a -x /usr/local/bin/svnversion ]
+ svnversion=/usr/local/bin/svnversion
+ break
As you can see, the same .svn/ directory is used in my patch as in
r197433.
I think looking for .git/ in the same directory as .svn/ make sense, but
I'm not a heavy git user. Assuming you disagree, the attached patch will
look above the kernel directory. If it bothers you to run realpath(1)
twice, I can save its output in a shell var and use that.
> : Index: newvers.sh
..
> : - SRCDIR=${d##*obj}
..
> : + SRCDIR=$(realpath $(dirname $0)/..)
Is your newver.sh script in the normal place within 'conf/'?
> : Do you get the subversion revision in your vers.c file with this patch?
>
> Well, except that you get the revision for the whole tree, instead of
> just for the kernel. And this takes a *LOT* longer to compute. The
> whole reason we did the sys hack was to make build times not suck...
Please send me the typescript output from with conf/kern.post.mk
patch. I need to see how "SRCDIR" is getting set to "/usr/src" for you
and not "/usr/src/sys".
--
-- David (obr...@freebsd.org)
MAKE=make sh -x /MM/test/sys/conf/newvers.sh GENERIC
+ TYPE=FreeBSD
+ REVISION=9.0
+ BRANCH=CURRENT
+ [ X != X ]
+ RELEASE=9.0-CURRENT
+ VERSION='FreeBSD 9.0-CURRENT'
+ [ X != X ]
+ dirname /MM/test/sys/conf/newvers.sh
+ awk '/__FreeBSD_version.*propagated to newvers/ {print $3}'
/MM/test/sys/conf/../sys/param.h
+ RELDATE=99
+ b=share/examples/etc/bsd-style-copyright
+ date +%Y
+ year=2010
+ [ -r ../share/examples/etc/bsd-style-copyright ]
+ [ -r ../../share/examples/etc/bsd-style-copyright ]
+ [ -r ../../../share/examples/etc/bsd-style-copyright ]
+ [ -r /usr/src/share/examples/etc/bsd-style-copyright ]
+ sed -e 's/\[year\]/1992-2010/' -e 's/\[your name here\]\.* /The FreeBSD
Project./' -e 's/\[your name\]\.*/The FreeBSD Project./' -e '/\[id for your
version control system, if any\]/d'
/usr/src/share/examples/etc/bsd-style-copyright
+ COPYRIGHT='/*-
* Copyright (c) 1992-2010 The FreeBSD Project.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'\'\'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMP
Re: svn commit: r204824 - head/sys/conf
On Sun, Mar 07, 2010 at 06:10:52PM -0800, Doug Barton wrote: > On 03/07/10 17:01, David O'Brien wrote: > > > +*/sys/*|*/compile/*) > > Please revert your previous change, and feel free to add this one instead. This alone will not work - it doesn't fix the calculation of SRCDIR: + v=0 u=root d=/MM/test/my-fbsd-kern/i386/compile/GENERIC h=dragon t='Tue Mar 9 18:42:18 PST 2010' + make -V KERN_IDENT + i=GENERIC + SRCDIR=/MM/test/my-fbsd-kern/i386/compile/GENERIC + [ -n '' ] + SRCDIR=/MM/test/my-fbsd-kern/i386/compile/GENERIC + [ -d /MM/test/my-fbsd-kern/i386/compile/GENERIC/sys/.svn -a -x /bin/svnversion ] + [ -d /MM/test/my-fbsd-kern/i386/compile/GENERIC/.git -a -x /bin/git ] I will fix newvers.sh tonight. -- -- David (obr...@freebsd.org) ___ 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: r204824 - head/sys/conf
On Sun, Mar 07, 2010 at 06:10:52PM -0800, Doug Barton wrote: > On 03/07/10 17:01, David O'Brien wrote: > > +*/sys/*|*/compile/*) > > Please revert your previous change, and feel free to add this one instead. > > I'm a little aggravated because this question of "what if the directory > isn't named */sys/*?" was already addressed when I made the change, and > the general agreement was that !sys was an edge case that wasn't worth > worrying about. I probably would have if I had been able to update my main system to a kernel newer than Nov 9th. Every time I've tried HEAD is toxic[*]. Tried again this morning - "no route to 127.0.0.1". > I'm even more aggravated that your change doesn't work for the common case. Sorry, I build all my kernels the traditional way. I was agrivated that your change didn't work with the kernel build method with 15 years history... -- -- David (obr...@freebsd.org) [*] March 6th kernel panics, March 5th kernel dead locks trivially on disk acces. Kernel build broken in January for 3 days due to em, Feb 1st panics, jan 26 panics. ___ 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: r204824 - head/sys/conf
On Sun, Mar 07, 2010 at 02:36:19PM -0700, M. Warner Losh wrote:
> Please back out this change. It is unwise, I think.
Instead I'd rather fix it for the use case you mention.
>%>%>%>%>%>%>%>%>%>%>%>%
Index: newvers.sh
===
--- newvers.sh (revision 204851)
+++ newvers.sh (working copy)
@@ -87,13 +87,11 @@ touch version
v=`cat version` u=${USER:-root} d=`pwd` h=${HOSTNAME:-`hostname`} t=`date`
i=`${MAKE:-make} -V KERN_IDENT`
+# Are we doing a kernel build? Look for "/sys/" in pwd for 'make kernel',
+# and "/compile/" for tradiational within-tree kernel build.
case "$d" in
-*/compile/*)
- SRCDIR=${d##*obj}
- if [ -n "$MACHINE" ]; then
- SRCDIR=${SRCDIR##/$MACHINE}
- fi
- SRCDIR=$(cd ${SRCDIR%%/compile/*}/.. && pwd)
+*/sys/*|*/compile/*)
+ SRCDIR=$(realpath $(dirname $0)/..)
for dir in /bin /usr/bin /usr/local/bin; do
if [ -d "${SRCDIR}/.svn" -a -x "${dir}/svnversion" ] ; then
>%>%>%>%>%>%>%>%>%>%>%>%
Do you get the subversion revision in your vers.c file with this patch?
--
-- David
___
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"
