Re: CVS commit: [yamt-nfs-mp] src/sys
On Wed, Jun 24, 2009 at 09:24:57PM -0700, Bill Stouder-Studenmund wrote: The fact that the caller has a reference to the vnode at all should really be enough, surely?? do you mean vref? it doesn't prevent revoke(2). thus a filesystem can't access v_data safely. If revoke works by changing fields of the vnode (like v_data) then it is always going to cause grief - since v_data can then disappear during the entry of any VOP call. In a single-threaded, non-smp, kernel the data areas can probably be changed in a consistent manner. With SMP you have to do things differently. So if revoke is making the vnode reference some other (dummy) fs and then releasing all references to the original fs, it just isn't going to work. How does Solaris do this? My understanding is you _don't_ have to lock nodes any where near as often as we do (or did last I looked, which was admittedly a while ago). FWIW SYSV handled controlling terminal 'revoke' by disallowing access to the major/minor in the specfs code. So even if you did another open() you couldn't access the device that had been your ctty. (Which was rather fun when the ctty was a clone device from the network stack, and the program was a network daemon.) David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/external/ibm-public
On Tue, Jun 23, 2009 at 06:02:04PM -0400, Perry E. Metzger wrote: Matthias Scheler t...@netbsd.org writes: Log Message: Add makefile framework to build Postfix 2.6.2. Don't turn it on yet as the Postfix 2.6.2 binary doesn't work yet because it cannot find /usr/libexec/postfix/postfix-script. That has to be /etc/postfix/postfix-script (yes, I know, it is unusual, but Wietse had reasons for wanting it that way -- it is partially configuration oriented.) Not any more. Even the Postfix makefiles install it to /usr/libexec now. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/external/ibm-public
On Tue, Jun 23, 2009 at 03:07:05PM +, Christos Zoulas wrote: Shouldn't all the programs go to bin/program instead at the top level? Indeed. I'll fix that later. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/external/ibm-public
On Thu, Jun 25, 2009 at 10:04:01AM -0400, Perry E. Metzger wrote: Ah, well, if that has changed, then clearly it should be left in the new setup. That does leave the question of whether we should obsolete the /etc/postfix/postfix-script etc files in the set lists. Yes, we should. And I've already done that. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/external/ibm-public
Matthias Scheler t...@netbsd.org writes: On Thu, Jun 25, 2009 at 10:04:01AM -0400, Perry E. Metzger wrote: Ah, well, if that has changed, then clearly it should be left in the new setup. That does leave the question of whether we should obsolete the /etc/postfix/postfix-script etc files in the set lists. Yes, we should. And I've already done that. Excellent. Oh, and thank you for doing all the work needed to get Postfix up to date -- it is much appreciated! Perry
Re: CVS commit: src/sys
Arnaud Lacombe lacom...@gmail.com writes: On Wed, Jun 24, 2009 at 6:42 AM, Izumi Tsutsuitsut...@ceres.dti.ne.jp wrote: - it's reasonable for me that we should wait at least a week before to consider no response means no objections. FWIW, I'm not sure the policy wait for objection and commit if none is the best to follow. I (personally) prefers the wait for approval and commit one. 90% of the time no one cares enough and since no one is in charge of approving, approval would never come. Perry
Re: CVS commit: src/share/man/man4
On Thu, Jun 25, 2009 at 12:25 PM, Alan Barretta...@cequrux.com wrote: On Wed, 24 Jun 2009, Zafer Aydogan wrote: Log Message: catch spelling error. -accept all sorts of unforseen consequences. +accept all sorts of unforeseen consequences. Changing from British to American spelling is OK, I suppose, but please don't use log messages that imply that the British spelling was incorrect. (Similarly for supercede/supersede.) --apb (Alan Barrett) It has nothing whatsoever to do with American English.
Re: CVS commit: src/sys
lacom...@gmail.com wrote: On Wed, Jun 24, 2009 at 6:42 AM, Izumi Tsutsuitsut...@ceres.dti.ne.jp wrote: - it's reasonable for me that we should wait at least a week before to consider no response means no objections. FWIW, I'm not sure the policy wait for objection and commit if none is the best to follow. I (personally) prefers the wait for approval and commit one. We already have some guidelines: http://www.NetBSD.org/developers/commit-guidelines.html 4. The more intrusive your changes are the higher is the level of required prior approval. * Obvious fixes can be committed without any prior discussion or review. (The definition of obvious in the GCC Project is: could not possibly cause anyone to object. We adopt this definition here) * All other (i. e. non-obvious) fixes should have a review. * Implementing (significant) new features requires a prior discussion on an appropriate technical mailing list. * Changing existing interfaces in libraries or in the kernel requires prior approval by Core. But there is no explicit definition about responsible persons who should respond each call for review in the middle two cases. We are volunteered project[TM] so all reviews can't be done with timely manner, unfortunately. In some case, it took more than a year to get looks good comment. Is it still reasonable and the best for you? In my opinion, if one's changes can safely be reverted later (i.e. adding a new driver, or no public API changes, etc.) the policy approved by no objection may be acceptable, and one week seems reasonable compromise for me in that case because too long priod could spoil developer's motivations. (approvals in private discussion without authorized persons in the area could be more problematic..) --- Izumi Tsutsui
Re: CVS commit: src/usr.bin/unzip
On Thu, Jun 25, 2009 at 04:48:32PM -0400, Perry E. Metzger wrote: Log Message: Add work-in-progress unzip(1) frontend for libarchive. Derived from FreeBSD's unzip. Very cool -- presumably we should also grow a zip as well, for completeness. I don't think so. The next libarchive update will bring support for zip writing, so hoking up bsdtar would give that. The main reason for unzip(1) is to be a drop-in replacement for Infozip's unzip. Quite a bit of software depends on that. Joerg
Re: CVS commit: src/lib/libiscsi
On Thu, Jun 25, 2009 at 08:47:45PM +, David Young wrote: Module Name: src Committed By: dyoung Date: Thu Jun 25 20:47:45 UTC 2009 Modified Files: src/lib/libiscsi: Makefile Log Message: Update the path to the iSCSI sources, which have moved to external/bsd/iscsi/dist/ from dist/iscsi/. I think this change is unnecessary. libiscsi is now built via the makefile in src/external/bsd/iscsi/lib. Kind regards -- Matthias Scheler http://zhadum.org.uk/
