NFS Locking Problems (Was: Re: I'm impressed, but ...)
On Saturday 07 December 2002 05:40 pm, Philip Paeps wrote: On 2002-12-07 23:10:18 (+0100), Cliff Sarginson [EMAIL PROTECTED] wrote: On Sat, Dec 07, 2002 at 08:41:35PM +0100, Philip Paeps wrote: On 2002-11-25 01:49:34 (+0100), Philip Paeps [EMAIL PROTECTED] wrote: Perhaps someone can make sense of this? I'm happy I can read my mail now, without having to kick the power button every so often, but I'd prefer to store my mail here and have the mailserver write over NFS. (Mainly for speed reasons). I suspect file locks across NFS as a possible source of this kind of problem. Locking is always a problem over NFS :-/ It's one of the reasons I'm using maildirs instead of normal happy mboxes. You could use IMAP instead, allowing you to read and sort your mail from anywhere. Mutt is capable of IMAP, no? Theoretically - correct me if I'm wrong - file locks shouldn't matter with maildirs as once a file is written, there's not much chance of it having to be written again, let alone by more than one process? This is up to the processes that have opened the files. File locks over NFS are obtained by userland programs via the fcntl(2) system call, and it's quite likely (and desired, in fact) that mutt is obtaining, at the least, read locks on the files that it has opened. How would one verify that NFS locking is causing pain? There's some NFS debugging stuff in NOTES... I'm willing to try anything to help fix this :-) A pair of simple test programs works well. One file creates a file, opens it, and locks it. The other program attempts to obtain either conflicting (e.g., try to grab a write-lock while the other process has a read-lock) or non-conflicting locks (try to grab a read-lock while the other process has a read-lock). It is best to run the programs on different hosts, against the same NFS filesystem. I've discovered that fcntl(2) on 4.x systems misbehaves in that the client host keeps track of the locks, so that different programs on the same client host (say, host A) honor the locks, but the lock is not propagated to the NFS server; therefore, processes on other hosts are not restrained by the locks that have been acquired by processes on host A. I have not tried these tests on current. To be fair, I only recently read (here) that rpc.lockd has to run on the client side as well as on the server side, and I have not yet repeated my tests. That's on my List of Things to Do RSN. -- Chris BeHanna http://www.pennasoft.com Principal Consultant PennaSoft Corporation [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: policy on GPL'd drivers?
On Tuesday 27 May 2003 08:43, David Leimbach wrote: On Tuesday, May 27, 2003, at 07:36 AM, Wilko Bulte wrote: On Tue, May 27, 2003 at 02:35:41PM +0200, Stijn Hoop wrote: On Tue, May 27, 2003 at 07:28:29AM -0500, David Leimbach wrote: I have the GPLd source to the nforce drivers for Linux to support the nVidia nforce and nforce2 drivers in the kernel. To port these to FreeBSD would be an interesting task [if it hasn't already been done] and I have been looking for an excuse to get down and dirty with FBSD. [Yes... talk is cheap... just do it... Nike-a-go-go etc etc... :)] What is the policy on drivers that are clearly going to have to be GPLd by the viral clause since I am referencing a GPL driver to do the porting work myself? Are these allowed in the kernel? Yes, see for example the GPL_ed floating point emulator. However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Get someone to pair with you and do a clean-room implementation. One of you studies the GPL'd driver and writes a specification. The other writes a BSD-licensed driver from the specification, BUT NEVER ONCE LOOKS AT THE GPL'D SOURCE. Virus removed. -- Chris BeHanna http://www.pennasoft.com Principal Consultant PennaSoft Corporation [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: We have ath, now what about Broadcom?
On Wed, 23 Jul 2003, Kevin Oberman wrote: From: Matthew Emmerton [EMAIL PROTECTED] Date: Wed, 23 Jul 2003 18:21:23 -0400 The folks at Broadcom have not been willing to release any information on their 800.11g chips for fear of violating FCC regs. The required NDA would prohibit the release of the source. You can program both the transmit power and frequency if you have this. (I make no claim as to whether their concerns have any validity.) For that reason there has been no open-source support for these chips. Why would Broadcom be scared? Obviously it's the _driver_ that controls the power/freq output of the chip, so the responsibility of staying within FCC regs is that of the driver authors. Of course, the no warranty aspects of open source drivers turns a blind eye to liability, but would things really come back to Broadcom? The logic is simple. the FCC hold the manufacturer responsible for improper RF from any product. The Broadcom chip makes it easy to generate illegal RF if you know where to poke. Can't they just redact that information from the spec.? -- Chris BeHanna Software Engineer (Remove bogus before responding.) [EMAIL PROTECTED] I was raised by a pack of wild corn dogs. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Seat-belt for source upgrades from stable to current
On Friday 31 January 2003 00:58, David Schultz wrote:
Thus spake Christopher Vance [EMAIL PROTECTED]:
On Thu, Jan 30, 2003 at 09:07:11PM -0800, Steve Kargl wrote:
: On Thu, Jan 30, 2003 at 08:05:06PM -0800, David Schultz wrote:
: Thus spake Steve Kargl [EMAIL PROTECTED]:
: On Thu, Jan 30, 2003 at 07:09:16PM -0800, David Schultz wrote:
:OT: Is there a good way to get the CVS metadata in /usr/src and
:/usr/ports without transferring the entire source tree over the
:network? On some machines, I'd like to be able to do a CVS
:{diff,log,update} now and then, but I don't have the disk space
:for the entire repository. I usually end up blowing away
:/usr/src and fetching a new copy from a CVS server, but I'm sure
:this is far from ideal for the people who pay for that server's
:bandwidth.
:
: anoncvs
:
: See the handbook for info.
:
: That's a great answer...to a different question. ;-)
:
: It's the correct answer. I assumed that you knew
: how to use cvs.
[...Chris Vance explains why cvsup is all he needs...]
Perhaps you can explain why cvsup is the wrong answer...
I don't know about Steve, but cvsup is the wrong answer for me
because it's a mirroring tool and not a version control tool.
Among the things I would like to do are:
- Update to a specific version of a specific file from the
repository.
Anoncvs will let you do this.
cvs -D $ANONCVSROOT co -r$REVISION -d $WHERE_I_WANT_IT $WHERE_IT_IS
- Generate a diff between two revisions in the repository,
You can use CVSweb for this quite ably. That's not a great
solution for generating patches, but it's decent enough for trolling
around the repo.
or between a version in the repository and some local
patches of my own.
For that, you'd most easily check out the directory in which the
files in question live, copy your local version into it, and use cvs
diff. The repo information is cached in the CVS/ subdir, so it all
works nicely:
cvs diff -u myfile.c
- View logs for particular files.
CVSweb is your friend. http://cvsweb.freebsd.org
[...old machine, limited disk space, mirroring the entire repo
infeasible...]
Transferring the entire source tree over the network via anoncvs is
suboptimal when all I really want is a few kilobytes of 'CVS'
subdirectories. But I guess it will have to do for now.
It's unnecessary. Use the -d option to cvs co to check out the
subdirectories into a convenient place.
[1] When the system is an aging dual PPro or 200MHz Alpha using
SCSI, buying new drives is not practical.
If you can afford it, retire the box to mail/firewall duty. A
bare-bones 2.4GHz P4 system can be had for $500US if you shop hard.
--
Chris BeHanna http://www.pennasoft.com
Principal Consultant
PennaSoft Corporation
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Cross-build ports from stable box?
The hard drive on my laptop died, which I took as a sign to bite the bullet and install -current (and pick up cardbus support for my spiffy new wireless card in the process). The laptop is a PIII-500. My workstation is a 1.3GHz T-bird, but it needs to stay -stable, as it's the home office workhorse (fileserver, SAMBA, print spooler, mail server, and firewall). Is there any way that I can build ports on the fast -STABLE box using a -CURRENT cross-environment? Thanks, -- Chris BeHanna http://www.pennasoft.com Principal Consultant PennaSoft Corporation [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-STABLE Roadmap
On Thursday 13 February 2003 11:28 pm, Sam Leffler wrote: At 4:36 PM -0800 2003/02/13, Scott Long wrote: - the classic 'worldstone' - webstone - /usr/ports/www/webstone - Fstress - http://www.cs.duke.edu/ari/fstress - ApacheBench - /usr/ports/www/p5-ApacheBench - netperf - /usr/ports/benchmarks/netperf Are there any other benchmarks that are being considered? What about LMBench? RawIO? Bonnie++? Other disk benchmarks? Do we care about application-layer benchmarks for other protocols, such as SMTP, POP3, or IMAP? Just curious. Thanks! This can quickly turn into a bikeshed, but suggest ones. We're looking for good benchmarks. lmbench, rawio, and bonniee are rather micro in nature (not bad, just limited in their usefulness). SpecFS (NFS ops/sec benchmark) -- Chris BeHanna http://www.pennasoft.com Principal Consultant PennaSoft Corporation [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Local repo: Perforce/CVS integration
For those of you doing development with Perforce, could you talk a little bit about how this is done? Do you do a cvsup nightly and import that on a vendor branch, then integrate it into your working tree? (That sounds like it would work.) Do you use cvs2p4? How about going in the other direction (from your local branches back to the trunk?) I'm reasonably well-versed in both CVS and Perforce, and Perforce just does merging *so* much better than CVS that'd I'd rather use it, but I'd also rather crib from someone who has a process that's working, rather than roll my own. Thanks, -- Chris BeHanna http://www.pennasoft.com Principal Consultant PennaSoft Corporation [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
On Sunday 02 March 2003 18:08, Jens Rehsack wrote: Now, that OpenWatcom is released, the FreeBSd port of it should follow. And maybe someone will try to compile the kernel and world with it. If that would work, this would be great, because the watcom compiler generates much better code than gcc does, even than gcc -O3 (and all known optimizations on). Is someone working on such a port? Will a bootstrap port to build it with GCC be part of the work? -- Chris BeHanna http://www.pennasoft.com Principal Consultant PennaSoft Corporation [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
On Tue, 23 Apr 2002, Dave Hayes wrote: Terry Lambert (who fits my arbitrary definition of a good cynic) writes: It's a hazard of Open Source projects, in general, that there are so many people hacking on whatever they think is cool that nothing ever really gets built to a long term design plan that's stable enough that a book stands a chance of having a 1 year lifetime. I could not help but notice your multiple attempts at expresing this particular concept often, that is...an implied necessity of a book that explains what's going on under the kernel hood. I agree that such a book would rapidly be out of date, but I also see the necessity thereof. So, it's time to question the assumption that the information you want available should be in a book. Many websites have annotation as a form of ad-hoc documentation (e.g. php.net). Why not have someone take a crack at documenting the FreeBSD kernel, and perhaps use some annotation feature to create a living document which (hopefully) comes close to describing the kernel architechture? If you want to track a moving target, perhaps you need to use a moving track? doxygen is *wonderful* for this for large C++ projects: it's able to draw you inheritance graphs and collaboration diagrams, as well as generate pretty, nicely formatted HTML containing API descriptions generated from javadoc-like comments in header files. I've never tried it on straight C. I suppose it is possible, but given the lack of inheritance, collaboration diagrams are going to be very messy. Still and all, it might be a very useful thing. If not doxygen, then perhaps some way to run the headers through jade/sgmlformat, with docbook-style SGML embedded in comments in header files describing kernel API calls and their parameters, with all typedef'd datatypes appropriately cross-linked. As a hack, one could even gulp embed POD within comments and run perldoc on everything. This could be done nightly or twice daily, with updates appearing live at freebsd.org. HTML versions of man pages with crosslinks go part of the way; what I'm thinking about (if any of you have used doxygen you'll know where I'm going) is a bit more comprehensive, with links to the actual header file from which the documentation was generated, so that the reader can see the declaration in its native context (with the doxygen or docbook comments stripped out for clarity). This still wouldn't address the need for some kind of overall architectural document, as well as the difficulty of keeping it up-to-date, but it would be of tremendous help to everyone working on the project. *If* developers can get used to updating the in-comment documentation whenever they make changes, then this reference would automatically be kept up-to-date. -- Chris BeHanna Software Engineer (Remove bogus before responding.) [EMAIL PROTECTED] I was raised by a pack of wild corn dogs. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
