Re: CVS commit: src/sbin/dmctl
On Tue, Feb 8, 2011 at 2:58 PM, Paul Goyette pgoye...@netbsd.org wrote: Module Name: src Committed By: pgoyette Date: Tue Feb 8 13:58:54 UTC 2011 Modified Files: src/sbin/dmctl: dmctl.c Log Message: Use PRIu64 to fix build on amd64 (and presumably other 64-bit ports) Thanks ! To generate a diff of this commit: cvs rdiff -u -r1.1 -r1.2 src/sbin/dmctl/dmctl.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. -- Regards. Adam
Re: Changes made with too little discussion
On Wed, Jan 19, 2011 at 10:31 AM, Alan Barrett a...@cequrux.com wrote: On Tue, 18 Jan 2011, Jukka Ruohonen wrote: On Tue, Jan 18, 2011 at 11:34:23AM +1100, Simon Burge wrote: Why was this removed when there was an active discussion about removing it where no concensus was reached? This sort of thing where commis occur before a discussion is finished seems to be occurring more and more often. I don't care much about /usr/share/misc/operator, but I do care about people making changes without discussion, or making changes with too little discussion, or making changes that go against the consensus of the discussion. I would like to see this change reverted, becasue it was made with too little discussion. Maybe because the whole tech-userlevel@ mailing list has become poisonous? I know several people who abstain from posting anything to the list because of the nature of the list and these discussions. If you are not willing to discuss changes, or pay attention to other people's opinions, then you are part of the problem. You don't have to agree with everybody, but you do need to pay attention to the discussion. If no clear consensus emerges, or if the consensus is opposite from your preferred outcome, then you may appeal to core to make a decision. Let me say it this way, if will will spent months in clueless discussion about thinks like remove misc/operator we will not do any real work. e.g. Lua it took one year to discuss everything and it was major PITA for almost everyone. We need some proper way how to evaluate changes, discussion about them is clearly not good way. Because most of best developers are not talking in those never ending mail threads. In practice most active never ending mail writers contribute very small or zero amount of code. I really don't think that their opinion should be taken serious. If they really want to have NetBSD done by their way they should start contributing, just talking is not going to fix anything. E.G. Example scenario Dev A wants to add new feature, software whatever he spent his time on it, developing, testing preparing and sends patch to tech-userlevel@ where it starts never ending discussion about it how it slows build on 20years old vax(replace with anything with 128Mb ram). After few weeks of waiting Dev A doesn't have attitude to work on his patch anymore and he is totally pissed of by trying to explain that we really need to move forward. In the result we will lost (maybe good maybe wrong patch), contributing developer and onlyone who wins are those who a priori hates any change. Truly I haven't seen any discussion which had more than 10mails where clear consensus was made. Thats not going to happen. -- Regards. Adam
Re: CVS commit: src/distrib
On Fri, Jan 14, 2011 at 11:26 AM, Izumi Tsutsui tsut...@netbsd.org wrote: Module Name: src Committed By: tsutsui Date: Fri Jan 14 10:26:38 UTC 2011 Modified Files: src/distrib/acorn26/instkernel: list src/distrib/acorn32/ramdisk: list src/distrib/alpha/instkernel/ramdisk: list src/distrib/amd64/ramdisks/ramdisk: list src/distrib/amiga/floppies/inst-common: list src/distrib/arc/ramdisk: list src/distrib/atari/floppies/install: list src/distrib/atari/floppies/prepare: list src/distrib/bebox/ramdisk: list src/distrib/cats/ramdisk: list src/distrib/cobalt/ramdisk: list src/distrib/dreamcast/ramdisk: list src/distrib/evbarm/instkernel/ramdisk: list src/distrib/evbmips/instkernel/ramdisk: list src/distrib/evbppc/ramdisk: list src/distrib/evbsh3/instkernel/ramdisk: list src/distrib/evbsh3/rom/ramdiskcommon: list ramdiskbin.conf src/distrib/ews4800mips/floppies/ramdisk: list src/distrib/hp300/ramdisk: list src/distrib/hp700/ramdisk: list src/distrib/i386/cdroms: Makefile.cdrom src/distrib/i386/ramdisks/common: list.ramdisk src/distrib/ibmnws/netboot/ramdisk: list src/distrib/landisk/ramdisk: list src/distrib/mac68k/instkernel/ramdisk: list src/distrib/macppc/floppies/ramdisk: list src/distrib/miniroot: list src/distrib/mipsco/ramdisk: list src/distrib/news68k/floppies/ramdisk: list src/distrib/newsmips/floppies/ramdisk: list src/distrib/ofppc/ramdisks/ramdisk: list src/distrib/pmax/ramdisk: list src/distrib/prep/floppies/ramdisk: list src/distrib/rs6000/ramdisk: list src/distrib/sandpoint/ramdisk: list src/distrib/sgimips/ramdisk: list src/distrib/shark/instkernel/ramdisk: list src/distrib/sparc64/cdroms/installcd: Makefile src/distrib/sparc64/instfs: list src/distrib/sun2/miniroot: list src/distrib/sun3/miniroot: list src/distrib/vax/inst-common: list src/distrib/vax/ramdisk: list src/distrib/x68k/floppies/ramdisk: list src/distrib/zaurus/ramdisk: list Log Message: Adjust file lists for recent move: usr/sbin/chown - sbin/chown usr/bin/chgrp - bin/chgrp Thanks for fixing this. -- Regards. Adam
Re: /var/lock
On Mon, Jan 3, 2011 at 1:21 PM, Alan Barrett a...@cequrux.com wrote: On Mon, 03 Jan 2011, rud...@eq.cz wrote: Adam Hamsik wrote: Modified Files: src/distrib/sets/lists/base: mi src/etc/mtree: NetBSD.dist.base Log Message: Add /var/lock directory to base set it's used by LVM and other tools. Change group owner to operator to enable LVM locking for him. Why is /var/run not the right place for your needs? Also, where was this discussed? If it was discussed, please update hier(7) according to the outcome of the discussion. Ok I have commited fix for this. lvm tools now use /var/run/lvm directory for locks. I have patched mountcritlocal to create this dir for us, that wya it works for everyone in every case. -- Regards. Adam
Re: CVS commit: src
On Tue, Nov 30, 2010 at 3:23 PM, Antti Kantee po...@netbsd.org wrote: Module Name: src Committed By: pooka Date: Tue Nov 30 14:23:24 UTC 2010 Modified Files: src/lib/librumpuser: Makefile src/sys/rump/include/rump: rump.h rumpuser.h src/sys/rump/librump/rumpkern: rump.c Added Files: src/lib/librumpuser: rumpuser_daemonize.c Log Message: Require server to be explicitly initialized with rump_init_server(url). Also, add rump_daemonize_begin() / rump_daemonize_end() to help with the can't daemon() after pthread_create() problem. Applications could accomplish the same, but since it's such a common operation, provide a little help. Can you show some small example how rump server should look like now ? Just replace rump_init with rump_init_server ? and RUMP_SP_PATH is in url To generate a diff of this commit: cvs rdiff -u -r1.4 -r1.5 src/lib/librumpuser/Makefile cvs rdiff -u -r0 -r1.1 src/lib/librumpuser/rumpuser_daemonize.c cvs rdiff -u -r1.48 -r1.49 src/sys/rump/include/rump/rump.h cvs rdiff -u -r1.53 -r1.54 src/sys/rump/include/rump/rumpuser.h cvs rdiff -u -r1.206 -r1.207 src/sys/rump/librump/rumpkern/rump.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. -- Regards. Adam
Re: CVS commit: src/external/cddl/osnet
On Fri, Apr 23, 2010 at 1:39 PM, Adam Hoka ah...@netbsd.org wrote: Module Name: src Committed By: ahoka Date: Fri Apr 23 11:39:53 UTC 2010 Modified Files: src/external/cddl/osnet/dev/dtrace: dtrace_sysctl.c dtrace_unload.c src/external/cddl/osnet/dev/dtrace/amd64: dtrace_subr.c src/external/cddl/osnet/dev/dtrace/i386: dtrace_subr.c src/external/cddl/osnet/dist/uts/common/dtrace: dtrace.c Log Message: Remove a couple of zero length kmem_frees. It should fix at least one crash when unloading the dtrace module, possibly many others. This should be reverted and properly reviewed. Adding more diffs against solaris code base is wrong. -- Regards. Adam
Re: CVS commit: src
On Fri, Mar 12, 2010 at 10:53 PM, Darran Hunt dar...@netbsd.org wrote: Module Name: src Committed By: darran Date: Fri Mar 12 21:53:16 UTC 2010 Modified Files: src/distrib/sets/lists/modules: mi src/external/cddl/osnet/dev/fbt: fbt.c src/external/cddl/osnet/dist/uts/common/dtrace: dtrace.c src/sys/modules/dtrace: Makefile src/sys/sys: module.h Added Files: src/sys/modules/dtrace/fbt: Makefile Log Message: DTrace: Add the Function Boundary Trace (FBT) provider moduile. This module instruments every function in the kernel with entry and exit probes. These probes are true zero-effect probes in that they don't exist in the code until they are enabled. The probes are enabled by directly patching the function entry and exit points to make jumps into the dtrace framework. This gives us over 29,000 trace points in the kernel. Nice do you have any example how this can be used :) ? To generate a diff of this commit: cvs rdiff -u -r1.11 -r1.12 src/distrib/sets/lists/modules/mi cvs rdiff -u -r1.2 -r1.3 src/external/cddl/osnet/dev/fbt/fbt.c cvs rdiff -u -r1.8 -r1.9 \ src/external/cddl/osnet/dist/uts/common/dtrace/dtrace.c cvs rdiff -u -r1.2 -r1.3 src/sys/modules/dtrace/Makefile cvs rdiff -u -r0 -r1.1 src/sys/modules/dtrace/fbt/Makefile cvs rdiff -u -r1.20 -r1.21 src/sys/sys/module.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. -- Regards. Adam
Re: CVS commit: src/distrib/sets
On Wed, Mar 3, 2010 at 5:13 PM, Matthias Scheler t...@netbsd.org wrote: Module Name: src Committed By: tron Date: Wed Mar 3 16:13:42 UTC 2010 Modified Files: src/distrib/sets: mkvars.mk sets.subr src/distrib/sets/lists/modules: mi Log Message: dtrace,zfs means MKDTRACE=yes *and* MKZFS=yes which is not what we want. Invent a flag solaris which is the or of those two flags. Why is this needed ? I would rather see two flags one for zfs and one for dtrace. -- Regards. Adam
Re: CVS commit: src/sys/dev
On Tue, Nov 10, 2009 at 2:35 PM, Matthias Scheler t...@netbsd.org wrote: On Tue, Nov 10, 2009 at 08:48:42AM +, Matthias Scheler wrote: A LOCKDEBUG kernel will panic. How can we avoid the stack overflows and such in a different way? I'll try to rewrite the code to use M_NOWAIT. The attached diff changes the code to use M_NOWAIT. I have however only compiled tested it so far. I don't think that this is right approach which can work. Because M_NOWIAT allocation can very easily fail(even if there is free memory in system), which will panic cgd driver. -- Regards. Adam
