Re: CVS commit: src/usr.bin/make
On Thu, Apr 07, 2011 at 02:49:31AM +0100, Mindaugas Rasiukevicius wrote: > "Joerg Sonnenberger" wrote: > > Module Name:src > > Committed By: joerg > > Date: Thu Apr 7 01:40:02 UTC 2011 > > > > Modified Files: > > src/usr.bin/make: make.1 var.c > > src/usr.bin/make/unit-tests: Makefile test.exp > > Added Files: > > src/usr.bin/make/unit-tests: hash > > > > Log Message: > > Add the :hash modifier to compute a 32bit hash of an variable. > > This uses MurmurHash3 to get a reasonable collission-free hash with > > small code. The result is endian neutral. > > Cool. Can you please move MurmurHash3 hash into src/common? I have > been planning to use it in NPF, and potentially there are more uses in > the kernel, since it has a great speed and mixing trade-off. No. make has to be self-contained, so that doesn't make sense. Joerg
Re: CVS commit: src/usr.bin/make
"Joerg Sonnenberger" wrote: > Module Name: src > Committed By: joerg > Date: Thu Apr 7 01:40:02 UTC 2011 > > Modified Files: > src/usr.bin/make: make.1 var.c > src/usr.bin/make/unit-tests: Makefile test.exp > Added Files: > src/usr.bin/make/unit-tests: hash > > Log Message: > Add the :hash modifier to compute a 32bit hash of an variable. > This uses MurmurHash3 to get a reasonable collission-free hash with > small code. The result is endian neutral. Cool. Can you please move MurmurHash3 hash into src/common? I have been planning to use it in NPF, and potentially there are more uses in the kernel, since it has a great speed and mixing trade-off. Thanks. -- Mindaugas
Re: CVS commit: src/sys/arch/xen/xen
On 06.04.2011 20:01, Manuel Bouyer wrote: > You could also use > xvifxiy (e.g. xvif5i2, where i stands for 'index'). > or any other letter ... Huh hmm indeed... I wonder why I did not think about this approach before... -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: src/sys/arch/xen/xen
On Wed, Apr 06, 2011 at 05:41:37PM +0100, Jean-Yves Migeon wrote: > Yep, but there are other places where this will get tricky. For > example, rc.conf(5) is parsed as a classic shell script [1]. Given > that someone has two possibilities to configure interfaces: > > /etc/ifconfig.xxx > or > ifconfig_xxx # in rc.conf(5) > > If we follow the same "xxx" naming convention for both, we would > have to 'tr' certain lines of rc.conf for interfaces that contains a > [^a-zA-Z0-9_] char. This complexifies rc.conf parsing for no real > benefit. Putting a ifconfig_xxx-yyy="auto" in rc.conf(5) will likely > result in a parsing error. > > I am about to revert my patch anyway, and use '_' instead. I will > also update ifconfig.if(5) to clearly indicate that only chars > accepted in shell variable names should be used. You could also use xvifxiy (e.g. xvif5i2, where i stands for 'index'). or any other letter ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/arch/xen/xen
On Wed, 6 Apr 2011 16:29:22 +, Taylor R Campbell wrote: Date: Mon, 04 Apr 2011 23:46:19 +0200 From: Jean-Yves Migeon The newer scripts for Xen read the interface value from the vifname entry in Xenstore, so changing the name is not that critical. But this should be stabilized sooner than later. Personally, I find '_' rather ugly in an interface name... but I am open to suggestions, even fixing rc.d/network if it needs to. One could declare that ifnames must match [a-z][-a-z0-9]*[0-9], and then in /etc/rc.d/network pass them through `tr - _' before evaluating `args=\$ifconfig_$int'. This guarantees that setting ifconfig_ifN in /etc/rc.conf always works, and depends only on agreeing to the ifname policy and ensuring that all the existing ifnames actually follow it. Of course, tr might not be available yet in /etc/rc.d/network, but someone wizardlier (or more patient) with sh than I can probably work around that... Yep, but there are other places where this will get tricky. For example, rc.conf(5) is parsed as a classic shell script [1]. Given that someone has two possibilities to configure interfaces: /etc/ifconfig.xxx or ifconfig_xxx # in rc.conf(5) If we follow the same "xxx" naming convention for both, we would have to 'tr' certain lines of rc.conf for interfaces that contains a [^a-zA-Z0-9_] char. This complexifies rc.conf parsing for no real benefit. Putting a ifconfig_xxx-yyy="auto" in rc.conf(5) will likely result in a parsing error. I am about to revert my patch anyway, and use '_' instead. I will also update ifconfig.if(5) to clearly indicate that only chars accepted in shell variable names should be used. [1] http://nxr.netbsd.org/xref/src/etc/rc#22 -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: src/sys/arch/xen/xen
Date: Mon, 04 Apr 2011 23:46:19 +0200 From: Jean-Yves Migeon The newer scripts for Xen read the interface value from the vifname entry in Xenstore, so changing the name is not that critical. But this should be stabilized sooner than later. Personally, I find '_' rather ugly in an interface name... but I am open to suggestions, even fixing rc.d/network if it needs to. One could declare that ifnames must match [a-z][-a-z0-9]*[0-9], and then in /etc/rc.d/network pass them through `tr - _' before evaluating `args=\$ifconfig_$int'. This guarantees that setting ifconfig_ifN in /etc/rc.conf always works, and depends only on agreeing to the ifname policy and ensuring that all the existing ifnames actually follow it. Of course, tr might not be available yet in /etc/rc.d/network, but someone wizardlier (or more patient) with sh than I can probably work around that...
Re: CVS commit: src/sys
Antti, Can you respond, or fix? Thanks. David Holland wrote: > On Tue, Mar 22, 2011 at 04:10:16PM +, Mindaugas Rasiukevicius wrote: > > > src/sys/kern: subr_pool.c vfs_lookup.c > > > src/sys/rump/librump/rumpkern: rump.c > > > > > > Log Message: > > > pnbuf_cache is used all over the place outside of vfs, so put it > > > in one place to avoid many definitions. > > > > Are you going to move random pools to subr_pool.c just because it is > > more convenient for rumpkern? This change breaks logical abstraction > > without real justification. Please revert. > > I agree - almost all users should be using struct pathbuf, which is > isolated within vfs_lookup.c. There are a few outliers at this point, > but they should be tidied up, not catered to. > -- Mindaugas
