Re: svn commit: r212959 - head/sbin/mount_unionfs
On Tue, Sep 21, 2010 at 12:01:03PM -0700, Doug Barton wrote: > You forgot to bump .Dd I thought it is required when manpages undergoes substantial or at least functional changes. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r213508 - head/sys/fs/msdosfs
On Thu, Oct 07, 2010 at 08:36:02AM +, Konstantin Belousov wrote: > The msdosfs lookup is case insensitive. Several aliases may be inserted for > a single directory entry. As a consequnce, name cache purge done by lookup > for fvp when DELETE op for namei is specified, might be not enough to > expunge all namecache entries that were installed for this direntry. > > Explicitely call cache_purge(fvp) when msdosfs_rename() succeeded. Maybe this text could be used as a comment in the code? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r213543 - head/sys/fs/msdosfs
On Fri, Oct 08, 2010 at 07:17:22AM +, Konstantin Belousov wrote: > Author: kib > Date: Fri Oct 8 07:17:22 2010 > New Revision: 213543 > URL: http://svn.freebsd.org/changeset/base/213543 > > Log: > Add a comment describing the reason for calling cache_purge(fvp). > > Requested by: danfe Thanks, but that was just a kind suggestion. :-) ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r214431 - head/bin/rm
On Wed, Oct 27, 2010 at 03:33:01PM -0700, Xin LI wrote: > Maybe something like: > > BUGS > > The -P option assumes that the underlying storage overwrites file block > when data is written on existing offset. Several factors including the > file system and its backing store could defeat the assumption, this > includes, but is not limited to file systems that uses Copy-On-Write > strategy (e.g. ZFS or UFS when snapshot is being used), or backing > datastore that does journaling, etc. In addition, only regular files > are overwritten, other types of files are not. This sounds very nice and FreeBSD-ish. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: 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
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. :-^ ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r229430 - in head/sys: conf dev/sound/pci modules/sound/driver/emu10k1
On Wed, Jan 04, 2012 at 09:54:53AM +0100, Joel Dahl wrote: > The emu10k1 and emu10kx drivers essentially support the same hardware, with > a few exceptions (if memory serves me right -- I think there are a few cards > that emu10kx does not support, someone should check with Yuriy). However, > emu10kx has a few nice features like optional multichannel and MIDI I/O > support... How hard would it be to (re)implement missing features with emu10k1 and nuke GPL-polluted emu10kx? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r229430 - in head/sys: conf dev/sound/pci modules/sound/driver/emu10k1
On Wed, Jan 04, 2012 at 05:58:10AM -0800, Pedro Giffuni wrote: > --- Mer 4/1/12, Alexey Dokuchaev ha scritto: > > How hard would it be to (re)implement missing features with > > emu10k1 and nuke GPL-polluted emu10kx? > > The emu10kx started from the emu10k1 and is mostly BSD licensed, > I did start cleaning it in kern/153901 but I didn't commit the > the emu10kx part. > > 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. :-) ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r229430 - in head/sys: conf dev/sound/pci modules/sound/driver/emu10k1
On Wed, Jan 04, 2012 at 06:52:17AM -0800, Garrett Cooper wrote: > On Wed, Jan 4, 2012 at 6:43 AM, Alexander Motin wrote: > > 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. OK, how about this: I have an E-MU 1212m. Any takers? :-) ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r215214 - stable/8/sys/dev/sk
On Sat, Nov 13, 2010 at 12:46:07AM +, Pyun YongHyeon wrote: > Author: yongari > Date: Sat Nov 13 00:46:07 2010 > New Revision: 215214 > URL: http://svn.freebsd.org/changeset/base/215214 > > Log: > MFC r214898: > If we got an invalid station address, generate random address. This > might be caused by broken BIOS. > > Reported by: "Mikhail T." aldan.algebra.com> Perhaps the reporter can be more easily referenced as m...@? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r215274 - head/share/mk
On Sun, Nov 14, 2010 at 01:37:09AM +, Warner Losh wrote: > Author: imp > Date: Sun Nov 14 01:37:08 2010 > New Revision: 215274 > URL: http://svn.freebsd.org/changeset/base/215274 > > Log: > This case is actually powerpc specific, and doesn't apply to powerpc64. > > Submitted by: nathanw@ finger nath...@freebsd.org [...] finger: nathanw: no such user ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r215274 - head/share/mk
On Sun, Nov 14, 2010 at 07:38:51PM -0800, Garrett Cooper wrote: > 2010/11/14 Alexey Dokuchaev : > > On Sun, Nov 14, 2010 at 01:37:09AM +, Warner Losh wrote: > >> Log: > >> This case is actually powerpc specific, and doesn't apply to powerpc64. > >> > >> Submitted by: nathanw@ > > > > finger nath...@freebsd.org > > [...] > > finger: nathanw: no such user > > Was supposed to be nwhitehorn@ You know that, I know, and others likely know it as well. My point, however, is that this might not be true to someone reading the logs 10 years from now. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r215520 - in head: bin/sh share/man/man1 usr.bin/printf
On Fri, Nov 19, 2010 at 12:56:13PM +, Jilles Tjoelker wrote: > I do not want to encourage people to write fragile and non-portable echo > commands by making printf much slower than echo. True. > Side effect: printf is now always the builtin version (which behaves > identically to /usr/bin/printf) and cannot be overridden via PATH (except > via the undocumented %builtin mechanism). Are there any plans to document it? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216263 - head/sys/dev/acpica
On Tue, Dec 07, 2010 at 06:49:11PM +, John Baldwin wrote: > Author: jhb > Date: Tue Dec 7 18:49:11 2010 > New Revision: 216263 > URL: http://svn.freebsd.org/changeset/base/216263 > > Log: > Use proper resource ID's for HPET IRQ resources. This mostly consists of > looking to see if there is an existing IRQ resource for a given IRQ > provided by the BIOS and using that RID if so. Otherwise, allocate a new > RID for the new IRQ. Could it be related to "device_attach: acpi_hpet0 attach returned 12" messages quite a few of us are seeing by chance? If yes, will it be MFCed to 7/8? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r196440 - head/lib/libpmc
On Sun, Aug 23, 2009 at 06:19:02AM +, Joseph Koshy wrote: > Author: jkoshy > Date: Sun Aug 23 06:19:02 2009 > New Revision: 196440 > URL: http://svn.freebsd.org/changeset/base/196440 > > Log: > Correct grammar. > > -CPUs are named using small integers from zero uptil, but > +CPUs are named using small integers from zero until, but I guess "up to" is also more appropriate here instead of "until". ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r196524 - in head/sys: dev/syscons i386/isa
On Mon, Aug 24, 2009 at 10:35:53PM +, Xin LI wrote: > Author: delphij > Date: Mon Aug 24 22:35:53 2009 > New Revision: 196524 > URL: http://svn.freebsd.org/changeset/base/196524 > > Log: > Fix VESA modes and allow 8bit depth modes. > > PR: i386/124902 > Submitted by: paradox > MFC after: 2 months > > Modified: > head/sys/dev/syscons/scvgarndr.c > head/sys/dev/syscons/scvidctl.c > head/sys/i386/isa/vesa.c This commit broke logo screensaver with vesa on my NEC Versa S950 laptop. Reverting and rebuilding/reloading vesa module restored correct behavior. I'm not familiar with our VESA implementation internals to give you sufficient analysis right now, but will take a look. Who did review these changes, BTW? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r196727 - head/share/man/man5
On Tue, Sep 01, 2009 at 09:23:44AM -0700, Doug Barton wrote: > Maxim Konovalov wrote: > > Author: maxim > > Date: Tue Sep 1 05:55:10 2009 > > New Revision: 196727 > > URL: http://svn.freebsd.org/changeset/base/196727 > > > > Log: > > o Document MALLOC_PRODUCTION knob. > > > > PR: docs/136029 > > Submitted by: anonymous > > MFC after:2 weeks > > > > Modified: > > head/share/man/man5/make.conf.5 > > Unless I'm missing something this should be in the src.conf man page > instead of make.conf. However, I'm used to make.conf since 4.x days, so at least cross-reference of some sort is in order (I'm not sure, there might be one already now that I write this). ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197313 - head/release
On Fri, Sep 18, 2009 at 02:53:01PM +, Ken Smith wrote: > Author: kensmith > Date: Fri Sep 18 14:53:01 2009 > New Revision: 197313 > URL: http://svn.freebsd.org/changeset/base/197313 > > Log: > Have sparc64 join the separate livefs crowd. Including the docs packages > on disc1 (needed now by sysinstall) overflows the target CDROM iso size. I've always been wondering how could docs be more important than livefs? I'd rather have -docs iso (which I won't ever download anyways) than -livefs one (which is needed far more often, e.g. to fix botched or corrupted installation) in addition to disc1. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197480 - head/sys/teken
On Fri, Sep 25, 2009 at 11:58:51AM +, Ed Schouten wrote:
> Author: ed
> Date: Fri Sep 25 11:58:51 2009
> New Revision: 197480
> URL: http://svn.freebsd.org/changeset/base/197480
>
> Log:
> Conformance: ignore {delete,insert} line while outside the scrolling region.
>
> I noticed a small inconsistency in delete and insert line between xterm
> and libteken. libteken allows these actions to happen while the cursor
> is placed outside the scrolling region, while xterm does not.
>
> This behaviour seems to be VT100-like. Confirmation:
>
> http://www.vt100.net/docs/vt102-ug/chapter5.html
> "This sequence is ignored when cursor is outside scrolling region."
You could have probably mention canonical document name and
chapter/paragraph number in comments as well (refering to standards
seems quite appropriate and just looks good in code).
./danfe
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197498 - head/cddl/contrib/opensolaris/cmd/zfs
On Sat, Sep 26, 2009 at 10:51:58PM +0200, Dag-Erling Sm??rgrav wrote: > Pawel Jakub Dawidek writes: > > I didn't, thanks. Unfortunately svn doesn't even allow forced commits, > > which is a paintful regression compared to cvs. > > Subversion does allow editing a log message after the fact, but our > commit scripts prohibit it. This should IMHO be allowed, and cause a > new email to be sent out to note the change. I recall that one of the reasons behind prohibition was to avoid issues with CVS exporter. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197623 - stable/8
On Tue, Sep 29, 2009 at 07:57:06PM +, Ken Smith wrote: > +NOTE TO PEOPLE WHO THINK THAT FreeBSD 8.x IS SLOW ON IA64 OR SUN4V: > + For ia64 the INVARIANTS and INVARIANTS_SUPPORT kernel options ^ Shouldn't it be INVARIANT_SUPPORT instead (note the superfluous `S')? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r197646 - head/etc/rc.d
On Wed, Sep 30, 2009 at 02:58:10PM +, Hajimu UMEMOTO wrote: > Author: ume > Date: Wed Sep 30 14:58:10 2009 > New Revision: 197646 > URL: http://svn.freebsd.org/changeset/base/197646 > > Log: > Don't do an IPv6 operation when the kernel doesn't have > an IPv6 support. Thanks! ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r198486 - head/sys/dev/ata
On Mon, Oct 26, 2009 at 11:20:15AM +, Alexander Motin wrote: > Author: mav > Date: Mon Oct 26 11:20:14 2009 > New Revision: 198486 > URL: http://svn.freebsd.org/changeset/base/198486 > > Log: > Increase ATA command timeouts. Some drives need more then 5s to spin-up. Can't it be factored out into a macro so one does not have to make a bunch of those identical changes over several files shall it be required to adjust timeout again some time in the future? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r226947 - in head/sys: dev/esp sparc64/sbus
On Sun, Oct 30, 2011 at 09:17:42PM +, Marius Strobl wrote: > Author: marius > Date: Sun Oct 30 21:17:42 2011 > New Revision: 226947 > URL: http://svn.freebsd.org/changeset/base/226947 > > Log: > - Use device_t rather than the NetBSDish struct device. Hmm, I though that style(9) advises against this practice: Avoid using typedefs for structure types. Typedefs are problematic because they do not properly hide their underlying type; [...] When convention requires a typedef, make its name match the struct tag. Avoid typedefs ending in _t, except as specified in Standard C or by POSIX. Does these rules not apply for struct device for some reason? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r226947 - in head/sys: dev/esp sparc64/sbus
On Tue, Nov 01, 2011 at 12:01:16AM +1100, Bruce Evans wrote: > On Mon, 31 Oct 2011, Alexey Dokuchaev wrote: > > When convention requires a typedef, make its name match the struct tag. > > Avoid typedefs ending in _t, except as specified in Standard C or by > > POSIX. > > > > Do these rules not apply for struct device for some reason? > > Yes (they don't apply here). device_t is one of a few properly opaque > typedefs for struct pointers. 'struct device' is only (completely) > declared in kern/subr_bus.c. Thus the implementation details of it > obviously cannot escape to drivers. Most of the APIs in > are supposed to be like this. But `typedef struct kobj_class driver_t' > and `#define driver_method_t kobj_method_t' are gross exceptions. > has to include for dereferencing these, and > kobj.h breaks the rule by providing both typedefs for struct pointers > and complete struct declarations. Thanks for detailed explanation Bruce. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r227081 - in head/sbin: atm/atmconfig badsect camcontrol ccdconfig devfs dmesg dumpfs fdisk ffsinfo fsck fsck_msdosfs fsirand growfs init mount mount_cd9660 mount_nullfs mount_udf natd
On Fri, Nov 04, 2011 at 01:36:02PM +, Ed Schouten wrote: > Author: ed > Date: Fri Nov 4 13:36:02 2011 > New Revision: 227081 > URL: http://svn.freebsd.org/changeset/base/227081 > > Log: > Add missing static keywords for global variables to tools in sbin/. > > These tools declare global variables without using the static keyword, > even though their use is limited to a single C-file, or without placing > an extern declaration of them in the proper header file. Thanks for doing this Ed, much appreciated! ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r227366 - in head/etc: . rc.d
On Tue, Nov 08, 2011 at 11:02:32PM +, Jilles Tjoelker wrote:
> Author: jilles
> Date: Tue Nov 8 23:02:32 2011
> New Revision: 227366
> URL: http://svn.freebsd.org/changeset/base/227366
>
> Log:
> rc.d: Eliminate some unnecessary non-POSIX constructs:
>
>* ^ in character class
>
> - for file in ${dir}/[^0-9]*.sh; do
> + for file in ${dir}/[!0-9]*.sh; do
I don't have my copy of POSIX handy, but looking at SUSv2, circumflex `^' is
documented as non-matching list expression specifier, while `!' is not.
I am reading it wrong?
./danfe
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r227366 - in head/etc: . rc.d
On Wed, Nov 09, 2011 at 10:31:27PM +0100, Jilles Tjoelker wrote: > Shell patterns are different from regular expressions. I suspected something like this, yes... > In SUSv4, XCU 2.13 Pattern Matching Notation describes shell patterns. > In particular, the role of the '^' to negate a bracket expression is > instead fulfilled by '!'; a '^' directly after the '[' produces > unspecified results (so that the common RE-like behaviour is allowed). > Historically, this is because the Bourne shell interprets '^' as a > synonym for '|' (pipe) and therefore it cannot occur in a pattern > unquoted. Thanks for the explanation. Always wanted to try using ^ as pipe, but all modern shells seem to not support it anymore. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r227536 - in head: release share/man/man7
On Thu, Nov 17, 2011 at 08:03:40AM -0500, Ken Smith wrote: > On Thu, 2011-11-17 at 13:42 +0100, Pawel Jakub Dawidek wrote: > > On Wed, Nov 16, 2011 at 10:24:10AM -0500, Ken Smith wrote: > > > Or both? We're heading in the direction of having both for the FTP > > > server tree. > > > > > > Kinda gross but "FBSD-9.0-RELEASE-amd64-amd64-bootonly.iso"? > > > > Can't we use one if they are equal? > > I'd prefer consistency. [...] But it looks so plain stupid! > I picture a higher percentage of people being confused about why some > architectures have one name while other architectures have two versus > people being confused about all of them having two names. And people would have to believe that we as a Project are so dumb that we could not figure out how to avoid this trivial redundancy when it is clearly not anywhere being useful. :-( ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r227536 - in head: release share/man/man7
On Thu, Nov 17, 2011 at 09:44:52AM -0500, Ken Smith wrote: > This is the problem we are trying to "solve": > > Supported TARGET/TARGET_ARCH pairs for world and kernel targets > amd64/amd64 > arm/arm > arm/armeb > i386/i386 > ia64/ia64 > mips/mipsel > mips/mipseb > mips/mips64el > mips/mips64eb > mips/mipsn32eb > pc98/i386 > powerpc/powerpc > powerpc/powerpc64 > sparc64/sparc64 As I see it, for every pair except pc98/i386, second part should be used. For pc98/i386, first (pc98). Problem solved. ;-) ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r227536 - in head: release share/man/man7
On Thu, Nov 17, 2011 at 02:16:47PM -0500, John Baldwin wrote: > On Thursday, November 17, 2011 12:43:12 pm Ken Smith wrote: > > If you're referring to the FTP directory tree layout we wind up with: > > > > .../releases/amd64/9.0-RELEASE > > .../releases/amd64/ISO-IMAGES/9.0 > > > > for an example of uname -m == uname -p. But for our two powerpc related > > architectures we get: > > > > .../releases/powerpc/9.0-RELEASE > > .../releases/powerpc/ISO-IMAGES/9.0 > > .../releases/powerpc/powerpc64/9.0-RELEASE > > .../releases/powerpc/powerpc64/ISO-IMAGES/9.0 > > > > I'm not sure I like the inconsistency. > > Given the available tradeoffs I prefer this to amd64/amd64. We could also > define the rule another way, which is if a given TARGET only has a single > TARGET_ARCH you just use TARGET, otherwise you use TARGET/TARGET_ARCH. If we seem to employ some naming transition rule based on TARGET_ARCH and TARGET, why not simply check just for pc98 as I suggested earlier, and return TARGET in this case, and TARGET_ARCH otherwise? Generalizing, perhaps this rule can be extended to the list of TARGET/TARGET_ARCH combos for which we return TARGET, and TARGET_ARCH for the rest? (This is for ISO file names; for release directory structure John's suggestion looks reasonable.) ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r227650 - in head: lib/libkiconv sys/conf sys/fs/msdosfs sys/fs/smbfs sys/kern sys/libkern sys/modules/libiconv sys/modules/libmchain sys/netsmb sys/sys
On Fri, Nov 18, 2011 at 03:05:21AM +, Kevin Lo wrote: > Author: kevlo > Date: Fri Nov 18 03:05:20 2011 > New Revision: 227650 > URL: http://svn.freebsd.org/changeset/base/227650 > > Log: > Add unicode support to msdosfs and smbfs; original pathes from imura, > bug fixes by Kuan-Chung Chiu . Wow, long anticipated! Any MFCs planned? I've also posted a message[1] on unicode support for msdosfs/ntfs on -fs@ back in October, perhaps you could take a look on these patches and, ultimately, fix NTFS too? :-) Thanks! ./danfe [1] http://docs.freebsd.org/cgi/mid.cgi?20111013181602.GA35354 ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r222980 - in head/sys: amd64/conf i386/conf
On Sat, Jun 11, 2011 at 03:45:15PM +0200, Luigi Rizzo wrote: > In my experience, whenever i buy new motherboards it is often the > case that network cards, audio cards and several usb things > are not recognised just because a change in the device id. > Having the driver embedded in the kernel is very annoying in these cases. Not to mention that it's sometimes required to unload/reload some module so it can reinitialize its hardware when something breaks. I've always been recompiling minimal kernel with everything possible (down to io and mem devices) factored out into modules. Works perfectly. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r222980 - in head/sys: amd64/conf i386/conf
On Sat, Jun 11, 2011 at 01:55:15PM -0700, Doug Barton wrote: > I have 3 or 4 modules loaded via loader.conf at boot time. They take at > least 2 seconds each. IMO loading everything via loader.conf would slow > the boot so much as to be a non-starter. With my normal slim kernel with most of the modules loaded via loader.conf (other few loaded later in runtime) I have this: $ kldstat | wc -l 60 I do not observe noticeable difference compared to GENERIC kernel. Plus, users try to reboot their machines as rarely as possible, no? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r222980 - in head/sys: amd64/conf i386/conf
On Sat, Jun 11, 2011 at 08:51:32PM +0200, Pawel Jakub Dawidek wrote: > On Sat, Jun 11, 2011 at 10:44:14AM -0600, Warner Losh wrote: > > I think our best bet for 9 is to strip GENERIC to the bone and have a > > 'generic.conf' if you will that loads everything we compile in today. > > I think trasz@ tried that and there is a problem. Loading modules on > boot is very slow. If you try to load everything that GENERIC has as > modules the boot will take forever. Perhaps then we need to come up with something more intelligent, i.e. do not load everything trying to get maximum coverage of users' hardware, but load only required bits based on what we see on PCI bus (roughly speaking). > On all my servers and my laptop I use such minimalistic kernels and load > everything from modules. Yes, this is very convenient and IMHO the way to go. :-) ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r223129 - head/release
On Sat, Jun 18, 2011 at 09:17:57AM +1000, Peter Jeremy wrote: > On 2011-Jun-15 23:38:15 +, Nathan Whitehorn > wrote: > >Log: > > Do not install the rescue tools onto the install CD. Since it is read > > only, they are very unlikely to be needed and take up a great deal of > > space. > > If I've correctly understood this change, I'm not sure this is a > positive move. > > Based on a quick test, removing /rescue saves about 4MB (in reality, > the saving should be less because /rescue removes the need for > /stand). OTOH, it renders the install CD useless as a recovery > "fixit" disk - whilst the CD is unlikely to need recovery itself, it > was useful for recovering hard disks I think we would be far better off with an image which would provide a release (without packages) + full fixit functionality. Existing set of images is quite suboptimal: install image cannot be used as fixit disc, fixit disc cannot be used for installation. People who want packages will probably just burn DVD image; CD users more likely to go with ports. Having single installation image with everything but packages included is a clear winner for CD format. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r223519 - head/etc/devd
On Sun, Jun 26, 2011 at 10:14:13PM -0600, Warner Losh wrote: > Not in GENERIC. 9.0 is getting ready to feature freeze any minute, so > there's no time to do the testing that a radical change like that would > require. Fair enough. Right now, this work seems to cover only USB kernel modules, is it so? Is expansion into generic PCI area also planned, provided that you've already had some ideas and seem to be willing to pick up the work given enough support from the other developers (please excuse me if my understanding is wrong)? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r219424 - head/sbin/geom/class/eli
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. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r220250 - in stable/8: bin/test tools/regression/bin/test
On Fri, Apr 01, 2011 at 06:23:44PM +, Xin LI wrote: > 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. I thought general consensus that this change should never be part of FreeBSD, not just being undocumented (which, as we all know, is bad practice pe se). ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: 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 06:28:48PM +0300, Alexander Motin wrote: > What's about creating some kind of symlinks, it could be nice if it > worked, but I don't see the way to do it on disk(9) or GEOM layers > without breaking device's access counters and as result further random > problems. Speaking on Alexander's side, I'd want to mention that many of our users had been bitten by obscure adX naming during past years (largely due to ATA_STATIC_ID option which was probably useful back in times when there typically was only one IDE controller present in system, but leads to all sorts of weird ad4-6-8's in recent years) had already migrated to glabel or GPT labels, to avoid precisely the issues we're talking about here. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r221497 - head/release/ia64
On Thu, May 05, 2011 at 10:29:47PM -0500, Nathan Whitehorn wrote: > I'm cleaning up the release-building code, and am switching them from > mkisofs to makefs, which provides the same functionality. This started > with some irritation with the cdrtools port and a bug in the HFS hybrid > generation that was breaking PPC release CD generation. On a seemingly unrelated note, I've been under impression that for a long time, FreeBSD had some problems with generating "hybrid" installation images, while both some Linux distrosi (?) and Haiku had long history of providing *something* that can be equally burnt on CD and memstick. Are there plans for FreeBSD to do the same? Frankly speaking, right now assortment on ISOs offered by us seems quite suboptimal (e.g., there is not baseinstall+livefs image, which seems the most desirable). ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r221952 - head/sbin/geom/class/part
On Sun, May 15, 2011 at 11:09:10AM -0400, Marcel Moolenaar wrote: > On May 15, 2011, at 7:45 AM, Andrey V. Elsukov wrote: > > Author: ae > > Date: Sun May 15 11:45:13 2011 > > New Revision: 221952 > > URL: http://svn.freebsd.org/changeset/base/221952 > > > > Log: > > Simplify the code a bit. For own providers GEOM_PART always provides > > "start" and "end" config attributes. > > > > MFC after: 1 week > > Just to make sure: the code deals with backward compatibility. > If you're aware of the issue, but don't care (anymore) about it, > then the change is fine (as I can't quite remember the case in > point, and I don't care enough to speculatively page in the > details). > > If you weren't aware, we should probably determine the impact > before you MFC this. Let me know and I'll dig up the details. I would also suggest increasing "MFC after" period in this particular case for couple of months maybe. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r222417 - in head/sys/boot: common forth i386/loader ia64/common pc98/loader powerpc/ofw powerpc/ps3 sparc64/loader
On Sat, May 28, 2011 at 08:50:39AM +, Julian Elischer wrote: > Author: julian > Date: Sat May 28 08:50:38 2011 > New Revision: 222417 > URL: http://svn.freebsd.org/changeset/base/222417 > > Log: > New boot loader menus from Devin Teske. > Discussed on hackers and recommended for inclusion into 9.0 at the > devsummit. What about that sexy loader by olli@ [1]? I thought it was also destined for 9.x? Or these two works do not interfere? I've been using it for quite a while, seems pretty stable to me. ./danfe [1] http://wiki.freebsd.org/OliverFromme/BootLoader ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r190808 - stable/7/etc/rc.d
On Tue, Apr 07, 2009 at 04:29:50PM +, Maksim Yevmenkin wrote:
> Author: emax
> Date: Tue Apr 7 16:29:50 2009
> New Revision: 190808
> URL: http://svn.freebsd.org/changeset/base/190808
>
> ipfw_start()
> {
> + local _firewall_type
> +
> + _firewall_type=$1
Why extra tab and not simply "local _firewall_type=$1"?
> -run_rc_command "$1"
> +run_rc_command $*
I haven't looked at the implementation of run_rc_command but "$1"
suggests it should be "$@" instead.
./danfe
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r191330 - head/usr.bin/ncal
On Mon, Apr 20, 2009 at 06:19:38PM +, Roman Divacky wrote: > Author: rdivacky > Date: Mon Apr 20 18:19:38 2009 > New Revision: 191330 > URL: http://svn.freebsd.org/changeset/base/191330 > > Log: > Implement highlighting of today in month view of cal/ncal just like > gnu cal does. This is currently disabled for year view because of hard > coded padding in that case. This will hopefully be fixed soon. OK, what if some of us do not want this? Is there command line switch, compile macro, or anything else to retain traditional behavior planned? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r191330 - head/usr.bin/ncal
On Tue, Apr 21, 2009 at 09:06:51PM +0200, Roman Divacky wrote: > On Tue, Apr 21, 2009 at 02:54:36PM -0400, David Schultz wrote: > > Also, before this change, ncal was already full of convoluted > > buffer handling, arbitrary buffer sizes, and little to no bounds > > checking. This commit adds more magic numbers and fragile buffer > > handling code, and generally makes an already hairy program even > > less scrutable. This isn't your fault, but it would be nice if we > > could make ncal better before it gets much worse. For instance, > > you might use snprintf() or asprintf() instead of an extra half > > dozen calls to memcpy() with various offsets. > > yes, thats true. do you want me to revert this? I am perfectly fine > with having locally modified cal that supports this highlighting > and not share this with world at all. As a matter of fact, it might be good idea. Since the code is already in repo, it can be revised later and committed again in its refined form. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r191060 - in head/sys/dev: twa twe
On Thu, Apr 23, 2009 at 01:02:10AM +0200, Ed Schouten wrote: > * Stanislav Sedov wrote: > > Any reason to have two tabs here? > > Yes. I think the ioctl() function in the same file also used this line, > so I just literally copy/pasted it into open()/close(). But it looks like style bug which is supposed to get fixed, not duplicated. I am wrong? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r191681 - head/share/misc
On Thu, Apr 30, 2009 at 04:21:53PM +0400, Ruslan Ermilov wrote: > > How about enabling the ability to edit svn:log revision property, to > allow to fix commit logs? > > : svn: Revprop change blocked by pre-revprop-change hook (exit code 1) with > output: > : Changing revision properties is prohibited This would also remedy quite a number of mistakes that were previously "fixed" with now defunct force commits. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r261342 - in head: lib/libpmc sys/conf sys/dev/hwpmc sys/powerpc/include sys/sys
On Sat, Feb 01, 2014 at 02:03:51AM +, Justin Hibbits wrote: > New Revision: 261342 > URL: http://svnweb.freebsd.org/changeset/base/261342 > > Log: > Add hwpmc(4) support for the PowerPC 970 class processors, direct events. > This also fixes asserts on removal of the module for the mpc74xx. Hmm, -CURRENT does not build for me after this commit apparently; take a look at the log excerpt. Could it be that r261342 relies on some earlier revision which I'm missing (that is, my r260369'ish -CURRENT is too old)? What's the best way to catch up? Thanks, ./danfe ===> lib/libpmc (all) /usr/local/libexec/ccache/world/cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/lib/libpmc/libpmc.c -o libpmc.o cc1: warnings being treated as errors /usr/src/lib/libpmc/libpmc.c:160: warning: implicit declaration of function '__PMC_EV_PPC970' /usr/src/lib/libpmc/libpmc.c:160: warning: missing braces around initializer /usr/src/lib/libpmc/libpmc.c:160: warning: (near initialization for 'ppc970_event_table[0]') /usr/src/lib/libpmc/libpmc.c:160: error: initializer element is not constant /usr/src/lib/libpmc/libpmc.c:160: error: (near initialization for 'ppc970_event_table[0].pm_ev_name') /usr/src/lib/libpmc/libpmc.c:160: warning: missing initializer /usr/src/lib/libpmc/libpmc.c:160: warning: (near initialization for 'ppc970_event_table[0].pm_ev_name') /usr/src/lib/libpmc/libpmc.c:174: warning: implicit declaration of function '__PMC_EV_ALIAS_ATOM_SILVERMONT' /usr/src/lib/libpmc/libpmc.c:175: warning: missing braces around initializer /usr/src/lib/libpmc/libpmc.c:175: warning: (near initialization for 'atom_silvermont_event_table[0]') /usr/src/lib/libpmc/libpmc.c:175: error: initializer element is not constant /usr/src/lib/libpmc/libpmc.c:175: error: (near initialization for 'atom_silvermont_event_table[0].pm_ev_name') /usr/src/lib/libpmc/libpmc.c:175: warning: missing initializer /usr/src/lib/libpmc/libpmc.c:175: warning: (near initialization for 'atom_silvermont_event_table[0].pm_ev_name') /usr/src/lib/libpmc/libpmc.c:273: error: 'PMC_CLASS_PPC970' undeclared here (not in a function) /usr/src/lib/libpmc/libpmc.c:273: error: initializer element is not constant /usr/src/lib/libpmc/libpmc.c:273: error: (near initialization for 'ppc970_pmc_classes[0]') /usr/src/lib/libpmc/libpmc.c:273: error: initializer element is not constant /usr/src/lib/libpmc/libpmc.c:273: error: (near initialization for 'ppc970_pmc_classes[2]') /usr/src/lib/libpmc/libpmc.c:336: error: initializer element is not constant /usr/src/lib/libpmc/libpmc.c:336: error: (near initialization for 'ppc970_class_table_descr.pm_evc_class') /usr/src/lib/libpmc/libpmc.c: In function 'pmc_event_names_of_class': /usr/src/lib/libpmc/libpmc.c:2746: error: 'PMC_CPU_INTEL_ATOM_SILVERMONT' undeclared (first use in this function) /usr/src/lib/libpmc/libpmc.c:2746: error: (Each undeclared identifier is reported only once /usr/src/lib/libpmc/libpmc.c:2746: error: for each function it appears in.) /usr/src/lib/libpmc/libpmc.c: In function 'pmc_init': /usr/src/lib/libpmc/libpmc.c:3135: error: 'PMC_CPU_PPC_970' undeclared (first use in this function) /usr/src/lib/libpmc/libpmc.c: In function '_pmc_name_of_event': /usr/src/lib/libpmc/libpmc.c:3222: error: 'PMC_CPU_INTEL_ATOM_SILVERMONT' undeclared (first use in this function) /usr/src/lib/libpmc/libpmc.c:3314: error: 'PMC_EV_PPC970_FIRST' undeclared (first use in this function) /usr/src/lib/libpmc/libpmc.c:3314: warning: comparison between pointer and integer /usr/src/lib/libpmc/libpmc.c:3314: error: 'PMC_EV_PPC970_LAST' undeclared (first use in this function) /usr/src/lib/libpmc/libpmc.c:3314: warning: comparison between pointer and integer *** Error code 1 ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r261342 - in head: lib/libpmc sys/conf sys/dev/hwpmc sys/powerpc/include sys/sys
On Sun, Mar 23, 2014 at 10:58:18PM -0700, Justin Hibbits wrote: > On Mon, 24 Mar 2014 05:44:42 +0000 Alexey Dokuchaev wrote: > > Hmm, -CURRENT does not build for me after this commit apparently; > > take a look at the log excerpt. Could it be that r261342 relies on > > some earlier revision which I'm missing (that is, my r260369'ish > > -CURRENT is too old)? What's the best way to catch up? Thanks, > > It looks to me like it's picking up your old PMC header files. Did you > try doing a full buildworld (without a -DNO_CLEAN)? I've built world > multiple times since and it works just fine for me. It turned out to be ccache's fault. Once I've resumed the build with -DNO_CLEAN -DNO_CCACHE, it finished just fine. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r263355 - stable/9/sys/kern
On Wed, Mar 19, 2014 at 12:57:13PM +, Konstantin Belousov wrote: > New Revision: 263355 > URL: http://svnweb.freebsd.org/changeset/base/263355 > > Log: > MFC r263079: > The auio structure is only initialized when the vnode is symlink, > avoid reading from it otherwise. Is it applicable to stable/8, and if yes, can it be MFCed? Thanks, ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r263355 - stable/9/sys/kern
On Thu, Mar 27, 2014 at 02:11:55PM +0200, Konstantin Belousov wrote: > On Thu, Mar 27, 2014 at 09:40:03AM +0000, Alexey Dokuchaev wrote: > > On Wed, Mar 19, 2014 at 12:57:13PM +, Konstantin Belousov wrote: > > > New Revision: 263355 > > > URL: http://svnweb.freebsd.org/changeset/base/263355 > > > > > > Log: > > > MFC r263079: > > > The auio structure is only initialized when the vnode is symlink, > > > avoid reading from it otherwise. > > > > Is it applicable to stable/8, and if yes, can it be MFCed? Thanks, > > This is purely cosmetic commit. Why do you insist on merging ? I am not insisting. ;-) I thought it was more than purely cosmetic, but then again, I did not study the code thoroughly enough. Sorry for the noise. My reason in that stable/8 is going to be EOLed sooner or later, yet I'm not willing to move from it since 9.x/10.x do not bring anything important for me except the bloat, and 8.x works perfectly fine. That said, I'm trying to get seemingly important bug fixes MFCed, albeit sometimes I overestimate their importance and/or relevance. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r263885 - in head/sys/dev/vt: . hw/vga
On Sun, Mar 30, 2014 at 12:35:23AM +0200, Aleksandr Rybalko wrote: > vt(4) have to use bitblt like method which is able to do masked write, > since mouse cursor have to left visible characters under itself. > But masked bitblt quite expensive due to read from framebuffer to apply > mask or due to VGA graphics mode problem (described here [1], lot of > small read and writes which can't be well optimized). > > Characters can be drown with simple (not masked) method, so vd_bitbltchr > used most frequently. > Mouse cursor only one (at least vt(4) can care about one :) ). And > currently mouse support only single consumer for masked method. I've always wondered why FreeBSD *ever* had this ugly "look-we-can-make-it- like-in-wind0ze" mouse pointer on the console. I've been always building kernel with SC_ALT_MOUSE_IMAGE; I'm really hoping (if this nonsense has to stay) there will be an option to completely disable it and all related code paths when vt(4) eventually replaces syscons(4). ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r263885 - in head/sys/dev/vt: . hw/vga
On Sun, Mar 30, 2014 at 11:38:24PM +0300, Aleksandr Rybalko wrote: > > I've always wondered why FreeBSD *ever* had this ugly > > "look-we-can-make-it- like-in-wind0ze" mouse pointer on the console. > > I've been always building kernel with SC_ALT_MOUSE_IMAGE; I'm really > > hoping (if this nonsense has to stay) there will be an option to > > completely disable it and all related code paths when vt(4) > > eventually replaces syscons(4). > > its name SC_NO_CUTPASTE for both syscons(4) and vt(4). Hmm, doesn't seem so. I've never had this option in kernel config, and its name suggest it's for disabling cut-n-paste buffer, which is not what I want (and find it very convenient, FWIW). I'm pretty sure that SC_ALT_MOUSE_IMAGE gives me that standard, "inverted" nice text-mode mouse pointer we all used to since early DOS years. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r263979 - in head: . contrib usr.bin
On Mon, Mar 31, 2014 at 05:14:10PM -0700, Xin Li wrote: > On 03/31/14 17:01, Glen Barber wrote: > > New Revision: 263979 > > URL: http://svnweb.freebsd.org/changeset/base/263979 > > > > Log: Import ruby19. > > Yay! Now we can import OpenJDK too ;-) I won't be exactly surprized when^Wif we do it one day. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r264269 - in head: sys/conf sys/kern sys/modules sys/modules/imgact_binmisc sys/sys usr.sbin usr.sbin/binmiscctl
On Tue, Apr 08, 2014 at 03:01:49PM -0700, Sean Bruno wrote: > I haven't tested on non-x86 h/w and have no idea if it works or not. I > didn't feel comfortable building this driver in the non-x86 case. If > there is a use case/tester for the other arch's, I'll be more than happy > to change this. I'd like to test it on PowerPC. Is there quick start guide available with some examples of usage? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On Tue, Jun 18, 2013 at 06:40:30PM +0200, Tijl Coosemans wrote: > On 2013-06-18 04:53, Peter Wemm wrote: > > New Revision: 251886 > > URL: http://svnweb.freebsd.org/changeset/base/251886 > > > > Log: > > Introduce svnlite so that we can check out our source code again. > > [...] > > I don't find it unreasonable to ask developers to install the port. > And for users it seems all they need is something like portsnap for base. > Portsnap already distributes ports svn so it shouldn't be too hard to > adapt it for base. And the extra layer it adds is very convenient. Apart > from a bigger than usual update maybe, portsnap users never even noticed > it was switched from cvs to svn at some point. +1. I fail to see the point of bringing Subversion and its supporting cruft into the base, even in some kind of "lite" form. We've done good thing getting rid or Perl many years ago, but since then we apparently keep adding stuff into the base instead of trying to get rid of it and all that maintenance burden that comes with it. Heck, it's not even required for the build, just to get the sources! пWe know that there's an ongoing effort of svnup, dependency-less checkout tool for the matter; perhaps it makes sence to invest into improving and importing it instead? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On Tue, Jun 18, 2013 at 06:48:24PM +0200, Andre Oppermann wrote: > Installing SVN from ports is very painful because of the huge dependency > chain it carries, with the largest being Python and Perl IIRC. I've built a static version once (there is an OPTION for it) and simply copy it around whenever I need it on a freshly installed box. Seems to work just fine. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On Tue, Jun 18, 2013 at 12:54:37PM -0400, Nikolai Lifanov wrote: > On 06/18/13 12:48, Andre Oppermann wrote: > >AFAIK there is a checkout-only SVN client available, as in cvsup, but I > >don't remember the name. > > It's net/svnup and is a great replacement for cvs, in my opinion. > CVS wasn't used for development for a long while anyway, so there is > nothing subversion is replacing that net/svnup wouldn't. AFAIK it still has (had?) some issues (performance-wise or something), that's why I mentioned that perhaps it should be improved (with some help of our community), and then imported. On the positive side, it seems that it's a rather active project, and there's a lot interest in it, so it should not take too long. Being able to checkout the sources is very desirable, but not at the cost of importing another heavy 3rd-party tool, which Subversion is. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On Wed, Jun 19, 2013 at 12:25:07PM +0930, Daniel O'Connor wrote: > On 19/06/2013, at 2:18, Andre Oppermann wrote: > > Installing SVN from ports is very painful because of the huge dependency > > chain it carries, with the largest being Python and Perl IIRC. > > Perhaps there should be an svnlite port then, or svnstatic or similar. > > If an svnstatic port was installed as a package it would have no run time > dependencies, so not huge chains of stuff to install. We do have it, actually: devel/subversion-static. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On Tue, Jun 18, 2013 at 03:47:44PM -0400, Garance A Drosehn wrote: > Note that a major change to the FreeBSD repo would require that users > install a new 'svn' anyway, even if they did install 'svn' back when > they first installed FreeBSD. > > IMO, I think this 'svnlite' idea is a good move. I wouldn't want a > full-blown official 'svn' in the base system, but just enough that > a user can immediately get freebsd-specific updates without first > needing to install some port. Frankly I find it somehow wrong that user who wants to immediately get freebsd-specific updates should use any source-control tools and compile stuff from sources. That what developers usually do, not users. Users, in their majority, do not like to build things, and that makes perfect sense. As Ubuntu user at $work, I never had to worry about how and where shall we get updates, yet the system somehow gets them, installs them, only occasionally asking for a reboot. Now, if our user is showing developer's attitude and wants to "make world", then it's fair to assume that he knows how to install things from ports, or has his own static svn client with him all the time, or mounts /usr/src over NFS -- whatever works better for him. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r251958 - head/contrib/bmake
On Tue, Jun 18, 2013 at 02:25:15PM -0700, Garrett Cooper wrote: > On Tue, Jun 18, 2013 at 12:35 PM, Simon J. Gerraty wrote: > > Author: sjg > > Date: Tue Jun 18 19:35:51 2013 > > New Revision: 251958 > > URL: http://svnweb.freebsd.org/changeset/base/251958 > > Was this the source of the huge > ignoring stale .depend > messages? Also seen that shit, quite scary. ;-) Thanks for fixing it and making -current more usable! ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r252425 - head/sys/arm/arm
On Mon, Jul 01, 2013 at 11:56:25AM +1000, Bruce Evans wrote: > On Sun, 30 Jun 2013, Aleksandr Rybalko wrote: > >Log: > > Decrypt magic numbers - define names for fields of Generic Timer's > > CNTKCTL reg. > >... > >+#define GENERIC_TIMER_CNTPSIRQ 29 > > Here the interesting part CNTPSIRQ is fairly abbreviated, but its prefix > is not. [...] > > For full uglyness, expand all the prefixes and names: > - SYS -> SYSTEM > - RES -> RESOURCE > - IRQ -> INTERRUPT_REQUEST_NUMBER > - SYS_RES_IRQ -> SYSTEM_RESOURCE_INTERRUPT_REQUEST_NUMBER > - RF -> RESOURCE_FLAG > - RF_SHAREABLE_RESOURCE_FLAG_SHAREABLE - RF_ACTIVE -> > RESOURCE_FLAG_ACTIVE > - CNTPSIRQ -> COUNT_PRIVATELY_SOURCED_INTERRUPT_REQUEST_NUMBER > (just guessing what PS means): [...] > > The names aren't even 80 characters long, so they actually fit on 1 line. LOL, nice write up Bruce. That's what usually happens when people are asked to address some issue, but actually they don't understand very well what's upsetting people. ;-) ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r252514 - head/sbin/swapon
On Tue, Jul 02, 2013 at 05:34:35PM +, Xin LI wrote: > New Revision: 252514 > URL: http://svnweb.freebsd.org/changeset/base/252514 > > Log: > Plug a memory leak. Is MFC to stable/[89] applicable? If yes, can it be scheduled? ;-) ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r252913 - head/sys/arm/ti/am335x
On Sat, Jul 06, 2013 at 09:33:08PM -0700, Juli Mallett wrote: > Thanks for this and the other commits, Oleksandr! Much appreciated. > Looking forward to giving it a spin on my BeagleBones Black! > > [commit diff skipped] Looking forward to never see overquoting again on FreeBSD lists! ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r252928 - stable/9/sys/netinet
On Sun, Jul 07, 2013 at 11:36:47AM +, Michael Tuexen wrote: > Author: tuexen > Date: Sun Jul 7 11:36:46 2013 > New Revision: 252928 > URL: http://svnweb.freebsd.org/changeset/base/252928 > > Log: > MFC r240158: > Get rid of a gcc'ism. Neat trick! I should use it more. ;-) Hope Clang will uphold it one day. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r253002 - head
On Mon, Jul 08, 2013 at 01:02:39AM +0300, Andriy Gapon wrote: > I am sure that the next time you need to run the same thing you'll remember > where you put the comment and you'll copy/paste from it. > I am sure that if any other developer runs into the same situation, then he > will: > - google > - ask on irc > - ask on mailing lists > - perhaps even read build(7) > > I am sure that looking through the Makefile would be one of the last things > on his mind. It's quite on the contrary. First people reach for comments/documentation; only as a last resort they will use Google or ask on MLs. Bad documentation is probably one of the key of Google's success. :-) ./danfe P.S. You gotta be kidding us, right? ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r253513 - head/release
On Sun, Jul 21, 2013 at 05:23:34AM +, Glen Barber wrote: > New Revision: 253513 > URL: http://svnweb.freebsd.org/changeset/base/253513 > > Log: > Create memstick images with the '.img' filename extension. > > Requested by: many > [...] Is there any work being done to merge the .iso and .img into single, hybrid bootable image (c.g. Haiku)? I've asked this question before, but I cannot recall now what was the outcome if it... ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r253513 - head/release
On Sun, Jul 21, 2013 at 04:17:26PM +, Teske, Devin wrote: > On Jul 21, 2013, at 6:39 AM, Alexey Dokuchaev wrote: > > Is there any work being done to merge the .iso and .img into single, > > hybrid bootable image (c.g. Haiku)? I've asked this question before, > > but I cannot recall now what was the outcome if it... > > I have been doing this for years @ $work with sysinstall. [...] > > P.S. It's *so* much more than *just* taking the installer and Hybridizing > it to work with CD versus USB seamlessly. The "Druid" line is a master- > work that took 7 years to produce. > > P.P.S. Been working on rewriting other aspects of the installer before we > revisit the idea of merging Druid components to achieve what you're > asking. For now, we have the Druid to show us a proof-of-concept that it's > not only achievable, but it's damned slick when you do get to the > hybridized arena. Undersood, thanks for the info. Looking forward to see it merged one day to both installer and release generation code. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r253614 - head/usr.bin/patch
On Wed, Jul 24, 2013 at 03:46:50PM +, Pedro F. Giffuni wrote: > New Revision: 253614 > URL: http://svnweb.freebsd.org/changeset/base/253614 > > Log: > patch: style fix It's still broken: bad use of capital letters (lack thereof), missing full stop (terminating dot). > Submitted by: gogolok $ finger gogo...@freebsd.org [...] finger: gogolok: no such user ?? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r253614 - head/usr.bin/patch
On Wed, Jul 24, 2013 at 01:14:25PM -0500, Pedro Giffuni wrote: > El 24/07/2013 11:52 a. m., Alexey Dokuchaev escribiцЁ: > >On Wed, Jul 24, 2013 at 03:46:50PM +, Pedro F. Giffuni wrote: > >>New Revision: 253614 > >>URL: http://svnweb.freebsd.org/changeset/base/253614 > >> > >>Log: > >> patch: style fix > > > >It's still broken: bad use of capital letters (lack thereof), missing full > >stop (terminating dot). > > > > All the comments in that file have that same problem. At least now > we are consistently inconsistent. ;-) > >> Submitted by:gogolok > > > >$ finger gogo...@freebsd.org > >[...] > >finger: gogolok: no such user > > > >?? > > > @google ... > > I actually don't have more information about the submitter: My point was that "short" should only be used for our fellow committers. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r247910 - head/sys/dev/sound/pci/hda
On Thu, Mar 07, 2013 at 07:54:50AM +, Gleb Smirnoff wrote: > New Revision: 247910 > URL: http://svnweb.freebsd.org/changeset/base/247910 > > Log: > Plug a memory leak. > > Reviewed by:mav > Sponsored by: Nginx, Inc. Any MFCs planned? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r247910 - head/sys/dev/sound/pci/hda
On Sat, Mar 09, 2013 at 03:48:04PM +0400, Gleb Smirnoff wrote: > On Fri, Mar 08, 2013 at 02:00:50AM +0000, Alexey Dokuchaev wrote: > A> On Thu, Mar 07, 2013 at 07:54:50AM +, Gleb Smirnoff wrote: > A> > New Revision: 247910 > A> > URL: http://svnweb.freebsd.org/changeset/base/247910 > A> > > A> > Log: > A> > Plug a memory leak. > A> > > A> > Reviewed by: mav > A> > Sponsored by: Nginx, Inc. > A> > A> Any MFCs planned? > > Yes, to stable/9. I've tested in on stable/8, also looks applicable. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r236750 - in stable/8: share/man/man4 sys/conf sys/dev/sound/pci/hda sys/modules/sound/driver/hda
On Fri, Jun 08, 2012 at 12:35:44PM +, Alexander Motin wrote: > New Revision: 236750 > URL: http://svn.freebsd.org/changeset/base/236750 > > Log: > MFC r230130: > Major snd_hda driver rewrite: >- Huge old hdac driver was split into three independent pieces: HDA > controller driver (hdac), HDA CODEC driver (hdacc) and HDA sudio function > driver (hdaa). [...] Alexander, Unfortunately, this commit apparently had broken the sound for me on my laptop. Back in 2011 you've helped me to come up with correct pin patches to fix both playback and recording on my notebook on stable/8 [1]: hint.hdac.0.cad0.nid13.config="as=1 seq=15" hint.hdac.0.cad0.nid9.config="as=4 seq=0" I've tried to apply the same changes (convert to the new sysctls), that is, dev.hdaa.0.nid13_config and dev.hdaa.0.nid9_config, but it did not work out (after dev.hdaa.0.reconfig=1). Do you have any idea how to fix it against the new driver? Please feel free to request any additional information and/or debugging aid. I would also happily provide you with remote access to the laptop, shall it be needed. ./danfe [1] http://docs.freebsd.org/cgi/mid.cgi?4DECC964.4040009 ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r236750 - in stable/8: share/man/man4 sys/conf sys/dev/sound/pci/hda sys/modules/sound/driver/hda
On Thu, Mar 21, 2013 at 04:25:21PM +, Alexey Dokuchaev wrote: > On Fri, Jun 08, 2012 at 12:35:44PM +, Alexander Motin wrote: > > New Revision: 236750 > > URL: http://svn.freebsd.org/changeset/base/236750 > > > > Log: > > MFC r230130: > > Major snd_hda driver rewrite: > >- Huge old hdac driver was split into three independent pieces: HDA > > controller driver (hdac), HDA CODEC driver (hdacc) and HDA sudio function > > driver (hdaa). [...] > > Unfortunately, this commit apparently had broken the sound for me on my > laptop. [...] While trying to debug this problem, I've noticed that though I can recompile snd_hda(4), I cannot load it: # kldload ./snd_hda.ko kldload: can't load ./snd_hda.ko: No such file or directory The message is clearly bogus, but in /var/log/messages I see this line: link_elf: symbol snd_verbose undefined Is this known behavior? How to remedy it? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r236750 - in stable/8: share/man/man4 sys/conf sys/dev/sound/pci/hda sys/modules/sound/driver/hda
On Mon, Apr 01, 2013 at 01:51:56PM +0300, Alexander Motin wrote: > On 01.04.2013 11:50, Alexey Dokuchaev wrote: > >While trying to debug this problem, I've noticed that though I can > >recompile snd_hda(4), I cannot load it: > > > > # kldload ./snd_hda.ko > > kldload: can't load ./snd_hda.ko: No such file or directory > > > >The message is clearly bogus, but in /var/log/messages I see this line: > > > > link_elf: symbol snd_verbose undefined > > > >Is this known behavior? How to remedy it? > > I guess it is result of some mismatch between sources used for > building and the running kernel. I haven't tested it last time, but > previously snd_hda perfectly worked as module. It works perfectly as a module, indeed: if I do full "make kernel". I use modules whenever it's possible in fact. The problem is that once I rebuild (in exactly the same source base) just snd_hda(4), that is "cd /sys/modules /sound/driver/hda && make", I cannot load newly built ./snd_hda.ko anymore, while "kldload /boot/kernel/snd_hda.ko" works fine. On the same running kernel, against the very same sources. I needed sound to work very soon this time (upcoming Skype conference call), so I just rolled back your changes and did "make kernel", but honestly I find it very annoying having to rebuild entire kernel when just snd_hda(4) rebuild should suffice. BTW, any ideas why my nid patches from pre-r236750 no longer apply? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r236750 - in stable/8: share/man/man4 sys/conf sys/dev/sound/pci/hda sys/modules/sound/driver/hda
On Mon, Apr 01, 2013 at 08:50:49AM +, Alexey Dokuchaev wrote: > On Thu, Mar 21, 2013 at 04:25:21PM +0000, Alexey Dokuchaev wrote: > > On Fri, Jun 08, 2012 at 12:35:44PM +, Alexander Motin wrote: > > > New Revision: 236750 > > > URL: http://svn.freebsd.org/changeset/base/236750 > > > > > > Log: > > > MFC r230130: > > > Major snd_hda driver rewrite: > > >- Huge old hdac driver was split into three independent pieces: HDA > > > controller driver (hdac), HDA CODEC driver (hdacc) and HDA sudio > > > function driver (hdaa). [...] > > > > Unfortunately, this commit apparently had broken the sound for me on my > > laptop. [...] > > While trying to debug this problem, I've noticed that though I can recompile > snd_hda(4), I cannot load it: > > # kldload ./snd_hda.ko > kldload: can't load ./snd_hda.ko: No such file or directory > > The message is clearly bogus, but in /var/log/messages I see this line: > > link_elf: symbol snd_verbose undefined Please ignore this: it's the fault of ld(1) from binutils-2.23.1 I happened to have in my $PATH before system ld(1), not yours; sorry. The question about nid overrides still remains unanswered, though. Anything I can do to expedite the investigation? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r249576 - stable/8/sys/dev/sound/pci/hda
Author: danfe (ports committer)
Date: Wed Apr 17 05:56:59 2013
New Revision: 249576
URL: http://svnweb.freebsd.org/changeset/base/249576
Log:
MFC r247910:
Plug a memory leak.
Reviewed by:mav
Sponsored by: Nginx, Inc.
Approved by: glebius
Modified:
stable/8/sys/dev/sound/pci/hda/hdacc.c
Directory Properties:
stable/8/sys/ (props changed)
stable/8/sys/dev/ (props changed)
stable/8/sys/dev/sound/ (props changed)
stable/8/sys/dev/sound/pci/ (props changed)
Modified: stable/8/sys/dev/sound/pci/hda/hdacc.c
==
--- stable/8/sys/dev/sound/pci/hda/hdacc.c Wed Apr 17 02:40:07 2013
(r249575)
+++ stable/8/sys/dev/sound/pci/hda/hdacc.c Wed Apr 17 05:56:59 2013
(r249576)
@@ -460,8 +460,12 @@ hdacc_attach(device_t dev)
static int
hdacc_detach(device_t dev)
{
+ struct hdacc_softc *codec = device_get_softc(dev);
+ int error;
- return (device_delete_children(dev));
+ error = device_delete_children(dev);
+ free(codec->fgs, M_HDACC);
+ return (error);
}
static int
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r249930 - head/sys/geom
On Fri, Apr 26, 2013 at 03:43:24PM +, Steven Hartland wrote: > New Revision: 249930 > URL: http://svnweb.freebsd.org/changeset/base/249930 > > Log: > [...] > In tests on a Intel 520 120GB FW: 400i disk it improved the delete > throughput > from 1.6GB/s to over 2.6GB/s on a full disk delete such as that done via > newfs -E > [...] > MFC after: 2 weeks Nice, Please don't forget about stable/8, thanks! ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r262882 - head/tools/tools/net80211/wlanstats
On Fri, Mar 07, 2014 at 01:23:49AM +, Eitan Adler wrote: > New Revision: 262882 > URL: http://svnweb.freebsd.org/changeset/base/262882 > > Log: > wlanstats: add help > > - add a help (-h) flag > - move usage into itsown function it looks like the only change now is that usage info always go to stdout, and exit code differs. i don't think it should be mfced. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r263212 - in stable/9: share/mk usr.bin usr.bin/bmake
On Sun, Mar 16, 2014 at 02:42:55AM +0100, Baptiste Daroussin wrote: > On Sat, Mar 15, 2014 at 11:51:28PM +, Simon J. Gerraty wrote: > > New Revision: 263212 > > URL: http://svnweb.freebsd.org/changeset/base/263212 > > > > Log: > > Backport bmake to 9 so ports can rely on it being available. > > We only build/install it as bmake. > > Thank you very much that will help a lot ports to move forward once the 8 > branch will be EOLed. Hmm, can you elaborate on this? I was hoping 8.x will support ports (after official EOL) for a while; how could lack of bmake in the 8.x base affect this? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r253888 - stable/9/usr.bin/grep/regex
On Fri, Aug 02, 2013 at 05:13:29PM +, Andrey A. Chernov wrote: > New Revision: 253888 > URL: http://svnweb.freebsd.org/changeset/base/253888 > > Log: > MFC r253810 > > grep -i does not work for simple patterns and single byte locales, like > LANG=ru_RU.KOI8-R grep -i > Fix it. Nice, could you please MFC it to stable/8 as well? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r254025 - in head/sys: amd64/amd64 arm/arm arm/at91 arm/mv/armadaxp arm/s3c2xx0 arm/xscale/i80321 arm/xscale/i8134x arm/xscale/ixp425 cddl/compat/opensolaris/kern cddl/compat/opensolar
On Wed, Aug 07, 2013 at 07:06:24PM +0300, Andriy Gapon wrote: > on 07/08/2013 18:27 Nikolai Lifanov said the following: > > Does this need a param.h bump? > > At least x11/nvidia-driver is sensitive to this. > > Sorry, but did you have to quote more than 1000 lines to ask this? +1 for overquoting anger. As for __FreeBSD_version bump, luckily for us, it was bumped just two days ago, and Nikolai already used it in this patch to fix nvidia-driver. That said, while Jeff probably should have bumped it, it seems not that necessary to bump __FreeBSD_version twice within couple of days. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On Thu, Sep 05, 2013 at 12:09:57AM +, Pawel Jakub Dawidek wrote:
> Author: pjd
> Date: Thu Sep 5 00:09:56 2013
> New Revision: 255219
> URL: http://svnweb.freebsd.org/changeset/base/255219
>
> Log:
> Change the cap_rights_t type from uint64_t to a structure that we can extend
> in the future in a backward compatible (API and ABI) way.
>
> The cap_rights_t represents capability rights. We used to use one bit to
> represent one right, but we are running out of spare bits. Currently the new
> structure provides place for 114 rights (so 50 more than the previous
> cap_rights_t), but it is possible to grow the structure to hold at least 285
> rights, although we can make it even larger if 285 rights won't be enough.
>
> The structure definition looks like this:
>
> struct cap_rights {
> uint64_tcr_rights[CAP_RIGHTS_VERSION + 2];
> };
I believe this commit broke nvidia-driver. Fix is trivial; however, I would
have to use OSVERSION from Sep 3rd, since you forgot to update sys/param.h.
./danfe
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r255323 - in head/sys: amd64/conf i386/conf
On Sat, Sep 07, 2013 at 10:48:48PM +0200, Edward Tomasz NapieraЁa wrote: > I have no idea on what's the loader(8) state right now, but long time ago > I've made a patch that made it significantly faster by making caching > actually work. Nice, the patch actually applies against 8-stable. I will test it next time I will rebuild the world on my laptop, thanks! > No idea if anyone picked up the patch [url skipped] though. Why it was never committed? Lack of review, or are there any issues/concerns raised by the patch? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r255426 - in head: lib/libc/sys sys/compat/freebsd32 sys/compat/linux sys/compat/svr4 sys/dev/drm2/i915 sys/i386/ibcs2 sys/i386/linux sys/ia64/ia32 sys/kern sys/sparc64/sparc64 sys/sys
On Mon, Sep 09, 2013 at 06:12:00PM +, John Baldwin wrote: > New Revision: 255426 > URL: http://svnweb.freebsd.org/changeset/base/255426 > > Log: > [...] > To facilitate this, add a new parameter to vm_map_find() that specifies an > optional maximum virtual address. While here, fix several callers of > vm_map_find() to use a VMFS_* constant for the findspace argument instead > of TRUE and FALSE. This commit breaks NVidia driver port, and (again) there was no corresponding __FreeBSD_version bump. This is another recent incident with -CURRENT silently changing KPIs that are publicly used. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r260474 - stable/9/sys/x86/cpufreq
On Thu, Jan 09, 2014 at 10:45:38AM +, Alexander Motin wrote: > New Revision: 260474 > URL: http://svnweb.freebsd.org/changeset/base/260474 > > Log: > MFC r259197: > Do not DELAY() for P-state transition unless we want to see the result. > > Intel manual says: "If a transition is already in progress, transition to > a new value will subsequently take effect. Reads of IA32_PERF_CTL determine > the last targeted operating point." So seems it should be fine to just > trigger wanted transition and go. Linux does the same. > > Modified: > stable/9/sys/x86/cpufreq/est.c It looks like stable/8 can also benefit from this commit. Mind making one? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r260474 - stable/9/sys/x86/cpufreq
On Mon, Jan 13, 2014 at 09:15:06PM +0200, Alexander Motin wrote: > On 13.01.2014 16:23, Alexey Dokuchaev wrote: > >On Thu, Jan 09, 2014 at 10:45:38AM +, Alexander Motin wrote: > >>New Revision: 260474 > >>URL: http://svnweb.freebsd.org/changeset/base/260474 > >>[...] > >>Modified: > >> stable/9/sys/x86/cpufreq/est.c > > > >It looks like stable/8 can also benefit from this commit. Mind making one? > > Done. Thank you. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r260783 - stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Thu, Jan 16, 2014 at 05:58:22PM +, Andriy Gapon wrote: > New Revision: 260783 > URL: http://svnweb.freebsd.org/changeset/base/260783 > > Log: > Revert r260780 "add zfs_bmap to aid vnode_pager_haspage" > > I thought that I had to have that commit in this branch, but now I > decided to not bother. Andriy, may I ask how soon you plan to finish merging to stable/8? I have a few patches (mostly GCC-related) to test against this branch, but rather wait for the dust to settle first to avoid any interference. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r261150 - head/sys/dev/virtio/network
On Sat, Jan 25, 2014 at 07:13:47AM +, Bryan Venteicher wrote: > New Revision: 261150 > URL: http://svnweb.freebsd.org/changeset/base/261150 > > Log: > Read and write the MAC address in the config space byte by byte Commit log looks incomplete: it does not tell what is the problem and how (why) committed change fixes it. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r261358 - head/sys/powerpc/conf
On Sat, Feb 01, 2014 at 08:56:50PM +, Nathan Whitehorn wrote: > New Revision: 261358 > URL: http://svnweb.freebsd.org/changeset/base/261358 > > Log: > Switch default Book-E scheduler to ULE, which works now, and enable > CAPABILITIES stuff required to make ssh work. Hmm; I've been using ssh(d) on a kernel w/out CAPABILITIES support just fine. Am I missing something? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r250306 - in stable/8/sys: net sys
On Mon, May 06, 2013 at 10:10:37PM +0200, Dimitry Andric wrote: > On May 6, 2013, at 21:59, Dimitry Andric wrote: > > New Revision: 250306 > > URL: http://svnweb.freebsd.org/changeset/base/250306 > > > > Log: > > MFC r215137: > > [...] > > > > MFC r215138: > > [...] > > See the following discussion for the reason to merge these changes: > http://docs.freebsd.org/cgi/mid.cgi?20130416121135.GA81519 Thank you! ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r250430 - head/sbin/dmesg
On Fri, May 10, 2013 at 03:42:48AM +, Eitan Adler wrote:
> New Revision: 250430
> URL: http://svnweb.freebsd.org/changeset/base/250430
>
> @@ -79,15 +80,20 @@ main(int argc, char *argv[])
> kvm_t *kd;
> size_t buflen, bufpos;
> long pri;
> - int all, ch;
> + int ch, clear;
> + bool all;
>
> - all = 0;
> + all = false;
> + clear = false;
> (void) setlocale(LC_CTYPE, "");
It's a bit weird that you've left the cast here...
> @@ -190,12 +196,16 @@ main(int argc, char *argv[])
> (void)strvisx(visbp, p, nextp - p, 0);
> (void)printf("%s", visbp);
... and here (also: notice inconsistent spacing),
> }
> + if (clear)
> + if (sysctlbyname("kern.msgbuf_clear", NULL, NULL, &clear,
> sizeof(int)))
> + err(1, "sysctl kern.msgbuf_clear");
> +
> exit(0);
> }
>
> void
> usage(void)
> {
> - (void)fprintf(stderr, "usage: dmesg [-a] [-M core [-N system]]\n");
> + fprintf(stderr, "usage: dmesg [-ac] [-M core [-N system]]\n");
but removed it here for no particular reason.
./danfe
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r250430 - head/sbin/dmesg
On Fri, May 10, 2013 at 08:43:37AM -0400, Eitan Adler wrote: > On 10 May 2013 03:42, Alexey Dokuchaev wrote: > > On Fri, May 10, 2013 at 03:42:48AM +, Eitan Adler wrote: > >> New Revision: 250430 > >> URL: http://svnweb.freebsd.org/changeset/base/250430 > >> > >> (void) setlocale(LC_CTYPE, ""); > > > > It's a bit weird that you've left the cast here... > > I didn't modify this line OK. > >> - (void)fprintf(stderr, "usage: dmesg [-a] [-M core [-N system]]\n"); > >> + fprintf(stderr, "usage: dmesg [-ac] [-M core [-N system]]\n"); > > > > but removed it here for no particular reason. > > Notice the additional 'c' in usage(). Of course. But my question was about dropping the cast, not adding new option. Adding a new option should have resulted in the following diff: - (void)fprintf(stderr, "usage: dmesg [-a] [-M core [-N system]]\n"); + (void)fprintf(stderr, "usage: dmesg [-ac] [-M core [-N system]]\n"); ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r250565 - head/etc
On Mon, May 13, 2013 at 01:14:35AM +0400, Dmitry Morozovsky wrote: > methodrealtm arsize > > gzip 45s 183M > bzip2 5m32s 115M > xz11m43s 112M > > I would tend to use xz for distributives (including freebsd-updates or > portsnap), where compression process is quite rare, but download size is > significant -- but not for logs, backups, or other similar once-packed > data... +1. xz is not part of all our releases, yet people still might be running 6.x for example, and they certainly won't be happy to keep two versions of their newsyslog.conf (otherwise identical) -- just another reason why this change is moot at least. Otherwise I totally agree with Dmitry that xz is not for frequent compressions of small files when it clearly loses to bzip2. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r250565 - head/etc
On Sun, May 12, 2013 at 11:37:48PM +0200, Ed Schouten wrote: > In fact, I think that for embedded systems, using xz compression would > even be better. Many of those systems are often more storage space > constrained than CPU constrained (e.g. a 200 MHz wireless device with > only 8 MB of flash). Speaking of embedded systems, we here at $work said no for xz (for compressing anything from initrd images to custom packages) precisely because it being notoriously slow. Really constrained environments certainly call for specific approaches, but just arbitrarily turning on xz compression on something as general purpose as syslog files is not the best thing to help one save space. If fact, I really doubt there would be any syslog files on filesystem with 8 MB of flash. :-) ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r250727 - stable/9/usr.sbin/wpa/wpa_supplicant
On Fri, May 17, 2013 at 12:14:36AM +, Eitan Adler wrote: > New Revision: 250727 > URL: http://svnweb.freebsd.org/changeset/base/250727 > > Log: > MFC r250528: > Teach wpa_supplicant to properly compute wireless signal strength. If this applicable to stable/8? If yes, can it be MFC'ed? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r250734 - stable/9/sys/x86/cpufreq
On Fri, May 17, 2013 at 04:09:05AM +, Hiren Panchasara wrote: > New Revision: 250734 > URL: http://svnweb.freebsd.org/changeset/base/250734 > > Log: > MFC: r250487 > > Adding a detach method to p4tcc driver. Would it also benefit stable/8? If yes, could it be MFC'ed? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r250734 - stable/9/sys/x86/cpufreq
On Fri, May 17, 2013 at 10:19:24AM -0700, hiren panchasara wrote: > On Thu, May 16, 2013 at 10:45 PM, Alexey Dokuchaev wrote: > > On Fri, May 17, 2013 at 04:09:05AM +, Hiren Panchasara wrote: > >> New Revision: 250734 > >> URL: http://svnweb.freebsd.org/changeset/base/250734 > >> > >> Log: > >> MFC: r250487 > >> > >> Adding a detach method to p4tcc driver. > > > > Would it also benefit stable/8? If yes, could it be MFC'ed? > > Committed: r250743 Seen it, thanks! ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r247086 - head/sys/x86/isa
On Thu, Feb 21, 2013 at 06:49:12AM +, Alexey Dokuchaev wrote: > On Thu, Feb 21, 2013 at 06:38:24AM +, Warner Losh wrote: > > New Revision: 247086 > > URL: http://svnweb.freebsd.org/changeset/base/247086 > > > > Log: > > Correct comment about use of pmtimer, and the real reason it isn't > > used or desirable for amd64. > > Thanks! > > > + * pmtimer is used only with the old APM power management, and not with > > + * acpi, which is required for amd64, so skip it in that case. > > Does it also mean it should be removed from ACPI-driven i386 machines kernel > configs? Apparently not: I've been running FreeBSD 8.4-PRERELEASE without pmtimer for a while, and noticed that my laptop stops keeping time during suspend. I've never noticed that behavior before (presumably, with pmtimer). I've found this old thread [1] on -current@ from Jan 2001 where src/UPDATING is quoted: The new pmtimer device is necessary for laptops. Failure to include the device will cause suspended laptops losing time when they resume. I will soon rebuild the kernel and put pmtimer back to see it fixes time keeping for me. If it will, apparently it is still useful for i386, and not just for APM, but ACPI as well... ./danfe [1] http://www.mail-archive.com/freebsd-current@freebsd.org/msg23642.html ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r247086 - head/sys/x86/isa
On Mon, May 20, 2013 at 07:20:48AM -0600, Warner Losh wrote:
> On May 19, 2013, at 8:21 PM, Alexey Dokuchaev wrote:
> > Apparently not: I've been running FreeBSD 8.4-PRERELEASE without pmtimer
> > for a while, and noticed that my laptop stops keeping time during suspend.
> > I've never noticed that behavior before (presumably, with pmtimer).
> >
> > I will soon rebuild the kernel and put pmtimer back to see it fixes time
> > keeping for me. If it will, apparently it is still useful for i386, and
> > not just for APM, but ACPI as well...
>
> It fights ACPI in what it does... It was needed for APM... Let me know how
> it turns out...
Just rebuilt vanilla r250824; timekeeping works fine (with pmtimer now). My
kernel config and loader.conf for reference:
http://193.124.210.26/{DARIA,loader.conf}
./danfe
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
