Re: CVS commit: src/sys/opencrypto

2014-01-24 Thread Paul Goyette
On Fri, 24 Jan 2014, Taylor R Campbell wrote: Shouldn't devsw_detach or config_fini_component handle this? Why does the crypto device need special reference counting that other devices don't? The crypto device isn't special in this regard. Pretty much all device driver modules need this sor

Re: CVS commit: src/sys/opencrypto

2014-01-24 Thread Taylor R Campbell
Date: Fri, 24 Jan 2014 17:35:41 + (UTC) From: chris...@astron.com (Christos Zoulas) In article <7458.1390534...@splode.eterna.com.au>, matthew green wrote: > >> Log Message: >> XXX Also note that there is still a small window where the ref-count can >> XXX be decremen

Re: CVS commit: src/sys/opencrypto

2014-01-24 Thread Paul Goyette
Some modules get auto-loaded by the syscall mechanism. We already have a mechanism to determine if any lwp's are currently executing these syscalls, and if yes we prevent auto-unload. For device-driver modules, there is currently no equivalent mechanism. They get auto-loaded from code in spec

Re: CVS commit: src/sys/opencrypto

2014-01-24 Thread Christos Zoulas
In article <7458.1390534...@splode.eterna.com.au>, matthew green wrote: > >> Log Message: >> Implement in-module ref-counting, and do not allow auto-unload if there >> are existing references. >> >> Note that manual unloading is not prevented. >> >> OK christos@ >> >> XXX Also note that there

Re: CVS commit: src/share/mk

2014-01-24 Thread Greg Troxel
chris...@zoulas.com (Christos Zoulas) writes: > On Jan 22, 7:29am, m...@3am-software.com (Matt Thomas) wrote: > -- Subject: Re: CVS commit: src/share/mk > > | I always wondered why we don't use ln -sf=20 > | and avoid the race. > > That does not work because if the destnation is a directory it w

Re: CVS commit: src/distrib/vax/ramdisk

2014-01-24 Thread Matt Thomas
On Jan 24, 2014, at 4:19 AM, Martin Husemann wrote: > Module Name: src > Committed By: martin > Date: Fri Jan 24 12:19:10 UTC 2014 > > Modified Files: > src/distrib/vax/ramdisk: Makefile > > Log Message: > Slightly bump ramdisk size, so the content fits even when compiled with >

Re: CVS commit: src/share/mk

2014-01-24 Thread Izumi Tsutsui
> You could install them all into /usr/include/arch and make all the > machine/*.h files look like: > > #include "arch/" # MACHINE # "/foo.h" As mrg@ wrote, kernel (and all standalone) builds should not require installed DESTDIR. If we install them into OBJDIR dynamically, I guess we will get a

Re: CVS commit: src/share/mk

2014-01-24 Thread Warner Losh
On Jan 24, 2014, at 2:16 AM, Izumi Tsutsui wrote: >> Sorry that I was lost, but I still believe that >> creating-directories-as-make-target is to avoid. > > Do you have any suggestion without boring work to rename all > #include lines and expand the "machine" path > in MI files to ${MACHINE}/in

Re: CVS commit: src/share/mk

2014-01-24 Thread Matt Thomas
On Jan 24, 2014, at 1:16 AM, Izumi Tsutsui wrote: > Do you have any suggestion without boring work to rename all > #include lines and expand the "machine" path > in MI files to ${MACHINE}/include? I wish that cc/clang supported -isystem:NAME PATH and iquote:NAME PATH which would look starting

Re: CVS commit: src/distrib/sets

2014-01-24 Thread Alan Barrett
On Fri, 24 Jan 2014, Masao Uebayashi wrote: I agree that in an ideal reproducible world timestamp (== physical time and its order) has no value. But it is useful to detect "unnecessary rebuild" - reproducible but built repeatedly & unnecessarily. I see some value in it. You could extract that

Re: CVS commit: src/share/mk

2014-01-24 Thread Izumi Tsutsui
> Sorry that I was lost, but I still believe that > creating-directories-as-make-target is to avoid. Do you have any suggestion without boring work to rename all #include lines and expand the "machine" path in MI files to ${MACHINE}/include? Creating symlinks for stand programs has been annoying