Re: FreeBSD or other BSD for no-MMU ARM processor ?
On Tuesday 15 June 2004 11:50, Gary Corcoran wrote: Wes Peters wrote: On Monday 14 June 2004 12:32 pm, Gary Corcoran wrote: Does anyone know if there is a port of FreeBSD, or any of the other BSDs (e.g. NetBSD) for that matter, which will run on an ARM processor which does NOT have an MMU (Memory Management Unit)? No, and there's not likely to be one anytime soon (unless you do it). Thanks for the definitive reply. We don't have enough resources for our work as it is, so no, we're not going to do it - we need something already available. NetBSD has ports for a couple of ARM920T designs, which do have an MMU. (I think they've recently popped a port for the Cogent CSB337, based on the Atmel chip.) The general feeling seems to be that without an MMU and the added features of memory protection it provides, the heavyweight process-oriented UNIX kernel doesn't really offer much advantage over a lighter-weight solution like RTEMS or eCos. The uClinux gang disagrees with this assessment, obviously, so you do have that choice as well. Thanks for the pointers. My boss (and our customer) has mentioned eCos, so we'll be looking into that. RTEMS I hadn't heard of - I'll have to check into that too. But since I like, and am somewhat familiar with, *BSD, I thought I'd ask if that might be an option... You'll like RTEMS, it's the BSD of RTOSes. The community support is great and Joel Sherrill, the head honcho there, is very responsive to customer input. OARCorp offers all sorts of contract help as well. In case you haven't found it (not likely), see: http://www.oarcorp.com/ eCos is also very good, and perhaps a bit more polished due to it's Cygnus Support and Red Hat parentage. I'm noticing more and more eval boards and development systems for 32-bit embedded cpus that come with eCos. If you're looking for a low-cost ARM7 solution, the Atmel EVB40 boards might be of interest. DigiKey carries the EVB40A, with a 66MHz ARM7TDMI chip (Ateml AT91R40008), which is directly supported by eCos, see: http://ecos.sourceware.org/ecos/boards/at91eb40a.html Both eCos and RTEMS use GCC cross-compilers for devlopment, so you'll be able to stick with FreeBSD as your workstation platform. In fact, the coupling between FreeBSD and RTEMS is very close; see /usr/ports/devel/ on your favorite FreeBSD system, where you will find: arm-rtems-binutils i386--g77 i960--gcc m68k--gdb mips--objc powerpc- sh- sparc- Installing the arm binutils (linker, assembler, etc), gcc and gdb ports will give you a complete RTEMS-arm development environment on your FreeBSD system with a minimum of fuss and bother. The other two ports will provide you with a Fortran-77 and Objective-C compiler, if you need those. Am I making your choice any easier? ;^) Please let me know how your project goes. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd asm
On Monday 14 June 2004 07:04, Peter Pentchev wrote: On Mon, Jun 14, 2004 at 01:59:11PM +0200, Jos? Nicol?s Castellano wrote: Hello to all, I'm proud to join this mailing, having posibilities to learn some new features of freebsd system. I have to mention i did some tests in asm from freebsd-devel and i get surprised, look at this: [demon]~$ uname -a FreeBSD demon.noconname.org 5.2.1-RELEASE-p4 FreeBSD 5.2.1-RELEASE-p4 #0: Tue Apr 6 19:35:49 CEST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NocONName i386 [demon]~$ cat hello.asm %include 'system.inc' section .data holadb 'Hola', 0Ah hbytes equ $-hola section .text global _start _start: pushdword hbytes pushdword hola pushdword stdout sys.write pushdword 0 sys.exit [demon]~$ nasm -f elf hello.asm hello.asm:1: fatal: unable to open include file `system.inc' ?Where is that file?... the -current port of nasm is incomplete ? I assume you are referring to the system.inc file mentioned in http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x86- portable-code.html If so, note that this page says that you need to create this file yourself, it is neither part of nasm nor part of the standard FreeBSD distribution :) See the last paragraph on the page - Go ahead, enter it into your editor and save it as system.inc. :) Gee, maybe somebody should do that and submit the file to krion@ for inclusion in the port patches. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD or other BSD for no-MMU ARM processor ?
On Monday 14 June 2004 12:32 pm, Gary Corcoran wrote: Does anyone know if there is a port of FreeBSD, or any of the other BSDs (e.g. NetBSD) for that matter, which will run on an ARM processor which does NOT have an MMU (Memory Management Unit)? No, and there's not likely to be one anytime soon (unless you do it). NetBSD has ports for a couple of ARM920T designs, which do have an MMU. (I think they've recently popped a port for the Cogent CSB337, based on the Atmel chip.) The general feeling seems to be that without an MMU and the added features of memory protection it provides, the heavyweight process-oriented UNIX kernel doesn't really offer much advantage over a lighter-weight solution like RTEMS or eCos. The uClinux gang disagrees with this assessment, obviously, so you do have that choice as well. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! KSE needs more attention
On Sunday 06 June 2004 16:49, Scott Long wrote: Garance A Drosihn wrote: At 3:46 PM -0600 6/6/04, Scott Long wrote: At this point, I'm going to advocate that Alpha be dropped from Tier-1 status for 5.3 and 5-STABLE and no longer be a blocking item for releases. ... As I said back then, demotion is not a terminal condition, and I would be thrilled if someone comes forward in the future and brings the platform back up to date. I think you have to officially demote it, with emphasis on the point that demotion is not a terminal condition. Then, if some developer(s) show up and implement all the missing pieces, we can happily announce it back in tier 1. But for now, say that it *IS* demoted. Not that you're advocating that we think about maybe demoting it in the future unless someone offers to start looking into the missing pieces. At the moment, it probably also makes sense to demote sparc64, even though I own one of those. Not that we have anything against it, but as a practical matter we haven't hit critical mass on it just yet. Since I am interested in sparc64, I can take that as a goal to help make it a tier-1 platform by 5.4-release... Ok, thanks for all of the input. I'm going to wait a few more days for anyone else to chime in and then discuss it with re@ and [EMAIL PROTECTED] We'll likely have a formal announcement in a week. Back to the topic at hand, who is looking that the other KSE issues? The tierness of a particular platform wasn't all that important as long as FreeBSD 5 remained a development branch, but with 5-STABLE rapidly approaching, it will become much more important. When we first documented the tier approach, we selected sparc64 as the reference 64-bit platform, because it was at that time the most viable and the most actively developed platform. This was shortly before the Athlon64 release, which has turned into an avalanche. None of the current tiers are set in stone, in fact, they're not really very firm at all. The stability and completeness of each will have to be evaluated as the 5.3 release becomes real and adjustments made. It wouldn't surprise me to see a new 64-bit reference platform chosen; the momentum in that arena has definitely shifted. As an aside, I would sadden me greatly to see sparc64 or alpha abandoned. Even sadder (to me) is how little I've been able to contribute to either. I don't have time to bring my sparc skills up to working on FreeBSD internals and I'm not likely to suddenly grow more time soon. I do have an Ultra 5 workstation that is free to any developer in North America who will use it to further FreeBSD development. I'll contact dlo@ with details. sparc64 and alpha need a few champions. Without them, these ports will quickly be relegated to the bit-bucket. At any rate, FreeBSD will continue to move, in a direction we've decided to call forward. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS-UP] mbuma is in the tree
On Wednesday 02 June 2004 07:12, Bosko Milekic wrote: If you read the paper on mbuma, you'll notice that I point out that it would be worth investigating whether, in scenarios where an m_tag is ALWAYS required per packet (e.g., MAC), providing a secondary zone with pre-allocated m_tags for packet headers might be worth it. Prior to this work, however, I suggest we investigate the possibility of using smaller mini-mbufs whenever clusters are used so that space wastage is reduced. It may also be worthwhile investigating eliminating clusters entirely. This is the point Poul-Henning, Robert and I were trying to make at the end of you talk at BSDCan. Since the double allocation required to create a cluster makes the locking (and cache slushing) requirements go up, it is probably worthwhile to investigate if raising the nominal mbuf size doesn't end up decreasing overall memory pressure. If you allocate more memory, but the allocation takes less time due to the simpler locking, you may actually decrease the total memory need. This is worth investigating partly because it is such a simple change. I propose investigating with mbuf size of 2K, large enough to fit standard ethernet frames, and a cluster size of 8K, which means a cluster mbuf is large enough to hold a 9K jumbo frame. Now that you've got mbuma in the tree, I can test this for you, unless this proposal catches your interest enough to give it a try. I'll see if I can't get a couple of our beefier machines at work updated to -CURRENT in the next week. Thanks for the good work. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vendors of multi-port PCI ethernet cards?
On Monday 26 April 2004 12:56, Steven Hartland wrote: Intel still do iirc. - Original Message - From: Stephen Hocking Does anyone know where I can lay my hands on one of those 4 port ethernet cards that used to be around a while back? http://www.zipzoomfly.com/jsp/ProductDetail.jsp?ProductCode=251442 They didn't show 10/100 cards, but they're still around. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a serious error in sched_ule.c?
On Tue, 09 Mar 2004 21:29:54 +0100 [EMAIL PROTECTED] (Dag-Erling Smørgrav) alleged: Wes Peters [EMAIL PROTECTED] writes: One of the classic trade-offs in making a 'server' vs. 'workstation' operating system. Workstations require a strong preference for interactive over background tasks so the interactive tasks will remain responsive, especially in terms of heavily event-driven tasks like graphical UIs. For a true server, where interactive tasks are not the norm, this preference may be counter-productive. Umm, remember that interactive here means performs I/O, even if that I/O is a database lookup or a TCP connection. Sigh. Nobody really does compute-bound tasks anymore, do they? I really miss scientific programming. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a serious error in sched_ule.c?
On Mon, 15 Mar 2004 07:42:59 + Colin Percival [EMAIL PROTECTED] alleged: At 07:32 15/03/2004, Dag-Erling Smørgrav wrote: Actually, my wife is a molecular biologist and eats CPU hours with milk and sugar for breakfast. She expressed her satisfaction yesterday at finding out that her latest program only takes four and a half hours per data set. But honey, says I, you have 30,000 data sets! Quoth the love of my life, That's OK, we've got *two* computers. ... and 8 years to waste, apparently. Wowsers. Sounds like they need a cluster. Introduce her to Dillon! ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a serious error in sched_ule.c?
On Tuesday 09 March 2004 08:41 am, Robert Watson wrote: On 9 Mar 2004, Bin Ren wrote: I've been reading sched_ule.c and seem to find a serious error: in 'sched_slice()': * Rationale: * KSEs in interactive ksegs get the minimum slice so that we * quickly notice if it abuses its advantage. . #define SCHED_SLICE_INTERACTIVE (slice_max) (slice_max) for interactive KSEs Either this is a serious mistake or I'm seriously missing sth here. I believe this is a synchronization error in the comment and the code. The code was changed to provide a maximum slice to interactive applications because non-CPU intensive X11 applications will be marked as interactive, but redraws get interrupted in a short slice. When the change went in to increase the time slice I saw an observable improvement in the redraws of X11 apps under load. One of the classic trade-offs in making a 'server' vs. 'workstation' operating system. Workstations require a strong preference for interactive over background tasks so the interactive tasks will remain responsive, especially in terms of heavily event-driven tasks like graphical UIs. For a true server, where interactive tasks are not the norm, this preference may be counter-productive. Is there some way (boot hint?) we could change SCHED_SLICE_INTERACTIVE between slice_max and something approaching slice_min? -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5)
On Monday 16 February 2004 10:11 am, Dag-Erling Smørgrav wrote:
Kris Kennaway [EMAIL PROTECTED] writes:
On Mon, Feb 16, 2004 at 03:52:16AM -0800, Wes Peters wrote:
Should I commit this?
What effect does it have on non-i386 architectures?
It can't possibly hurt. If the stack is already aligned on a better
boundary (64 or 128 bytes), it is also aligned on a 32-byte boundary
since 64 and 128 are multiples of 32, and the patch is a no-op. If
only a 16-byte alignment is required, a 32-byte alignment wastes a
small amount of memory but does not hurt performance. I believe that
less-than-16 (and possibly even less-than-32) alignment is pessimal on
all platforms we support.
I'm building world on my sparc64 just to be sure. Sorry, I didn't get to
work on this at all last night, but I should be able to post conclusive
results tonight, I just have to get through the rather long buildworld
while I'm at the office today.
Thank ${DEITY} for cheap, fast AMD machines. ;^)
--
Where am I, and what am I doing in this handbasket?
Wes Peters [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5)
On Sunday 15 February 2004 12:46, Dag-Erling Smørgrav wrote: Alexandr Kovalenko [EMAIL PROTECTED] writes: Could you please explain me this? Result is fully reproduceable. Please note, that the only difference is the output file name. Even resulting files match bit-to-bit. [...] Definitely some kind of alignment problem, but it only shows up at some optimization levels and not others. I've tested the patch Dan mentioned before and the results were astonishing. Running the flops.c 1.2 program in a loop, lengthening the environment string by one byte each time, I get 8 successive runs of fast, then 8 successive runs of slow, where fast and slow vary between 650 and 990 mflops. With the patch, the performance is always 990, within a few percent. Should I commit this? RCS file: /big/ncvs/src/sys/kern/kern_exec.c,v retrieving revision 1.235 diff -u -w -r1.235 kern_exec.c --- kern_exec.c 28 Dec 2003 04:37:59 - 1.235 +++ kern_exec.c 11 Feb 2004 16:47:28 - @@ -1014,6 +1014,15 @@ */ vectp = (char **)(destp - (imgp-argc + imgp-envc + 2) * sizeof(char *)); + + /* +* Align stack to a multiple of 0x20. +* XXX vectp has the wrong type; we usually want a vm_offset_t; +* the suword() family takes a void *, but should take a vm_offset_t. +* XXX should align stack for signals too. +* XXX should do this more machine/compiler-independently. +*/ + vectp = (char **)(((vm_offset_t)vectp ~(vm_offset_t)0x1F) - 4); /* * vectp also becomes our initial stack base -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED]http://softweyr.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5)
On Monday 09 February 2004 13:20, Juan Tumani wrote: I have an Intel D845GE m/b w/ a P4 1.7 CPU and I have the box setup to dual boot to either 4.9 or 5.2. Both OS are right off the latest posted iso CD image, i.e., no updates, no kernel tweaks, everything vanilla right out of the box. I compiled flops.c on both 4.9 and 5.2 and the 5.2 performance is less than half that of 4.9: 760 MFLOPS on 4.9 v/s 340 MFLOPS on 5.2. I tried turning off the SMP and other kernel tweaks and no improvement in 5.2. I then downloaded and installed gcc295 on the 5.2 machine and that fixed the problem. So now all I have to do is figure out the gcc 3.3.3 switches to make it run like gcc 2.9.5 or figure out how to rebuild 5.2 w/ gcc 2.9.5 :-). I'm not sure that kernel tweaks are going to make much difference on a single-threaded floating point benchmark. Compiler optimizations sure do, though. (Note: I couldn't find version 1.2 of flops.c, so this is based on version 2.0.) On a 2.0GHz P4, I see: [EMAIL PROTECTED] cc -o flops -O -DUNIX flops.c flops.c: In function `main': flops.c:174: warning: return type of `main' is not `int' [EMAIL PROTECTED] ./flops FLOPS C Program (Double Precision), V2.0 18 Dec 1992 Module ErrorRunTime MFLOPS (usec) 1 4.0146e-13 0.0301465.4460 2 -1.4166e-13 0.0619113.0049 3 4.7184e-14 0.0365465.3564 4 -1.2557e-13 0.0327458.7438 5 -1.3800e-13 0.0482601.5539 6 3.2380e-13 0.0470617.2479 7 -8.4583e-11 0.1692 70.9097 8 3.4867e-13 0.0510587.8699 Iterations = 51200 NullTime (usec) = 0.0008 MFLOPS(1) = 150.1795 MFLOPS(2) = 174.4286 MFLOPS(3) = 352.0107 MFLOPS(4) = 544.1166 [EMAIL PROTECTED] cc -o flops3 -O3 -mcpu=pentium4 -msse2 -DUNIX flops.c flops.c: In function `main': flops.c:174: warning: return type of `main' is not `int' [EMAIL PROTECTED] ./flops3 FLOPS C Program (Double Precision), V2.0 18 Dec 1992 Module ErrorRunTime MFLOPS (usec) 1 4.0146e-13 0.0202692.2121 2 -1.4166e-13 0.0199351.9018 3 4.7184e-14 0.0251676.9230 4 -1.2557e-13 0.0235637.0627 5 -1.3800e-13 0.0446650.2407 6 3.2380e-13 0.0436665.0579 7 -8.4583e-11 0.0567211.8219 8 3.4867e-13 0.0436687.5249 Iterations = 51200 NullTime (usec) = 0.0006 MFLOPS(1) = 417.4252 MFLOPS(2) = 396.1492 MFLOPS(3) = 567.2668 MFLOPS(4) = 669.6139 Pretty good increases across the board. Slightly off-topic, the same test on my Athlon XP 2000+ at home yields: -bash-2.05b$ cc -o flops3 -O3 -mcpu=athlon-xp -msse2 -DUNIX flops.c flops.c: In function `main': flops.c:174: warning: return type of `main' is not `int' -bash-2.05b$ ./flops3 FLOPS C Program (Double Precision), V2.0 18 Dec 1992 Module ErrorRunTime MFLOPS (usec) Illegal instruction (core dumped) Oh, duh, Athlon doesn't have SSE2. Try again: -bash-2.05b$ cc -o flops3 -O3 -mcpu=athlon-xp -msse -DUNIX flops.c flops.c: In function `main': flops.c:174: warning: return type of `main' is not `int' -bash-2.05b$ ./flops3 FLOPS C Program (Double Precision), V2.0 18 Dec 1992 Module ErrorRunTime MFLOPS (usec) 1 4.0146e-13 0.0145965.8007 2 -1.4166e-13 0.0108649.9764 3 4.7184e-14 0.0146 1162.1140 4 -1.2557e-13 0.0120 1250.0460 5 -1.3800e-13 0.0259 1118.8725 6 3.2380e-13 0.0209 1390.5740 7 -8.4583e-11 0.0310387.7082 8 3.4867e-13 0.0277 1082.6515 Iterations = 51200 NullTime (usec) = 0.0012 MFLOPS(1) = 759.3833 MFLOPS(2) = 717.9906 MFLOPS(3) = 996.1904 MFLOPS(4) = 1210.2268 Wowsers. Looks like if you're doing floating point, at least floating point loops that fit in the Athlon cache, you're a lot better off with Athlon than P4. You might want to try -funroll-loops, but that's enough effort for a decade-old benchmark. For me, at least. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Monday 12 January 2004 07:22 am, Brooks Davis wrote: On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote: I don't know the release build process, so I don't know how much effort is neccessary to create such floppies, but the loader seems to have all features needed to use such disks. It sounds like this is definatly a viable option. Now someone needs to see about hacking something like this into the release makefiles. Note that I didn't say it would be a lot of work. ;^) Do we have a volunteer showing up here? -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame and Vinum
On Sunday 11 January 2004 12:36 pm, Scott W wrote: David Gilbert wrote: Poul-Henning == Poul-Henning Kamp [EMAIL PROTECTED] writes: Poul-Henning In message [EMAIL PROTECTED], Poul-Henning Greg 'groggy' Lehey writes: Poul-Henning The reason I say this is that neither of you have the Poul-Henning time needed, and whoever picks up may have ideas, even Poul-Henning necesarry ideas, which would grind your spine seriously. Poul-Henning By letting go, I think you would give vinum a better Poul-Henning chance. In the p4 tree, we can easier add new talent to our developer force and I am pretty sure that some sort of merry band of developers would form around both RF and vinum there. ... now I thought I followed this list relatively well, but can someone point me at what 'p4' is? Dave. p4 = perforce source control. I'd seen the perforce depot somewhere on freebsd's sites, but didn't previous to this discussion understand it's purpose. Someone with more of a clue than I can fill in the blanks, but it seems that the perforce depot is essentially open-access, (unlike needing the commit bit set in FreeBSDs CVS tree), or at least easier to get commit privs assigned, allowing people that are not currently FreeBSD commiters to contribute changes back to the repository In particular, Perforce has a very nice lightweight branching model so it is easy to give someone a Perforce account and a private branch they are allowed to commit to. That's a nice feature for an open source project. ...at some point, presumably, to be rolled back into the main development branch of FreeBSD by integrating back into CVSif a project at some point becomes 'release-worthy.' You do have to be a committer to do this. More info on perforce is available at www.perforce.com . I saw someone mention in this thread not liking perforce, although I'm not sure why- For people with less than stellar net connectivity, cvsup and a local CVS repo are much easier to work with. Perforce was built with a LAN in mind and scales reasonably well to the Internet, but can be painful unless you have relatively low latency and relatively high bandwidth to the server. cvsup updates much faster on slow links, too. A few years ago Perforce was working on a write-through cache so you could have a local duplicate of the server environment, but I haven't seen that work come out of the company. That would've rocked for our development model. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: binary files in src tree
On Monday 12 January 2004 05:53 am, Jacques A. Vidrine wrote: On Sun, Jan 11, 2004 at 05:48:19PM +, Colin Percival wrote: While browsing the FreeBSD src tree, I came across a number of binary files (listed below); the regression tests are perhaps understandable, but shouldn't the rest of these files be uuencoded? tools/regression/usr.bin/uudecode/regress.out tools/regression/usr.bin/uuencode/regress.in Those that are found in src/contrib/ and src/crypto/, at least, should not be touched. However, it seems likely that some or all of them in that case are not actually used in FreeBSD. Those that are not used should perhaps be removed. I'll put reviewing the src/crypto/openssl/ cases on my todo list for the next import. The two binary files used to test uuencode/uudecode should NOT be uuencoded, for obvious reasons. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Sunday 11 January 2004 12:27 am, Paul Robinson wrote: Perhaps I'm missing something, and I can see why abondoning the current method in 5-6 years would be reasonable, but I don't see the immediate advantage of making the change right now. So you'll be signing up to do the floppy release engineering, and to modify the kernel so it can load the boot-device modules dynamically. That's great news! And I have to say, I agree. If abondoning floppies is part of some well-thought-out and well-planned package management strategy, I'm all for it. Otherwise, let sleeping dogs lie? The dog isn't sleeping, it's dead. Like everything else in FreeBSD, it takes time. If someone wants to donate that time, it'll continue getting done, otherwise it'll fall by the wayside. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Friday 09 January 2004 09:34 pm, Marc G. Fournier wrote: On Thu, 8 Jan 2004, Michel TALON wrote: Sincerely FreeBSD developers have more important tasks than spending hours to fit an installable system on floppies. When FreeBSD used one floppy, it was tolerable to do floppy installs. With 2 or 3 floppies it is awfully slow, i have done once and will never do it again. I still use floppies to do my installs, and find getting the base system up over FTP to generally take 30minutes *shrug* Faster, IMHO, then downloading the ISO and burning it to a CD .. Faster than loading a single ISO image with only the boot information and sysinstall and booting from that, rather than 3 (or 4 or 5) floppies? A CD-R is cheaper, faster, more reliable, and you don't have to keep feeding them into the machine. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Monday 05 January 2004 11:14 am, Brett Glass wrote: I'd like to see a more open and inclusive form of governance for FreeBSD. The current system of governance has, as its underlying assumption, that the most prolific coders make the best leaders. In my personal experience, this isn't a valid assumption. System administrators and end users have a big stake in FreeBSD, and are just as likely (perhaps more likely) to be good leaders for the project. The current system of governance is open and inclusive of those who have demonstrated the talent, ability, and willingness to be contributors to FreeBSD. The current core team is made up of a mix of big-time coders like Peter and Warner, and small-time coders like myself (now slightly below middle of the pack on commits) and a variety of other skills. I strongly encourage all FreeBSD committers to continuously watch for people who might be good core team members. Watch for leadership, for a sense of fair play, and for the ability to steer FreeBSD, from both technical and organizational viewpoints. Look for someone with 'the big picture,' and a vision of where FreeBSD is headed that you share. Somebody whose viewpoint doesn't extend beyond the virtual memory system, for instance, may be critical to the success of a kernel, but that doesn't necessarily make them the best person to steer a complex product that brings 10,000 applications along with it. We don't appear to have anyone like that on core now, and I doubt we will in the future. Programmers, system administrators, end users, and anyone else who wants to contribute to FreeBSD are welcome to contribute in whatever way they can. Anyone can file a PR about any aspect of the system they find troubling, or delightful, or have a better way of doing. Strike up a relationship with a committer or two (or twenty), let your ability and willingness to work be known, and become a committer too. 400 or so of your peers have already done it. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Tuesday 06 January 2004 09:05 am, Munden, Randall J wrote: Honestly, I picked up the troll thread because I'm curious as to why someone would commit so much time in effort to trolling these lists. In my experience it's a good idea to explore the reasoning behind that type of dedication (faulty or not) for no other reason that discovery. On-the-other-hand some people accuse me of being obsessive about information. /me shrugs People who hate rarely require rational reasons for hating. Attempting to apply logic to that which is not logical is not likely to produce useful results. Which leads me to query, given limited time an resources, what can I do? I've moved many a production server to fBSD over the last 10 or so years -- some of them literally -- by blathering nonstop about the virtues of the OS. So what else is there? Do I need to start writing documentation or publishing and pimping more Howtos on the intarweb? Should I brush up on my C and start patching? Yes, to all of the above. Pick the one(s) you enjoy most, or that you wish to learn most, and dig in. Best of all would be to write or fix some code, or write some articles that get printed on dead trees -- what Brett likes to call 'the mainstream press.' You know, those things the IT management leaves on the floor of the mens room. Frankly, I'd never given thought to providing more effort. The OS has always done it's own advocacy in my experience. Advocacy is important only if you want to conquer the world. Brett apparently does; many of us just want an operating system that meets our needs, and don't particularly care what somebody else uses. IMO, casual 'desktop' or 'laptop' computer users are probably better served by Mac OS X than anything I want to turn FreeBSD into, which is why my 68 year old father is a Mac owner. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Power consumption in desktop computers
On Friday 26 December 2003 05:41 pm, Martin Cracauer wrote: Wes Peters wrote on Fri, Dec 26, 2003 at 08:15:38AM -0800: If you want a desktop machine with low power consumption (and far less cooling fan noise as a bonus) you may want to look into the VIA Epia motherboards and systems. Actually I am posting from one of those - using a tty mailer :-) Kewl. I found that the requirment to run Mozilla Firebird outpaces this CPU. It's really too bad, if it wasn't for that thing I could happily run my old hardware forever. Have you tried Opera? My laptop is a PII-300; Opera 7 runs quite nicely and Firebird takes 3 or 4 minutes to start. There are a few things Opera doesn't do, or doesn't do well, but I usually just avoid those (flash, for instance.) KDE apps also run just fine on this old, slow hardware. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Power consumption in desktop computers
On Thursday 25 December 2003 19:46, Martin Cracauer wrote: Hi, those who followed might have noticed I was shopping for a notebook to replace some of my desktop system. To make it short, the notebook vendors all pissed me off so good that I'm not going to get a notebook (details on request) so I am going for other options. Here is what my powermeter thinks my desktops are using with various options: If you want a desktop machine with low power consumption (and far less cooling fan noise as a bonus) you may want to look into the VIA Epia motherboards and systems. Matt Dillon has posted his results in building workstations (sort of glorified Xterms) using Epia systems and LCD panels. You can read his reivew at: http://apollo.backplane.com/FreeBSD/epia/review.html -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED]http://softweyr.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Does indent(1) have a KNF mode?
On Sunday 07 December 2003 10:25, Steve Kargl wrote: Does indent(1) have a KNF mode? If not, does anyone have/know a set of command line switches that best approximates KNF? No, but it probably should have. Somebody once suggested several years ago the following options gave the closest appromixation of knf: -nbad -nbap -bbb -nbc -br -brs -c33 -cd33 -cdb -ce -ci4 -cli0 -di16 -fc1 -fca -hnl -i8 -ip4 -l79 -lp -npcs -nprs -psl -saf -sai -saw -sc -nsob -nss -ts8 A search of the archives for a few of those options may turn up the original. If you'd like to conjure up a patch to add a knf mode, I'm happy to test and commit it. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On Monday 24 November 2003 10:24 pm, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Stefan =?iso-8859-1 And that is what this thread is about: Secure removal of data from storage media. There definitely is a difference between RLL (as in 1,7i RLL) and modern PRML drives under this aspect. No there isn't. It's been proven again and again that you cannot reliably overwrite data on a magnetic media. In particular the difference in read/write geometry and lack of fine control over head placement makes this impossible. The only reliable way to loose data is to encrypt them and throw the key away. This is the conclusion I came to after pushing the idea around for months. If you want an interesting problem to work on, come up with a solution to the keying problem for disk encryption. It somehow needs to allow automated, unattended reboots during normal operations but prevent attackers from compromising the system. Maybe you could have the system send an SMS message when it needs a key, you reply with a one-time key from your mobile phone? While you're in there, paint that bikeshed blue. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On Friday 21 November 2003 03:56 pm, Stefan Eßer wrote: On 2003-11-21 14:09 -0800, Wes Peters [EMAIL PROTECTED] wrote: As for performance, you really need to flush the on-device cache on each pass to make sure the bit patterns get written to the platter in proper order. I don't see any clever way to coalesce the writing of the various patterns to multiple blocks short of a kernel thread, either, so performance would be abysmal. Imagine removing a large file, overwriting each block in 37 (IIRC) passes, syncing all the way through the on-disk cache after *every block.* I may be way off, but I do not think, that a special thread or a cache flush after each block is required: A simple algorithm could just mark each buffer with a special kind of dirty flag and a counter for the pass number (in fact, the existing dirty flag could be used, and a counter set to the number of passes required, with 0 indicating that the buffer is to be flushed to disk as is in the normal way). Oh, but you're wrong, if you actually want to ERASE the data on the disk platters. That's why I've referred people to the obliterate program in ports several times. Read the references contained there, then come back to this discussion. If you just want to zero the blocks, that is a lot easier, but you're not really protecting anything from anyone who can get their hands on the disk. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On Saturday 22 November 2003 02:54 am, Stefan Eßer wrote: On 2003-11-22 11:04 +0100, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Stefan Eßer [EMAIL PROTECTED] writes: I may be way off, but I do not think, that a special thread or a cache flush after each block is required: [...] What happens if you yank the power cord? Worst case: The same thing that happened, if the you lost power a fraction of a second earlier, just before the unlink or loss of last reference to the file ... Nothing short of a self-destruct mechanism will do any better ;-) Poppycock. Encrypting the data before it hits the disk is a fine protection against somebody later recovering the data, either inadvertantly or nefariously. Back to the subject of this thread: You could write a special flag needs to be securely removed to the inode. That way, an interrupted overwrite process could be continued after next reboot (for example initiated by fsck). But why would somebody trying to steal your data run fsck on it? You're not thinking paranoid enough. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On Sunday 23 November 2003 04:15 am, Stefan Eßer wrote: On 2003-11-23 00:16 -0800, Wes Peters [EMAIL PROTECTED] wrote: On Friday 21 November 2003 03:56 pm, Stefan Eßer wrote: A simple algorithm could just mark each buffer with a special kind of dirty flag and a counter for the pass number (in fact, the existing dirty flag could be used, and a counter set to the number of passes required, with 0 indicating that the buffer is to be flushed to disk as is in the normal way). Oh, but you're wrong, if you actually want to ERASE the data on the disk platters. That's why I've referred people to the obliterate program in ports several times. Read the references contained there, then come back to this discussion. This is rude! It's been some time since I read the Gutmann paper, but I still remember the points he made and even quite a number of the details. Either my (English) language skills are insufficient to make my point, or you just didn't read what I wrote. I thought it was obvious that if I'm talking of several passes, that each one writes specific data (either a complement of the original data, a suitable pattern or random data). I'm sorry, I must've cut out the part where you wrote that it isn't necessary to flush the data through the drive cache. It is, because the patterns have to be applied in order and may not work if applied out of order. Therefore, you have to flush the data from the drives own cache onto the platters after you have applied each pattern. You can optimize this by moving the solution to a different layer or implementing a kernel thread, but the drive cache sync does need to be done. What I'm suggesting is to have the obliteration implemented as an add on to the dirty buffer flush, with the difference that the buffer contents is prepared for the next step of the erasure process, written out, and then not declared free but again prepared for the next overwrite pass. A counter is required to keep the required state information for each individual buffer. AFAIK, there is no need to retain original data (or its complement) for the process, so in fact all that is needed is a pass counter and the very simple FA. There is no need for a special thread, and that was the point I was trying to make. Yes, I see. For each block, you store the index of the next pattern to be written as each current pattern Takling of obliterate: There is the patterns[] array and the passno variable attached to a buffer could select one of those patterns on each pass of the elevator. (Well, may be a seperate thread might be better to prepare buffers by filling in the correct patterns at slightly reduced priority ...) This would probably be an optimal solution. Given the difference between CPU performance and disk I/O speed, I've come to the conclusion disk encryption is probably a lower-cost solution. The big problem with disk encryption is the question where do I get the keys from. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On Sunday 23 November 2003 04:46 am, Stefan Eßer wrote: On 2003-11-23 00:19 -0800, Wes Peters [EMAIL PROTECTED] wrote: On Saturday 22 November 2003 02:54 am, Stefan Eßer wrote: On 2003-11-22 11:04 +0100, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Stefan Eßer [EMAIL PROTECTED] writes: I may be way off, but I do not think, that a special thread or a cache flush after each block is required: [...] What happens if you yank the power cord? Worst case: The same thing that happened, if the you lost power a fraction of a second earlier, just before the unlink or loss of last reference to the file ... Nothing short of a self-destruct mechanism will do any better ;-) Poppycock. Encrypting the data before it hits the disk is a fine protection against somebody later recovering the data, either inadvertantly or nefariously. Aren't we again unneccessarily rude here ? Encrypting data and secure removal of data are orthogonal and in case you need one, the other propbably won't be a good choice. Both are completely adequate to protect the data on the disk from disclosure. In doubt, I'd use encyption at the disk block level to protect sensitive data, but that's not the topic of this thread, IIRC. The subject was to get rid of remnants of data (whether encrypted or not) from some magnetic media (and similar methods might be suitable for flash media with different patterns and a smaller number of passes). Back to the subject of this thread: You could write a special flag needs to be securely removed to the inode. That way, an interrupted overwrite process could be continued after next reboot (for example initiated by fsck). But why would somebody trying to steal your data run fsck on it? You're not thinking paranoid enough. Sorry, but what are you talking about ? fsck could identify incompletely erased (in the sense of multipass overwrite with specific patterns) blocks, if that state was marked in the inode. But if someone is attempting to recover your deleted data, they're not going to run tools that would potentially eliminate that data from the disk. I'm designing to the idea of a disk that has been physically taken to a data recovery lab, because the intermediate steps don't interest me. But you see that: This is not meant as protection in case power is removed and the disk is analyzed off-line since most probably no fsck will ever be run over the filesystem again. The data needs to be overwritten in a timely manner as well. Leaving the disk in a partly erased state is the same as leaving it unerased. If you don't want the processing delay needed to do the full erasure you obviously don't really need full erasure. It is meant to protect against a power failure (or reboot) with data not being erased according to the specification, which might survive for a long time after next start (not by an attacker but in normal service). This is extra paranoia (compare to a crash while obliterate is overwriting blocks, which will not be restarted after a crash ...) It seems that you are opposed to having secure erase support in the kernel, and in fact, I'm not sure it is that useful, myself. No, at one time I had it on my todo list, but came to a more full understanding of the expense and abadoned it for that reason. I may someday do it in the simplest form just to prove it workable to myself, but I doubt that is a solution of general interest to FreeBSD. But in case it is considered useful and implemented (I'd try it myself, if I was interested in using this feature), then we should discuss the techical (and security) aspects of several designs and that's what I'm trying to do. There is some merit in providing a mechanism that is 90% as secure at 10% the computational cost. I basic infrastructure that provides a secure removal flag at the file and/or filesystem layer and a choice of patterns would be a nice solution. Those who just want to make sure the contents of an email aren't inadvertantly disclosed to another user could specify a simple pattern like overwrite with zeros once, those who want to keep the FBI at bay could use the whole 37 passes and spend days deleting files. Maybe I'll look into this again after all. The former variant seems like it might even be useful for a mail server or similar application. Have you seen any literature on secure overwrite patterns for flash? That would be an interesting option to provide. If nothing else, I'd like to hack something like that into obliterate. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On Friday 21 November 2003 05:30, Dag-Erling Smørgrav wrote: Pawel Jakub Dawidek [EMAIL PROTECTED] writes: I'm aware of this, but what we want to think over here is something like in-kernel 'rm -P'. So file will be overwriten even if it is opened and/or link count is grater than 0. That is not acceptable. First of all, it breaks a lot of assumptions in the filesystem code. Second, it is incompatible with the common technique of unlinking a temporary file immediately after opening it to avoid having it stick around if the process that created it dies prematurely. Your proposed change would thus reduce security rather than enhance it. Right. The idea of restricting a file marked secure to not be able to link to it, and refusing to set the flag if the file has a link count greater than 1, is easy to do. I'm not sure it makes sense, though. Besides, overwriting the contents of a file when it is removed from the file system is not enough. You also need to overwrite every block or fragment which is released any time the file shrinks. Fortunately, ufs always truncates a file to length 0 when it is removed, so you only need to modify ffs_truncate() to implement both aspects (truncation and removal). You should also take care to overwrite the file's extended attributes if it has any. For ffs, I believe it would be as simple as providing this behavior in ffs_blkfree. Both the vnode and fs are passed to ffs_blkfree, so the code should be able to check filesystem flags and/or file flags to determine if the block should be erased before freed. This simplistic approach would forgo some potentially very helpful optimizations, though. Finally, I think a filesystem flag is much better for this purpose than a file flag; and in either case, file removal and truncation performance will be awful. The filesystem flag is no more or less difficult to do; I can see doing both for completeness sake. As for performance, you really need to flush the on-device cache on each pass to make sure the bit patterns get written to the platter in proper order. I don't see any clever way to coalesce the writing of the various patterns to multiple blocks short of a kernel thread, either, so performance would be abysmal. Imagine removing a large file, overwriting each block in 37 (IIRC) passes, syncing all the way through the on-disk cache after *every block.* Disk encryption suddenly doesn't look so bad, does it? -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On Tuesday 18 November 2003 16:31, Rayson Ho wrote: I am wondering if it is useful to have a secure file flag?? The secure file flag will be set for files that contain sensitive data. Then the OS will take special care when operating on those secure files. e.g. when deleting a secure file, the OS will overwrite the file with random data. Better to overwrite it with a more secure pattern. See ports/ sysutils/obliterate for references. It has been mentioned before that this could be done on in the kernel, obliterating blocks in the VM rather than zeroing them. I hadn't thought of applying at the file or filesystem level. One advantage would be to have secure files in the same filesystem as other normal files. Any one knows if FreeBSD has already implemented this?? The closest we have is the 'rm -P' command and the above-mentioned obliterate command. The overwrite pattern used in 'rm -P' is not likely to be effective against a dedicated inspection of the disk; the one in obliterate somewhat more so. This sounds like an interesting file flag. Would you expect the process to block on the unlink(2) call while the overwrite takes place, or for this to happen in a kernel thread? The former seems pretty straight- forward, hacking at ffs_blkfree. The latter I really wouldn't know how to begin without (a lot) more study. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Observations on make release process?
On Friday 14 November 2003 02:57 pm, Clifton Royston wrote: On Fri, Nov 14, 2003 at 10:48:13PM +0100, Wilko Bulte wrote: On Fri, Nov 14, 2003 at 11:37:05AM -1000, Clifton Royston wrote: Is this as good a list as any for observations on the FreeBSD make release process? I can't see any other list that fits the subject. Did you dig into http://www.freebsd.org/releng/#docs ? Oh yes, that was one of my bibles so far, especially http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-bui ld.html along with man release and some other notes I've found on the web like: http://www.sfc.wide.ad.jp/~watari/FreeBSD/boot.html Here's one minor inaccuracy (or at any rate inadequacy) I've found in man release and the above pages: Patches or additions to existing documentation, or even just providing text to one of our many dedicated doco contributors, would be greatly appreciated. What can you do for FreeBSD today? ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: non-root process and PID files
On Friday 14 November 2003 01:45 am, Terry Lambert wrote:
Jos Backus wrote:
On Thu, Nov 13, 2003 at 02:45:18AM -0800, Terry Lambert wrote:
There are also the small issues of ordering (the reason you can't
just run everything out of /etc/ttys via init in the first place),
Sure. Hard to get right but not unsolvable. No reason you can't use
process monitoring with something like rcNG.
We tried very hard to do this on the InterJet. We still ended up
shooting most things in the head with large caliber bullets each
time the dial on demand interface went up or down because we did
not have the idea of hard and soft dependencies.
On the latest iteration of system configuration at St. Bernard, we do
track hard and soft dependencies. It turns out that it doesn't help as
much as you'd like, because...
Even if we had
had them, though, we would still have been SOL, since many of the
Open Source programs we used cached information when they started.
Because of this, the data could get stale.
Yup. I'm still amazed at the amount of software that doesn't have the
ability to reset it's configuration without just shooting it and starting
anew.
/service/smtpd.{external,internal}
Yeah, we did this, so that we could shoot only half the processes
in the head on link up/down.
It sucked. We almost shipped a product that wouldn't hav worked
when we did the DNS split, because the dependency graph had to be
manually managed, and wasn't.
We work in a much more static environment, which does make things a bit
less of a challenge. I encountered all the same problems at DoBox, and
solved them the same way. The St. Bernard appliances tend to get
reconfigured several times during installation then rarely after the
fact, so the challenge is to make sure we don't blow up while the
customer is trying to get it working out of the box. Tracking the
startup dependencies separately from reconfiguration dependencies helps
quite a bit on this front.
and removing human error from adding and removing new things to be
monitored.
That's a generic problem with any type of change management.
Not really. If your configuration changes all happened in a
centralized data repository, and nobody cached anything, but got
their information from that central repository, and the interface
to the repository was a system interface (so the system could
cache on your behalf so performance didn't degrade unbearably),
THEN you might have something. After you rewrote millions of
lines of Open Source code to use your registry instead of working
the way it currently works, which is everyone has their own poop
files. If you are lucky, hitting them over the head with a
shovel (SIGHUP) works, and you don't have to kill and resurrect
them (you just have to wait a long time before the services become
usable again, e.g. DNS reading its config files).
We have one of those. It even has a (relatively) stable API. It's called
PostgreSQL, perhaps you've heard of it? ;^)
Not what I'd recommend for a general configuration database, but we were
already using it for other data, and it does a pretty good job of cache
coherency. The differences in processor speed and memory cost these days
vs. what you worked with at Whistle makes a lot of difference in what you
can do as well.
Anyway, FreeBSD has steadfastly disliked the concept of a registry,
ever since Microsoft implemented it in Windows95; it's on of the
biggest NIH items of all time.
And yet struggles to move towards it in a limited fashion, with the
rc.conf concept. The problem would be making the necessary changes to
all those millions of lines of somebody else's code to have everything
work out of the registry.
--
Where am I, and what am I doing in this handbasket?
Wes Peters [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
On Saturday 25 October 2003 13:15, Poul-Henning Kamp wrote: For the last ten years, the NetBSD, OpenBSD and FreeBSD projects have had a tacit agreement not to post propaganda and inflamatory accusations to each others email lists (what project members do in their own projects is of course a different matter). I, and I think other members of FreeBSD, would appreciate it if the members of DragonflyBSD would adhere to this peace-keeping rule as well. Well said, and thank you. Tangential discussion full of wild, unsubstantiated accusation are certainly NOT going to help relationships between any groups of humans. Bad form, Mr. Macy. Please come back when you have a point. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED]http://softweyr.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: non-root process and PID files
On Monday 27 October 2003 07:31 am, Dan Langille wrote: If a process starts up and does a setuid, should it be writing the PID file before or after the setuid? Two methods exists AFAIK: 1 - write your PID immediately, and the file is chown root:wheel 2 - write your PID to /var/run/myapp/myapp.pid where /var/run/myapp/ is chown myapp:myapp Of the two, I think #1 is cleaner as it does not require another directory with special permissions. Any suggestions? Create the pid file while still root, and if you are going to change the user or group id, chown(2) or chgrp(2) the file just before setuid(2) / setgid(2) calls. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: non-root process and PID files
On Monday 27 October 2003 12:42 pm, Dan Langille wrote: On Mon, 27 Oct 2003, Wes Peters wrote: On Monday 27 October 2003 07:31 am, Dan Langille wrote: If a process starts up and does a setuid, should it be writing the PID file before or after the setuid? Two methods exists AFAIK: 1 - write your PID immediately, and the file is chown root:wheel 2 - write your PID to /var/run/myapp/myapp.pid where /var/run/myapp/ is chown myapp:myapp Of the two, I think #1 is cleaner as it does not require another directory with special permissions. Any suggestions? Create the pid file while still root, and if you are going to change the user or group id, chown(2) or chgrp(2) the file just before setuid(2) / setgid(2) calls. I'm told that this leaves you open to a symlink attack. If you leave the file chown root:wheel, then if an attacker does gain control of the application, they can't change the PID file. The key point is the app is root when writing the PID file. If the attacker symlinks the PID to something else (e.g. /etc/fstab), then that's when the fun starts. OK, bad knee-jerk design. In the past I've always just followed the standard 'clean it up when the daemon is restarted' philosophy because it seemed safe to leave the file 'protected' this way. For clean shutdowns, shutdown scripts run as root can clean up any pid file they want, right? If the process crashes, having the pid file available may prove helpful in debugging, at least in terms of log traces and such. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD mail list etiquette
In a recent message on this list, Poul-Henning Kamp [EMAIL PROTECTED] took Kip Macy [EMAIL PROTECTED] to task for posting DragonFlyBSD research and development results here, writing You seem to have mistaken [EMAIL PROTECTED] for [EMAIL PROTECTED] Please don't make this mistake again. Please note that Poul-Henning Kamp is NOT a moderator for this mail list, nor an official of the FreeBSD Project in any way. The above is simply Poul-Henning's opinion; you may attach whatever validity to that you wish. Kip Macy, other DragonFlyBSD developers, and anyone else wishing to contribute are invited to join and participate in the open FreeBSD mail lists, sharing code, design information, research and test results, etc. according to their own will. We welcome input from everyone, including constructive criticism of weaknesses or flaws in FreeBSD. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: smallest piece of hardware that runs *BSD?
On Friday 10 October 2003 07:17 am, C. Kukulies wrote: 1990: In ten years, computers will just be bumps in cables. (Gordon Bell) Remember that quote? Now, we are not far from that. I'm thinking of some CPU with TP Ethernet and memory of size of an USB stick. Anyone knowing such or having experience? Grab a copy of Embedded Systems Programming, there are ads for things like this all over near the back of the magazine. In particular, the chip in whatever USB stick you're looking at probably has an 8-bit CPU of some sort in it. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VT8237 serial-ATA support, Promise ATA stalls, GEOM noise
On Monday 06 October 2003 12:10 am, Soren Schmidt wrote: It seems Sean Hamilton wrote: I have two Asus boards (A7V8X and A7V) which have in common a Promise ATA controller. Both of these boards hang up for about a minute during the boot of 5.1-RELEASE, and emit messages about ad* devices being reset -- I cannot paste them verbatim as they seem to have been omitted from my dmesg. In the case of the A7V8X, the controller is unused and disabled in the BIOS. Has this been rectified for 5.2? Should not happen on -current. I haven't seen this on my A7V, running a week-old -current: atapci0: VIA 8235 UDMA133 controller port 0xb000-0xb00f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 76319MB WDC WD800JB-00CRA1 [155061/16/63] at ata0-master UDMA100 acd0: CD-RW HL-DT-ST GCE-8481B at ata1-master PIO4 The system is quite fast; it outperforms my P4 2.0 workstation at work on 'worldstones' by several minutes. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing the NAT IP on demand?
On Sunday 05 October 2003 19:11, Nick Rogness wrote: On Sun, 5 Oct 2003, Wes Peters wrote: On Sunday 05 October 2003 01:02 am, Nick Rogness wrote: On Sat, 4 Oct 2003, Leo Bicknell wrote: I'm considering options for a new project, and I think I've discovered what I think is the best idea, but I don't think current software supports the config. I'd like to get some confirmation, and comments on if it would be hard to implement. Consider: ISP #1---\ \ FreeBSD BoxLAN / ISP #2---/ In this case the LAN would be 1918 space, the two ISP's would each provide a public IP for the FreeBSD box. Now, NAT would be required. What I want to do is write an external application to decide the performance of ISP #1 and ISP#2, and somehow tell NAT which outside address to use. That, by itself, is not hard. Here's the trick. I want the switch to be seamless. That is, if NAT is translating to ISP #1 and the application says switch to #2 the existing translations to #1 (until they go away naturally) should be kept, while new ones go to #2. The only ways I know to change the outside address seem to tear down all existing connections. Is it possible to make this work today? Would it be hard to fix if it doesn't work today? This can simply not work without resetting connections. The socket pair on the outside would break as your outside traffic switches from one to the other (src/dst would change). There is no fix, as this breaks basic IP principals. That's not at all what Leo was asking. Sorry bout that, didn't read carefully enough. I understand the question now after more careful reading. Leo, you may be able to do this with ipfilter's ipnat. Nat rules are traditionally processed with 'ipnat -CF', the -C clears the rules and the -F option clears the currently active NAT mappings. You should experiment with rewriting the rules and instantiating them with -C only. This should leave the existing stateful mappings to the formerly preferred interface while creating all new mappings on the newly preferred interface. In addition to keeping your NAT translations (as suggested by Wes), you need to also keep routes for those entries as well, so that preserved traffic remains to route out the right ISP even if a switch occurs. Ah, yes, another sticky bit of the problem. It seems you could do a least a partial workaround by creating and maintaining a host route for each active NAT mapping. The NAT engine would have to reference-count the routes it is maintaining. This *is* a simpler alternative than hacking source routing into FreeBSD at this point. The reason for this is simple. When you switch the route(s) to the other ISP (which you would have to do), your existing translations would get routed out to the wrong ISP. You would need to keep routes for existing translations to make sure they leave the proper 'old' interface. This would not be necessary if each ISP allowed you to use either public IP on each others network (not likely). Nat (AFAIK) does not determine which interface to leave. You can ipnat operates quite differently from natd; it bears looking into. It's been a while since I was intimate with ipnat, so I can't say off the top of my head how hard this might be. change the source address in the packet to anything you want, this will not tell it to leave 'interace_to_ISP#1' or 'interface_to_ISP#2'. That is a decision made using the routing table. ipnat redirections already have a limited sort of round-robin load balancing capability. A quick read through ipnat(5) may enlighten. It would be instructive to search out the round-robin code and think about how to extend it into a mechanism to do failover or smarter load balancing. Your app would have to keep track of these NAT things and also add and remove routes from the routing table. Nat mappings are already available, via the /dev/ipnat device and ioctl's, with ipnat. That is, if everything is going out ISP#1 and you decide to switch to ISP#2 you would need to: 1) Keep exisiting NAT translation(s) like suggested by Wes. 2) Add routing table entry for each of the NAT translations you want to preserve to ISP#1 3) Switch default routing to ISP#2 4) When sessions are finsihed and NAT translations removed to ISP#1, the route(s) that pertain to those NAT translations would need to be removed. Yeah, conceptually it's pretty simple isn't it? The devil is, as always, in the details. ;^) -- Where am I, and what am I doing
Re: Changing the NAT IP on demand?
On Monday 06 October 2003 06:43, Leo Bicknell wrote: Note, I think this configuration would be useful in a lot of other applications as well. Consider someone who can get, say, a 128k symmetric DSL line, and a 56k up 1M down satellite link. If using this trick you could direct latency sensitive (ssh, telnet, ntp) traffic over the DSL line, and send bulk data (http, ftp) over the satellite link that could be quite useful. I think I'm going to have to set up a lab box now and dig into this at a deeper level. Linux apparently has some software available to does at least part of this; others who have asked similar questions in the past have referred to such capabilities. A grep through the archives might be in order, but I can't recall enough to give you a guideline on what to search for. Maybe 'nat' and 'multiple' or something like that. Good luck! -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] : libc_r/uthread/uthread_write.c
On Saturday 04 October 2003 07:21 am, Dan Langille wrote: On 4 Oct 2003 at 10:17, Daniel Eischen wrote: On Mon, 29 Sep 2003, Dan Langille wrote: All our testing on this patch has been successful. I'm going to do a few more tests on different hardware under 4.8-stable. What's the next step? Commit it? Get others to test with it first? It's already in -current. Thanks for that commit. You'll have to wait for the code freeze to thaw in -stable before it goes in there. Bugger... which means it won't be into 4.9-RELEASE. If it is important, forward the code and the reason it is needed to [EMAIL PROTECTED] Code freeze means 'only critical bug fixes'; if this is one of those, let's get it in. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED]http://softweyr.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing the NAT IP on demand?
On Sunday 05 October 2003 01:02 am, Nick Rogness wrote: On Sat, 4 Oct 2003, Leo Bicknell wrote: I'm considering options for a new project, and I think I've discovered what I think is the best idea, but I don't think current software supports the config. I'd like to get some confirmation, and comments on if it would be hard to implement. Consider: ISP #1---\ \ FreeBSD BoxLAN / ISP #2---/ In this case the LAN would be 1918 space, the two ISP's would each provide a public IP for the FreeBSD box. Now, NAT would be required. What I want to do is write an external application to decide the performance of ISP #1 and ISP#2, and somehow tell NAT which outside address to use. That, by itself, is not hard. Here's the trick. I want the switch to be seamless. That is, if NAT is translating to ISP #1 and the application says switch to #2 the existing translations to #1 (until they go away naturally) should be kept, while new ones go to #2. The only ways I know to change the outside address seem to tear down all existing connections. Is it possible to make this work today? Would it be hard to fix if it doesn't work today? This can simply not work without resetting connections. The socket pair on the outside would break as your outside traffic switches from one to the other (src/dst would change). There is no fix, as this breaks basic IP principals. That's not at all what Leo was asking. Leo, you may be able to do this with ipfilter's ipnat. Nat rules are traditionally processed with 'ipnat -CF', the -C clears the rules and the -F option clears the currently active NAT mappings. You should experiment with rewriting the rules and instantiating them with -C only. This should leave the existing stateful mappings to the formerly preferred interface while creating all new mappings on the newly preferred interface. This might tend to confuse UDP-based services, which might see the next request as a different 'session', but I doubt those are much a problem across the internet. Good luck. If you run into bugs, I've always found Darren Reed to be helpful and interested in improving ipfilter/ipnat. This might even be a feature that intriques him enough to pique his interest in making it a feature of ipnat. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED]http://softweyr.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is socket buffer locking as questionable as it seems?
On Saturday 04 October 2003 11:39 am, Sam Leffler wrote: On Friday 03 October 2003 10:38 pm, Brian Fundakowski Feldman wrote: I keep getting these panics on my SMP box (no backtrace or DDB or crash dump of course, because panic() == hang to FreeBSD these days): panic: receive: m == 0 so-so_rcv.sb_cc == 52 From what I can tell, all sorts of socket-related calls are MP-safe and yet never even come close to locking the socket buffer. From what I can tell, the easiest way for this occur would be sbrelease() being called from somewhere that it's supposed to, but doesn't, have sblock(). Has anyone seen these, or a place to start looking? Maybe a way to get panics to stop hanging the machine? TIA if anyone has some enlightenment. Haven't seen anything on my SMP test box. As Robert has already said sockets are still implicitly locked by Giant. You need to provide more information like what version you are running and what your system is doing when the panic occurs. FWIW panic does not hang for me so you might first try to figure out why that's occuring. Is this one of the areas you are planning to get to, Sam? -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wireless Embedded monitoring
On Tuesday 23 September 2003 15:55, Daniel Eischen wrote: On Tue, 23 Sep 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel Eischen [EMAIL PROTECTED] writes: : Anyone have any experience with PC/104 or other really small : footprint platorms and FreeBSD? Yes. Works great. We've used FreeBSD on about two dozen different single board computers. : We need to build a small box for equipment monitoring : (temperature, pressure diff., vibration, indication). Just a few : discrete inputs/outputs, and analog inputs would be good enough. : The hard part may be sampling an A/D signal at up to 30KHz, so : having the I/O card do the sampling and buffer it would : probably be necessary. I'd recommend one of the Soekris boxes. : Any ideas on hardware (SBC, I/O board)? http://www.soekris.com is great. Yes, it looks nice. The form factor is just a bit larger than PC/104, especially with a PCCard plugged into its side. We'd also need some sort of general purpose I/O card which are fairly easy to find in PC/104 stacking modules. I'll join in the general chorus here. I had one of the very early soekris boxes and found it to be a gem. If a 5x86 133MHz processor meets your needs, you'll like it a lot. I haven't tried the net4801 board, but I've worked with other Geode designs and if you need more cpu, that'll probably do. Good luck. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: percent support in sysinstall slice editor
On Monday 22 September 2003 17:18, Matt Peterson wrote: Howdy, Would it be possible to add disk percentage support in the sysinstall slice editor? That is, instead of building slice based on a fixed size (ie: 5Gb) use percentage of the total disk size (ie: 25%). Yeah, that's a great idea! Where's your patch? ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Shared memory question
On Friday 29 August 2003 20:31, Lev Walkin wrote: zera holladay wrote: When one uses the term shared memory while discussing Unix, then what is generally the meaning of that term? I have read that some Unixes have shared memory for shared objects. [...] Shared memory is just a chunk of memory which may be created by one program and attached to (by) many other programs. Yes, the management (allocation and deallocation) of shared memory chunks are done in kernel. User space applications have to use shmget(2), shmat(2), shmdt(2) system calls to obtain, attach and release the chunk of shared memory. Or mmap(2) with the MAP_SHARED attribute set. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ugly Huge BSD Monster
On Tuesday 02 September 2003 04:07, Sten Daniel Sørsdal wrote: On Mon, Sep 01, 2003 at 12:38:34PM -0700, Greg Shenaut wrote: Has it ever been suggested to create one or more dependencies ports (or more to the point, packages)? I think it might be pretty useful to have something like that so that all of the prerequisites can be installed at once. Maybe I'm missing something but how would that be an improvement on what FreeBSD does now? If I try to install package X, it will automatically install dependencies A, B and C, as well as their dependencies. That would ease the installation of port X on Y number of machines. Same libraries, same everything, precompiled. Otherwise one needs to manually track dependencies (not a terribly difficult job) and make those as packages, and keep doing this until all dependencies are as packages (in my case, i have several light-weight servers/routers that have no gcc/make capabilities). If anyone knows of a program/script that will do this for me, please speak up! portinstall -r -p pkgname will build a package for pkgname and all of it's dependencies. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Addition to reboot(8): reboot / halt reasons
On Tuesday 02 September 2003 06:40, Daniel Lang wrote: Hi, Christopher Nehren wrote on Tue, Sep 02, 2003 at 08:55:23AM -0400: On Tue, 2003-09-02 at 00:36, Sean Kelly wrote: Err.. Wouldn't it just be easier to use the `shutdown` command? I suggest you check `man 8 shutdown` out. I'll concede and admit that I should have RTFM'd. But in the same vein, if shutdown(8) provides the functionality of halt(8) and reboot(8), why do they exist as separate programs? I'm probably missing something here, but wouldn't it be easier to just combine shutdown and reboot / halt, as reboot and halt already are? Yes, you are missing something. shutdown(8) is a sort-of frontend to reboot/halt. It contains additional functionality and calls /sbin/halt or /sbin/reboot. So the combination already exists. Further halt(8) and reboot(8) are the same program, as you can easily verify using ls -i. The shutdown(8) frontend adds warning-messages and grace-time features to reboot/halt. The true answer is hysterical raisins. Or was that historical reasons? Something like that. reboot and halt are BSD commands, shutdown SYSV-ish. Shutdown has all those nice professional options to warn users, schedule a shutdown in a few minutes, etc. Reboot and halt expect you to already know how to use at(1) and wall(1) to effect the same results, and to write a script if you really want to do that over and over again. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
3Com 3C940 gigabit ethernet adapter
While poking around looking for support for this chip on the ASUS P4P800, I happened to find that our friends over in OpenBSD-land have added support for the 3c940, which is a variant of the SysKonnect Marvell chipset. This seems to have been added in r1.32 of if_sk.c in the OpenBSD sources. If you have some hardware, you may wish to poke into this. Good luck. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Committing a driver to -stable
On Friday 18 July 2003 06:28, Bosko Milekic wrote: On Fri, Jul 18, 2003 at 06:19:46PM +0200, Harti Brandt wrote: Hi all, as far as I know new stuff should be first committed to -current and, if it turns out stable enough, MFCed to -stable. I would like to commit a driver to -stable that will not be in -current. The driver is for ProSum's ProATM card. I have recently committed a full busdma driver to current (patm(4)), that I hesitate to backport to -stable because it requires ATM infrastructure that we don't have in stable. On the other hand there is a -stable driver for this card from ProSum (www.prosum.fr) that is reported to be very stable under -stable :-), that several people use and that I would like to commit. So, can I do this? If the same device is supported under -current already, and it's a question of how the driver is implemented (i.e., completely differently in -stable due to a lack of -current's ATM infrastructure), then I don't see why not. However, you may want to wait for someone from the TRB (is there a list of who's part of this group somewhere, anyway?) and/or -core to respond before you take action. Agreed. I suggest dashing off a copy of your original message to arch@ and follow up to trb@ ONLY IF someone complains. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raw socket programming SOLVED
On Saturday 05 July 2003 08:01 pm, Alin-Adrian Anton wrote:
Yes, it works now, with these includes:
---
#include sys/types.h
#include sys/socket.h
#include stdio.h
#include string.h
#include errno.h
#include netinet/in_systm.h
#include netinet/in.h
#include netinet/ip.h
#include unistd.h
#include netinet/tcp.h
---
Believe it or not, the advice in style(9) is quite helpful in putting
include files in their correct order. I'm so used to doing things in
similar order that I re-wrote your original program as:
#include sys/types.h
#include sys/socket.h
#include netinet/in_systm.h
#include netinet/in.h
#include netinet/ip.h
#include netinet/tcp.h
#include errno.h
#include stdio.h
#include string.h
#include unistd.h
int main() { printf(foo\n); }
after grepping for n_long in /usr/include. The order of the netinet
includes; in.h then ip.h then tcp.h, seems logical to me. Perhaps a
(re-) reading of the instructions on include files in style(9) is in
order.
--
Where am I, and what am I doing in this handbasket?
Wes Peters [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: Change to sys_errlist
On Thursday 10 July 2003 01:21 pm, Matthew Emmerton wrote: On Sun, 6 Jul 2003, Terry Lambert wrote: Matthew Emmerton wrote: This is a RFC on a change to sys_errlist for errno = 0. On Linux, if perror() or strerror() is called with errno = 0, the resulting string is Success. On FreeBSD, the resulting string is Unknown error: 0. I think that FreeBSD's output is unintentionally confusing, as errno = 0 implies success. The following patch will change the output to the Linux behaviour. I appreciate any comments. Actually, I ran into a situation on MacOS X the other day that had a system call with a -1 return code with an errno == 0. I would personally like to distinguish this case, if only for the purpose of catching kernel errors. Saying Success when in fact the system call is returning -1 is a bogus thing to do. Agreed. I thought this over and read some specs and believe our way is the right way. In point of fact, errno == 0 does NOT mean Success, it means WTF?. 0 isn't a valid errno, so no meaning can be gleaned from errno == 0 any more than it could be gleaned from errno == 0xb00bface or errno == 6.023e23. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gethostbyname_r
On Monday 30 June 2003 14:39, Kris Kennaway wrote: On Mon, Jun 30, 2003 at 04:43:27PM +0200, Stijn Hoop wrote: Hi, I was wondering if anybody was working on an implementation of a reentrant gethostbyname_r function, mostly because it looks like mozilla/firebird will finally gain support for an async DNS thread in the near future. However, it is claimed in Mozilla's bug reporting system that FreeBSD 5.x doesn't have support for this. See http://bugzilla.mozilla.org/show_bug.cgi?id=70213#c36 A quick grep -r in /usr/src shows only hits in contrib, so it's probably true that it's not implemented. There was a bogus non-reentrant version half-implemented in libc in both 4.x and 5.x, which I recently removed in 5.x. I need to remove it on 4.x as well. General consensus seems to be that implementing it properly is Hard. Yes, it is, or at least was in 4.x. I thought we got a shiny new gethostbyname_r with Jacques Vidrine's nss implementation in 5.0, though. Is this not right? -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kqueue alternative?
On Monday 16 June 2003 11:39 am, Eric Jacobs wrote: On Mon, 16 Jun 2003 10:11:10 -0700 Joshua Oreman [EMAIL PROTECTED] wrote: On Mon, Jun 16, 2003 at 11:44:15AM +0100 or thereabouts, Tony Finch seemed to write: Select doesn't work with files. Really? `man 2 select' says nothing about that. It just talks about 'file descriptors'. Now if it said 'socket descriptors' or 'non-file file descriptors' I would understand, but I don't think that that statement is implied by the man page. Is there something I'm missing? A file descriptor that references an ordinary vnode (file or directory) will always be ready for I/O, because unlike a socket or pipe, it never needs to block in order to tell you if it's at EOF. So, while it works, and is logical, it isn't terribly useful. It's useful from the standpoint that the same select code that works with a device or socket handle, both of which can block, will work with a file handle that can't block or a pipe handle that can block. Looked at in this light, it would be really stupid if select didn't behave as it does when fed a file handle. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is BSD a Linux operating system?
On Tuesday 10 June 2003 12:02 am, Danny Braniss wrote: http://www.linuxiso.org/ and now back to our local programming, danny Don't get your undies in a bundle, it's really just a free advertising site. All of the downloads are links to existing mirror sites. I sent them a note about 5.1 and all the new architectures; let's see how responsive they are about updates. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc bug? Openoffice port impossibel to compile on 4.8
On Thursday 29 May 2003 00:12, Dag-Erling Smorgrav wrote: Bruce M Simpson [EMAIL PROTECTED] writes: However, we're dealing with something a bit more stable in terms of code base, anyway. Having to commit a whole bunch of fixes for the sake of a compiler upgrade isn't acceptable. Sounds like the GCC guys have been bitten by the Linux bug. May I remind you that KR-style declarations have been deprecated for the last 14 years? Funny, the last time I looked at a C language specification they were still supported. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc bug? Openoffice port impossibel to compile on 4.8
On Wednesday 28 May 2003 05:12 am, Dag-Erling Smorgrav wrote:
Wes Peters [EMAIL PROTECTED] writes:
GCC 3.2 is broken by design. It insists, amongst other stupidities,
on type-checking arguments using old style declarations like:
int foo(bar)
char *bar;
{}
rendering most UNIX software from before 1996 uncompilable.
have you tried -traditional?
Yup:
cc1: warning: -traditional is deprecated and may be removed
Didn't help a bit.
--
Where am I, and what am I doing in this handbasket?
Wes Peters [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc bug? Openoffice port impossibel to compile on 4.8
On Wednesday 28 May 2003 04:11 pm, Bruce M Simpson wrote: I remember having to convert all my Lattice C code to use ANSI style declarations after upgrading to SAS/C on the Amiga. However, we're dealing with something a bit more stable in terms of code base, anyway. Having to commit a whole bunch of fixes for the sake of a compiler upgrade isn't acceptable. Sounds like the GCC guys have been bitten by the Linux bug. That's what it sounds like to me, too. At the same time we're changing the ports infrastructure so we intentionally break all cross-compilers; they have to fix the CFLAGS in order to make the compilers compile. Linux may be leading the charge but we're following right along. I may take the time to produce a snobol port that compiles cleanly; I like having it available for hysterical raisins. It does irk me that we can't compile valid KR code without the compiler throwing a conniption fit trying to typecheck something it has no real knowledge of. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc bug? Openoffice port impossibel to compile on 4.8
On Thursday 22 May 2003 10:23 am, Julian Elischer wrote:
I have rebuilt my system several times and rebuilt all ports..
/usr/ports/editors/openoffice always ends up with:
GCC 3.2 is broken by design. It insists, amongst other stupidities, on
type-checking arguments using old style declarations like:
int foo(bar)
char *bar;
{}
rendering most UNIX software from before 1996 uncompilable. This is
biting one of my ports, I can't figure out how to shut the fscking thing
up, and am pretty much beyond caring. The Powers That Be in GCC-land
seem to have decided for us the world doesn't need any stinking
20-year-old software.
--
Where am I, and what am I doing in this handbasket?
Wes Peters [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
BSD tar (was Re: Making pkg_XXX tools smarter about file types...)
On Friday 28 March 2003 22:47, Tim Kientzle wrote: P.S. It's galled me for a while that pkg_add has to fork 'tar' to extract the archive. Me too, me too. I've started piecing together a library that reads/writes tarfiles. Excellent. A general design goal in userland should be to implement functionality in libraries and then wrap small driver programs around them to export the basic functionality to userland. I guess this partly violates the original UNIX tools philosophy, but all it really does is move it from the original pipes interfaces into the dynamic linker. With this, it should be possible to make pkg_add considerably more efficient. In particular, rather than extracting to a temp directory, then parsing important information, then moving the files, it should be possible using this library to read the initial entries (+CONTENTS, in particular) directly into memory, process the information there, then extract the remainder of the package files directly into their final locations. I'd much rather see the metadata moved outside the file archives, but that's a separate argument and in now way detracts from your proposed work. ;^) So far, I have a library API outlined, and functional read support implemented. Next step is to hack up a minimal tar implementation that uses it to make sure everything's working correctly. So far, the library automatically detects compression formats (using techniques like those in my pkg_install patch) and has some rough support for detecting the archive format as well. (One goal of mine: support for 'pax extended archives', which I understand can handle ACLs.) I have wondered outloud before if pax might be a suitable starting place for such a hacking expedition. Others who've worked on pax assure me it is not. ;^( Sigh. So much code, so few programmers. Of course, such a library could also form the basis for a BSD-licensed tar to replace GNU tar. I understand a few people have wanted such a thing. Why yes, yes they have. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
On Wednesday 26 March 2003 16:03, David Gilbert wrote: Given the price of this card ... and the fact that less-than-400Mhz CPU's are rather rare, and that this is only an issue for high bandwidth applications ... the rl cards might fit for you. Given the price of the card, you can almost always find a better one at roughly the same price. For instance, this one: dc0: Intel 21143 10/100BaseTX port 0xd800-0xd87f mem 0xf300-0xf30003ff irq 7 at device 11.0 on pci0 was FREE last Christmas, from Office Depot. It's a Belkin branded card and normally sells for $10 (at TigerDirect.com). -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lots of kernel core dumps
On Monday 24 March 2003 11:18, Daniela wrote: On Sunday 23 March 2003 20:20, Wes Peters wrote: The reason for creating the 5.0 release is to make it easy for more developers and testers to jump onto the 5.x bandwagon by giving them a known (relatively) good starting point. Quite a number of problems have been fixed since 5.0-RELEASE; CURRENT is now generally much more stable, and nobody is going to spend time updating 5.0 which is essentially an early access release. You have to decide for yourself if this machine is too critical to run CURRENT, in which case it's probably best off running STABLE or the latest 4.x release branch, or if you want to update it to CURRENT, follow the CURRENT mailing list, and update again at known stable development points. It looks like right now is pretty good if you want to jump. At any rate, thanks for your tenacity. We really do appreciate the contributions of everyone. Well, it's just a home server. I don't mind a few crashes, but security is important for me. What do you think, should I go back to -stable? FreeBSD is the world's best OS, I want to see it succeeding and I want to help as much as possible. I have two machines at home and run STABLE on my workstation, which is also our 'group server' for the home. I have current on a crash test box that used to be my workstation 6 years ago, a K6/233 I can't imagine not having. If you're similarly hardware-rich, I'd recommend a similar approach. If you have only the one box, I personally would probably run CURRENT and be careful about when to run CVSup. Good luck! -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lots of kernel core dumps
On Saturday 22 March 2003 15:10, Daniela wrote: I know, but 5.0-RELEASE was a) A work-in-progress, not a perfect, bug-free release b) A snapshot of 5.0-CURRENT You read the 5.0 Early Adopter's Guide, right? Bugs like this are expected at this stage in the development process, and if you encounter them then you need to either give up on 5.x and go back to 4.x-STABLE, or upgrade to 5.0-CURRENT if they are already fixed there. Kris Yes, I read the Early Adopter's Guide. Is there any way to solve this without upgrading to -current? I want a stable server, of course, but I still want to help the FreeBSD folks to make 5.0 the best release ever. This requires testing to be done. Yes it does, but not on a production machine. We admire your courage and willingness to help, but it's not helping as much as you think. ;^) The reason for creating the 5.0 release is to make it easy for more developers and testers to jump onto the 5.x bandwagon by giving them a known (relatively) good starting point. Quite a number of problems have been fixed since 5.0-RELEASE; CURRENT is now generally much more stable, and nobody is going to spend time updating 5.0 which is essentially an early access release. You have to decide for yourself if this machine is too critical to run CURRENT, in which case it's probably best off running STABLE or the latest 4.x release branch, or if you want to update it to CURRENT, follow the CURRENT mailing list, and update again at known stable development points. It looks like right now is pretty good if you want to jump. At any rate, thanks for your tenacity. We really do appreciate the contributions of everyone. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
On Wednesday 12 March 2003 10:37, Doug Ambrisko wrote: Wes Peters writes: | Or you can cheat and use a SmartBits-2000 like I did. It can send | exactly 148,800 packets per second, with very precise timing of the | inter-packet Soon we should be getting an Ixia. That'll certainly do the trick. That is, if they actually manage to deliver it before the SmartBits people buy them up and kill them off; they've done that with at least one other competitor. | So it seems to keep up reasonably well, but this is misleading. Use | -l to force the packets out as quickly as the card can generate them: | | -bash-2.05b$ sudo ping -i 0.01 -c 5000 -l 5000 204.68.178.2 | ... | 64 bytes from 204.68.178.2: icmp_seq=92 ttl=128 time=14.855 ms | 64 bytes from 204.68.178.2: icmp_seq=93 ttl=128 time=14.880 ms | 64 bytes from 204.68.178.2: icmp_seq=4424 ttl=128 time=17.308 ms | | --- 204.68.178.2 ping statistics --- | 5000 packets transmitted, 95 packets received, 98% packet loss | round-trip min/avg/max/stddev = 11.929/14.520/17.308/0.682 ms | | Wow. The receiving side handled the first 93 packets and then rolled | over, recovering for only the last packet. (Look at the icmp_seq | numbers.) FreeBSD behaves similarly, but try the test on your own. | ;^) I don't see any difference between the rl and fxp tests using the same originating machine and dest machine. The dest machine has both rl and fxp You won't, this is a problem endemic to the PCI bus. The problems with the RealTek chipset mostly have to do with CPU load doing real-world work, not silly-bugger tests. This *is* why anyone who thinks they can make a real, reliable router by cramming a couple of PCI cards into a FreeBSD box is deluded. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Insecure PHP installation?
On Monday 10 March 2003 10:59, Doug Barton wrote: On Mon, 10 Mar 2003 [EMAIL PROTECTED] wrote: Hi all I know PHP is not in the base system, but I thought I could ask here anyway. You should have asked this on [EMAIL PROTECTED],org, and cc'ed the PHP maintainer, FYI. I have installed PHP on my FreeBSD 4.7 computer and did a find / -perm +0002. I could see that /usr/local/bin/pear is a script and world writable, isn't that a little dangerous? That's definitely bad, yes. Please use send-pr to file a problem report about this. I have PHP installed from the port on my system: -bash-2.05b$ pkg_info | grep php mod_php4-4.2.3 PHP4 module for Apache It does not seem to exhibit this problem: -bash-2.05b$ ls -l /usr/local/bin/pear -rwxr-xr-x 1 root wheel 5957 Dec 21 18:01 /usr/local/bin/pear Did you install from the package? If not, why not? If so, is your package different from mine or has your installation been changed after the fact? -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
On Monday 10 March 2003 08:47, Doug Ambrisko wrote: Hmm, I thought I had said benchmark in your environment. We have a closed box that is sort-of a router and a bridge. So your only inputs is really network traffic. That is what we tune the box for. So it would be interesting to see you kill it in 1s. Again our issue is PCI bus. Flood it with wire speed 64-byte packets and drive it into receive interrupt livelock. Yup, the PCI bus is (most of) the problem here too. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: High CPU usage when forwarding packets
On Saturday 08 March 2003 05:08, Bruce Cran wrote: Thanks, I added kern.ipc.nmbclusters=8192 to /boot/loader.conf and the messages have stopped. I have also learnt that the high CPU usage is simply because I'm trying to push 600KB/sec over an ISA bus, and lots of copying is going on. I'd like to get a PCI card and stop using the onboard lnc, but unfortunately the single PCI slot is already taken up by other other NIC. You need a PCI dual NIC, then. ISA network adapters suck, as you've noted. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
On Friday 07 March 2003 09:16, Doug Ambrisko wrote: Wes Peters writes: | On Thursday 06 March 2003 15:02, Paulo Roberto wrote: | --- Bram Van Dam [EMAIL PROTECTED] wrote: | cheap they are they do their job fairly well. If performance | isn't an issue then go for it. | | I couldn't agree more. If you are just staying in 55 mph, you don't | need a Ferrari. | | It's not a ford vs. ferrari problem, it's that the ford only has | first gear, so you're doing 45 mph at redline and in grave danger of | blowing the heads off continuously. | | The problem with the RealTek chipset is that the packets have to be | aligned on some completely stupid boundary in memory (32 bytes if | memory serves). The driver code ends up copying the packet data to a | tempory buffer before sending it for almost every outgoing packet, | which is just totally stupid. [snip] | JUST SAY NO. Actually, test and the pick the fastest tends to be better. Since D-Link dropped their good 4-port card for a broken one which they discontinued we had to scramble for a solution. Our test bed was a basically a server machine tied to a router/bridge like thing with 4 clients. We'd run tests all to the server, all to the clients and everything at once. This illustrated the HW issue with the new D-Link 4 port card since none of their supported drivers and OSes could get over 20Mbs. We had 100FDX links to each client and a Gig link to the server. FreeBSD could peak to 40Mbs if I recall right and we were told FreeBSD must be broken even though it was faster then their supported OSes (Windows 1Mbs)! To be honest I did fix a bunch of bugs in the FreeBSD driver. Using this framework we had a bridge riser card that we could plug 4 various PCI ethernet cards. We tested the dc(4), fxp(4), rl(4), sis(4) cards of various types and with our motherboard and CPU the rl(4) 8139C chips where the fastest via netperf with a significant margin. I went into the test biased against Realtek but couldn't justify not using them after testing. Now we are using the 8100L chip so we have a pretty simple design. You did something truly bizarre. I've tested similar cards on many machines ranging from K6-2 400MHz to P4 2.4GHz and the RealTek performance has always been at or near the bottom of the heap. On the slower processors, the overhead of aligning packets shows heavily, but it can be noticed on any system. A number of the chips folded into the dc(4) driver are horrible and perform right down there with the RealTek, but a few are fairly good. The 3com 3c905s are generally quite good using the xl(4) driver, as are the Intel EEPro's using fxp. I've read of others struggling with both but never encountered this myself. I tend to be quite conservative about throwing random versions of FreeBSD at systems, though, and many of those complaints come from people at various points on -stable, rather than a known release point. So I'd say given a sufficiently fast CPU and memory the Realteks work pretty darn good. For a sufficient engine RPM, that escort will do 85 MPH in first gear, too. ;^) The speed win could be do to a slightly better bus interface. That was the problem with the newer D-Link 4 port card in that during RX the chip would take over the PCI bus for a lng time. Yup, they're complicated beasts. For someone who is not going to work on the drivers themselves but wants performance, I suspect buying whatever you can get in bulk for eight dollars is not an optimal strategy. A sufficiently fast CPU in our case is 700Mhz Celeron which is a lot different then pushing 100Mbs with a P5 133Mhz. Our bigger issue is bus performance on a 32bit/33Mhz bus with 3, 4-port cards. To date we haven't had any trouble with them and we've shipped a bunch. Give me 1 second and I can easily bring any of your systems to their knees, regardless of which cards you have installed. Everything is relative. Were you watching the system load while performing your testing? Was the cpu doing anything but routing? Is it required to for your application? These and many others are all important questions, and tend to have different answers for every application. For a desktop workstation with undemanding network application requirements (email, web browsing, occasional software updates) RealTek or any other card that successfully attach to the network and correctly autonegotiate with your hub (shudder) or switch is fine. Even a RealTek. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
On Friday 07 March 2003 13:17, Doug Ambrisko wrote: Thierry Herbelot writes: | | and the avid reader asks : so, now, what NIC are you really using ? | (I too have used with great pleasure quite a bunch of DLink-DFE-570), | and I was leaning towards using the newer DFE-580 4-port on another | project ...) PHK found a 4 port fxp card that was priced pretty good. I don't know how successful he has with them. We're using a 2-port EEPro with 82551 chips with the two ports connected with relays and a watchdog; we get excellent throughput in our testing so far. I don't recall the vendor, it is Ad-something. I can look them up Monday if you email me about it then. I think they make a 4-port 551 card without the relays as well, but I don't know about pricing. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
On Thursday 06 March 2003 15:02, Paulo Roberto wrote: --- Bram Van Dam [EMAIL PROTECTED] wrote: cheap they are they do their job fairly well. If performance isn't an issue then go for it. I couldn't agree more. If you are just staying in 55 mph, you don't need a Ferrari. It's not a ford vs. ferrari problem, it's that the ford only has first gear, so you're doing 45 mph at redline and in grave danger of blowing the heads off continuously. The problem with the RealTek chipset is that the packets have to be aligned on some completely stupid boundary in memory (32 bytes if memory serves). The driver code ends up copying the packet data to a tempory buffer before sending it for almost every outgoing packet, which is just totally stupid. There are dozens of other chipsets in the same price range as the RealTek's that don't require this stupidity, most of them supported by the dc(4) driver. Track down a couple of different cards, try them out on your own, and they buy a bunch of them. Belkin is selling a card based on the Intel (formerly DEC) 21143 for $15; if you can find them in bulk you can probably get them for $8-9. Those are a LOT better than the RealTek cards. JUST SAY NO. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C coding editor
On Saturday 01 March 2003 03:12 pm, Giorgos Keramidas wrote: On 2003-02-28 07:52, Terry Lambert [EMAIL PROTECTED] wrote: Wes Peters wrote: No, but your editor really ought to be able to interpret tab stops correctly at like 0.5 in increments. Code editors on the Mac have been doing this for years. If editors like this were more common, it would be a lot easier to justify use of proportional fonts in coding editors. I don't think anyone really cares how many characters there are after a tabstop, so long as the visual layout is uniform to the left of the code. If you use indentation, this still works, no mater what your font, as long as there are fixed indentations per tab (IMO). True, true. The printouts of code created with literate programming tools like tangle/weave and their many offsprings are very easy to read if indentation has constant width. The font of the program text isn't really important, as long as nesting isn't horribly broken by someone who typed the wrong number of spaces instead of just hitting tab. But the font of the program text *is* important if you are considering readability. We use variable-width fonts for books and printed matter because they are easier to read than monospaced fonts. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C coding editor
On Friday 28 February 2003 07:52, Terry Lambert wrote: I blame this on people unsuited to writing software getting CS degrees and/or programming jobs, because they think that that's where the money is at. Luckily, they later find out that salary is a matter of merit, much more than it's a matter of having paper credentials, and if you haven't blown at least one test because you wer in the CS lab until 5AM playing with the new Retrogrpahics cards and high persistance phosphor tubes, and slept through your alarm, well... 8-) 8-). Oh, the good old days. Very soon, these people end up finding gainful employment asking people if they would like fries with that. Just like RMS wants them too. But wait, he wants you and me to be doing that too... I personally attribute the majority of very long lines to deep structure element nesting, which everyone seems happy to do these days, and long_variable_names_which_try_to_be_meaningful_but_fail. Hell, you can't add two of those together, even with a +=, and not wrap the line at least once... Ditto. I have a single function, the critical path of the Xylan switch control software, that fits nicely in 80 columns. It has a McCabe's complexity number of 360, the highest I've ever heard of. According to McCabe, anything beyond 25 is not understandable by human beings and it's a logarithmic scale. No, but your editor really ought to be able to interpret tab stops correctly at like 0.5 in increments. Code editors on the Mac have been doing this for years. If editors like this were more common, it would be a lot easier to justify use of proportional fonts in coding editors. I don't think anyone really cares how many characters there are after a tabstop, so long as the visual layout is uniform to the left of the code. If you use indentation, this still works, no mater what your font, as long as there are fixed indentations per tab (IMO). Precisely. The GNU enscript pretty-print function does a relatively nice job of this, but it ends up mangling the gnu-style continuation line indents. Solution? Don't do continuation lines. At all. Just print your code 1-up in 7 point Palatino and it fits nicely on Letter-size paper. For those of us weird enough to print code, that is. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED]http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C coding editor
On Wednesday 26 February 2003 09:57 am, Jason Andresen wrote: Wes Peters wrote: Seriously, limiting your programming for a lifetime to 80 columns because you couldn't figure out how to make some grotty old dot matrix printer do 8-point printing a decade ago really isn't all that smart, is it? Even if I never have to print out on a printer like that, who's to say nobody else is? You will no doubt turn people away if they open up your code in their favorite programming editor and all of the lines wrap a few characters. Worse if they are already at the maximum size their screen/eyeballs can support. I rejected programming to the least common denominator in equipment. You should try it too, it's incredibly liberating. The legions of programmers under the age of 25 holding up 80x25 consoles as some sort of mantra is just weird, and the idea of cramming a video card capable of a million 3d triangles per second into a machine so some dumbass can use it as a vt220 just makes me roll on the floor. Of course you probably didn't live through paying $75,000 for workstations with a tenth that 3D performance. I'm still disappointed at programming editors that can't make sense of normal typefaces and have to be used with monospaced fonts. Same for email, but that's a different argument. I find that monospace fonts are quite nice in programming on occasion when you want to line up output or just nicely format blocks of text. My code almost never lines up output for formats blocks of text. For some odd reason, the program on the other end of the socket doesn't really care what my source code looks like, so I make it readable and understandable by using horizontal and vertical whitespace in ways that separate the code into small, visually recognizable chunks that implement a single idea at a time. What about when someone opens up your project with a different font and all of the comments and blocks of code are all scattered across the screen in some haphazard looking mess? I use what is mostly likely a different font from what you use for coding every day. I do all of my coding on FreeBSD, most of it in Emacs, and use lucidatypewriter (less and less) or luxi mono for most of it. My own code often goes as wide as 120 characters because anything more than that won't fit comfortably on a 1024 pixel wide screen, which is a much better default than 80 columns these days. Visual distinctiveness and effective use of whitespace can be invaluble in helping people understand your code (or understanding other people's code). That's why people have settled on a format they can reproduce in almost all instances. Very few compilers accept code with formatting markup beyond ^Ls and TABs. You can't compile a Word document. No, but your editor really ought to be able to interpret tab stops correctly at like 0.5 in increments. Code editors on the Mac have been doing this for years. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED]http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Monitoring changes in extended attributes?
On Monday 24 February 2003 07:25, Robert Watson wrote: On Wed, 12 Feb 2003, Kevin Fogleman wrote: Is there an existing way to monitor the entire filesystem for changes to any file, particularly changes in extended attributes? I'm looking to write a program that builds an index of all user-accessable extended attributes for every file in the filesystem and then updates that index in real time according to modifications to existing files' attributes, creation of new files and deletion of files. I've read over the documentation for kqueue, but some things were left unclear. For example, it appears that kqueue needs a file descriptor for each file that one would want to monitor, making any large-scale file monitoring impractical. Is there any other way in FreeBSD to be notified of file modifications in a way that would allow one to monitor the whole file system or large portions of it? Also, I'm not very knowledgable about file system conventions, so I'm wondering how one would detect the creation of new files? I don't really need to know whether a particular attribute changed, but rather just whether any of them changed. BTW, I have posted this question earlier to freebsd-questions, but nobody answered and, judging by the content of the other questions on that list, I thought that my question would be more appropriate here. Currently, you can monitor particular files for meta-data changes, which include extended attribute modifications, and you can monitor directories for changes, which might include the addition of a new name (and hence possibly a file). However, currently there's no way to monitor at the granularity of a file system for events such as Some EA changed or A new file was allocated. I guess such primitives haven't generally been needed in the past, although I can certainly imagine scenarios where they might be used. Kqueue is the vehicle the two events I identified above can be monitored with, and it's certainly possible to imagine adding new event categories to monitor a file system for global events, assuming it's a local file system. However, then the question becomes Once I know that a file has been added, how do I find it, which I would guess generally results in a recursive search, at which point I suspect you might as well just re-search the entire fs once in a while anyway. The functionality you're looking for sounds a bit more database-esque than in line with a traditional file store. BeFS (in BeOS) had some interesting capabilities along these lines. It seems to me that the ability to monitor a mounted filesystem for inode changes would be a big plus. If you need to get from the inode number back to the filename or directory entry, you could either search or maintain an in-memory cache of the directory structure. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bootp_subr.c forget it.
On Monday 24 February 2003 08:48 am, Terry Lambert wrote: omestre wrote: Of course that the FreeBSD code will not have my name, and company! That is the code that i did for MY company! What i wanted was share is the solution! If you will supress my name or everything, is not my problem. If i change a bit, a letter... in a source code, i will allways put my name. Not because the rights, but because the errors! Then i break the software, the errors are mine, this is justice. The license issues are very serious to the community. FreeBSD could not, in good conscience, rip off your code without giving you the credit you asked for in your patch. We have other ways of noting donations to the project as well. The primary one is the Obtained From: header in the CVS commit, where sponsored changes like this can be noted without affecting the copyright in any way. Please consider using this if it is sufficient for you and your employers needs. I think that the community would be willing to take responsibility for any bugs that it was willing to commit to the source tree. Yes, we are, and we are also very willing to give credit. We don't want to create anymore licensing nightmare than we already have if we can avoid it. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED]http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C coding editor
On Friday 21 February 2003 04:21 am, Clemens Hermann wrote: Hi, what are your favourite editors for coding C? While vi on the first terminal, cc on second and runs on the third is fine for very small things I doubt it is the way people do it here. Terminal? You have heard of this really cool thing called windowing software? ;^) I completely utterly fail to understand why some young developers attach some sort of romance to writing code on an 80x25 screen, when all the haxxors my age or older waited (or slaved away) for years, even decades, to get something better and more flexible. I've seen vim, emacs/xemacs, and kdevelop all mentioned in this thread. I'd just like to point out that the first three have great advantages under X and the last runs exclusively on X (at least on UNIX it does). X is for programmers, too. Try it, you'll like it. You might even find a use for that mouse. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED]http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop
On Wednesday 19 February 2003 04:43, Vaclav Haisman wrote: man 2 abort -- Terry logout ~/tmpman 2 abort No entry for abort in section 2 of the manual Yeah, it's in (3). try _exit(2). Besides, this doesn't explain anything. I see I haven't asked any question in my previous post. So, why does FreeBSD behave different? Because it *is* different? If you want to catch a signal and be able to handle it, the other two are wrong, are they not? The idea here is to catch SEGV and be able to respond to it in some reasonable fashion. What that reasonable fashion might be is left up to the program, that's why we have signal handlers. You might for instance want to close open files or disconnect from a database connection. What if the file close or database socket close yeilds another SEGV? Do you want to just abruptly die, or do you want to at least be able to attempt to log this condition? You can always count the number of SEGVs you've handled with a static counter and modify your behavior accordingly. What would you like to see, a sigaction flag of SA_CRASHON2NDSIG that is set by default? (Ah, Wes, that software comedian.) -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: arc4random() range
On Tuesday 18 February 2003 22:36, Peter Jeremy wrote: I see this as a major advantage of arc4random() - if I want 32-bit random numbers I don't have to call random() twice and merge the results. I've never understood why random() was specified to return a '0' in the MSB. It probably had something to do with the PDP-11 architecture. This rings a bell, but I can't recall what it was. Greg Lehey might be able to help here, he has far better knowlege of the Good Old Days(tm) than I do. I'd ask Mike Murphy, the resident UNIX graybeard, but he's not in yet. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hi!Dear FreeBSD!
On Wednesday 19 February 2003 06:30, Terry Lambert wrote: Nik Clayton wrote: On Sun, Feb 02, 2003 at 10:37:21AM -0600, Stephen Hilton wrote: Why not base it on latitude and longitude, along with an email address and text fields to allow for some self expression of areas of interest etc...? A clickable map would be a nice interface for the database lookups with a max radius factor, but really is just icing on the cake. Please, no wheel reinvention. http://www.pm.org/groups/index.html None of those maps are clickable. They're actually just *tiny* PNGs of maps-with-pins-in-them, with no obvious correlation to real location data associated with PERL (e.g. number of pins is not equal to number of page entries, in most cases, and the pins for Columbs, Dayton, and other Ohio locations all pops up at the same pixel location, etc.). It's really unfortunate that no one seems to be willing to put out the server resources to do real GIS mapping, e.g. using the data specifications at: http://www.opengis.org/ Given that it looks like it's membership restricted to people who can pay, and that there are no decent Open Source rendering products: http://www.opengis.org/testing/product/index.php and that it's in the best interests of the commercial vendors to keep it this way, so as to not have to compete on the basis of innovation, people are unlikely to find that this is going to change very soon, unless someone who cares enough about maps to keep suggesting that people implement this actually sit down and build the map rendering software to do the job (hint: Stephen) The US DoD Defense Mapping Agency has transferred their database of the North American continent to a technology transfer company that allows you to download it in chunks, or order it on CD-ROM. The specifications for the data are publically available and quite easy to use, the basic data unit is a terrain elevation from the center of the earth at 1 meter intervals over a 1 degree by 1 degree square. (This is DTED, Digital Terrain Elevation Data; also available are features like rivers lakes, roads and buildings, in the Digital Feature Analysis Data or DFAD datasets.) The CIA has maps for most of the world available in the same format in their World DataBank, but so far doesn't seem interested in releasing theirs. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Binary security updates
On Sunday 16 February 2003 02:39, Colin Percival wrote: On december 25th, I released a first draft of a binary security update tool aimed at allowing people to track the security branches without keeping a source tree or recompiling; the response was generally positive, but as I pointed out in my announcement, there were several problems which needed to be fixed. I'm just about finished fixing up all those details, and I intend to release a new version soon and start publishing the necessary updates for i386 4.8-RELEASE when it comes out (not that I expect 4.8-RELEASE to include any security holes, of course ;). These would, of course, be freely available (although I might ask for donations to cover bandwidth costs if I get lots of traffic). Would any FreeBSD developer(s) be willing to help me with this? I'd very much like to have at least one person look over my code and give it some sort of stamp of approval; both for my own peace of mind and to make people feel more happy about using it. If you are willing to do the work, I'm certain we can track down some mirror sites willing to bear the traffic for you. We'll bring the efforts of the Donations Liason Officer, Michael W. Lucas, to bear on this. All you need to do is let him know what resources you will need. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Got X working with via driver ( Re: Another EPIA M 9000 update ) results (was Re: Lower power SMP boxes?))
On Monday 10 February 2003 17:57, Matthew Dillon wrote: Very nasty but I got X working with the via driver by dummying up libddmpeg (which is supplied along with via_drv.o on the VIA EPIA M 9000 CD). Basically I linked libddmpeg.a with a dummy program to pull in the required symbols and generated a new .so which does not link against libc.so.6. With the dummied up libdmpeg.so in place the VIA-supplied driver works. It complains a bit, but it works. http://apollo.backplane.com/FreeBSD/ I'll keep the page up unless VIA complains to me. I don't know why they would, though. How dare you sell our products for us! Stop it this instant! I certainly hope they're not that stupid. I'm going to get a couple of these as test machines in our lab. Thanks for going the extra mile on this (as always) Matt. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Missing commit bit [PATCH].
On Sunday 09 February 2003 19:20, clemens fischer wrote: Pawel Jakub Dawidek [EMAIL PROTECTED]: [about removing matt d. committer bit] If so, tell me now, please, what kind of reasons left, that can't be shown in public forum? i'd be satisfied with the reasons that _can be_ shown in a public forum, because anything else can't be but personal and thus contra- productive to the common cause(tm). Matt Dillon was removed from the ranks of committers for one simple reason: the Core Team asked him if he could in the future live up to the Committers Rules and he replied that he could not. We will do the same for anyone else. We hope anyone else who can't play by the rules will voluntarily resign rather than forcing us to take such action. Committers who break the rules but remain personally committed to meeting them are reminded in writing and occasionally by being suspended for a few days. The use of this mechanism has dropped off signficantly from when it was first implemented; I had hopes this meant the project was becoming a less adversarial place to work. Perhaps this can still come about. If you are a committer, this is a good opportunity to review the rules. If you are not a committer but are a contributor to FreeBSD, we welcome your input. We feel the rules are fair and necessary to useful interactions in a group as large as the FreeBSD community has grown. Please let us (the Core Team) know if you see anything in the Rules that is somehow unfair to individuals or groups, or otherwise objectionable. http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/rules.html -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: anyone working on a new file system metaphor?
On Fri, 10 Jan 2003 11:03:15 -0500 Kieren MacMillan [EMAIL PROTECTED] wrote: Hello, all you BSD hackers! A major change to the file-folder-desktop metaphor is long overdue, and it seems to me that FreeBSD -- with Mac OS X as a large and growing child -- is the perfect place to start the revolution... ;-) If anyone has seen Scopeware (http://www.scopeware.com), you'll know the kind of thing I'm thinking of: a universal indexing system where *any* file of *any* type in *any* location would be cross-referenced (using metadata as well as content where possible) in one or more filters or streams. Oddly enough, Evolution supports this concept for email. In addition to the usual support for mail folders and such, it has a virtual folder concept that allows you to group and view emails by sort/search criteria such as header contents. It's quite powerful; I use it for reviewing FreeBSD CVS commit messages and such quickly. Do you envision this as an actual new filesystem, or strictly as a user interface 'view' onto the filesystem? A filesystem with extensible attributes might be a good companion to such a system, where you can tag a file with one or more attributes, then sort and view the files by attribute. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: nsswitch help for you?
On Wed, 2002-12-25 at 06:54, [EMAIL PROTECTED] wrote: Quoting Danny Braniss [EMAIL PROTECTED]: what exactly do you want/need? danny Sorry, I'll try to get as specific as I can with my currently limited knowledge of the FBSD source code. Basically, I would like to know where I can find information on the nsswitch protocol (if that is even such a thing): perhaps a document or standards paper? The closest I've seen would be the nsswitch.conf man page from Solaris or Linux. Read what functionality is provided, figure out how to make that work on FreeBSD, write up your ideas, hack some code, ask for reviews along the way. I'm certainl you'll find people who are interested. I will be downloading -CURRENT tomorrow so I can take a look at the current nsswitch code, but is there anything you know right off hand that would help me? Ick? ;^) While you're out digging up man pages and such, be sure to look up gethostbyname_r, getpwuid_r, etc.; we've been needed these reentrant versions for quite some time now. You will most likely find that a proper implementation will provide the _r versions of these routines then implement the static versions on top of the reentrant ones. I'm sorry for the incompetence and don't want to clutter -hackers mailing list any more than I have too, but I don't exactly know what types of questions to even really ask you yet. If there is any general type of information you have to help the learning curve of the kernel though, I'd appreciate it. There's a world of difference between incompetence and just starting out. Please feel free to pester me for advice, moral support, reviews, etc. I started filling out the complement of _r routines in the library several years ago and quit when I got to getXbyY_r because the existing code was so turgid and the task a bit too daunting for the time I had available. Helping you finish it would lift a large load from my FreeBSD psyche. :^) -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: I'm leaving the project
On Wed, 18 Dec 2002 22:01:26 +0100 Wilko Bulte [EMAIL PROTECTED] wrote: On Wed, Dec 18, 2002 at 11:19:20AM -0800, Matthew Dillon wrote: :Yes, we need to embrace the trolls and stop marginalizing them. The :Troll-man has been downtrodden for far too long, it is time for him to :step into the light of society and be accepted for what he is...assuming :they don't shrivel up and die in the light. I don't know about you, but :that's a risk I'm more than willing to take. : :-- : \ |_ _|__ __|_ \ __| Jason Andresen[EMAIL PROTECTED] Yes, we should pull the poor guy out of the closet, kicking and screaming if we must, for his own good :-) Stock up on tar and feathers.. ;) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message And, to quote one of the better TV commercials in the USA, get a rope! -- Where am I, and what am I doing in this handbasket? Wes Peters[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How can I post a pr when my IP can't be reverse-resolved?
Terry Lambert wrote: öÎ Àî wrote: [ ... Subject: ... ] You can't. The method I was about to start using was to post the patch to the mailing list, and then use the web send-pr to send the PR with a URL for the patch in the mailing list archives. This won't work because they disabled the web send-pr. I think the reason this was disable is some idiot was posting a lot of PR's that were not really PR's, and then filling in the mailing lists as contact (or whatever). I saw a lot of these right before they disable it. Exactly the reason. Probably, the correct thing would be to accept the submission, and pend it for review, before it became active as a real PR. This would require that a human look at the pending PRs, and make a decision. Oddly enough, the Core Team has discussed exactly this approach. It's a good idea. Are you volunteering to do (some of) the work? Either of you? ;^) Instead, what happened was the web submission form was disabled, letting whoever was trying to poison the ability to report problems win. Only partially. People with working mail systems can still report problems. People with non-working mail systems, or ISPs who are incapable of creating a proper reverse DNS entry, probably need to solve those problems before becoming tremendously worried about bugs in FreeBSD. Hint hint. Not very satisfying to me, either, since a lot of people are PR-blind to patches posted to the mailing list. Maybe you could also ask them to reenable web send-pr, as I did. Probably not gonna happen, it's just an invitation to abuse. Sorry. Bad people suck, the best we can do is cut our losses and move on. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: more kernel programming style questions
M. Warner Losh wrote: You are better off defining a series of macros that do proper bus_space_readN/bus_space_writeN for each of the fields in the register set. This will ensure that your driver works unaltered on other architectures. Directly accessing memory mapped devices is a bad idea. While it works on i386, there are some platforms that have special alignment constraints that the underlying hardware doesn't always follow. As an example, I/O devices on the SPARC architecture are almost always placed in an alternate address space which means they have to be accessed using different instructions (LDA/STA) than those that access memory (LD/ST). Attempting memory I/O to devices on SPARC is doomed to failure. It's a whole new (portable) world, folks... -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: none
Kirk Strauser wrote: At 2002-12-10T00:44:03Z, [EMAIL PROTECTED] writes: hi,sorry does Linux run with an AMD Athlon 1,2Ghz ? how? Dunno. Ask on a Linux mailing list. FreeBSD runs just great on it. Maybe you should try that? ;^) http://www.freebsd.org/ -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: finding unmatched quotes in shell scripts
Greg Black wrote: Lyndon Nerenberg wrote: | I've tried a number of syntax-colouring editors, to no avail. The quotes | (single, double, and back) *are* balanced, according to everything I've | thrown the script at. That's why I'm more interested in something that | can actually parse Bourne shell syntax (quiet Terry - I *know* what | you're going to say) and dump out what it thinks the parse tree looks | like. The problem isn't with the quotes being unbalanced, it's something | else that's making the shell ignore one (or more) of those quotes. Surely the simple thing is to put an exit statement in the middle of the script and see which half has the problem? Move the exit statement forwards or backwards in a binary search until the problem leaps out and hits you in the face. Or simply set -x at the beginning of the script? -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Arp and Route Commands
Karl Timmermann wrote:
Hello,
I'm new to the list and was hoping maybe someone could help me. These
commands work in Linux (and in this order), but not in FreeBSD/Mac OS X
as the arp and route commands are different:
arp -s 10.10.10.0 00:00:ca:13:4b:54 -i eth1
arp -s 10.10.10.0 00:00:ca:13:4b:54 -i eth1
route add -net 10.10.10.0 netmask 255.255.255.0 dev eth1
route add default gw 10.10.10.0 dev eth1
anyone know how i would change these commands to work with the FreeBSD
versions of arp and route?
Read the man pages carefully. The BSD TCP/IP stack has a single arp
cache and a single route table, so the network interfaces do not
need to be specified. In particular, with arp you specify only the
hostname and ethernet address. The route command you specify the
IP address or hostname of the router rather than the egress interface.
Your commands would become:
arp -s 10.10.10.0 00:00:ca:13:4b:54
route add -net 10.10.10.0 -netmask 255.255.255.0 {IP address of router}
route add default {IP address of router}
Please note that in general you don't want to set these by hand, but
rather use the rc.conf file.
--
Where am I, and what am I doing in this handbasket?
Wes Peters Softweyr LLC
[EMAIL PROTECTED] http://softweyr.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: finding unmatched quotes in shell scripts
Lyndon Nerenberg wrote: I've tried a number of syntax-colouring editors, to no avail. The quotes (single, double, and back) *are* balanced, according to everything I've thrown the script at. That's why I'm more interested in something that can actually parse Bourne shell syntax (quiet Terry - I *know* what you're going to say) /usr/src/bin/sh/parser.c? ;^) /not_the_terry -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Shrinking /(s)bin: A Proposal
Doug Rabson wrote: On Thursday 14 November 2002 6:45 am, M. Warner Losh wrote: % make NOSHARED=NO buildworld No patches necessary. We do this all the time at work, and it works fabulously. I do this for disk based systems that have / and /usr on the same file system too. To do it right for split root/usr installations requires a few patches though. The rtld and the libs required for /[s]bin need to move to / and compat symlinks created from /usr. A suitable crunchgen'ed binary for /recover would be useful too. Time to bring back /lib? -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Shrinking /(s)bin: A Proposal
Justin Wojdacki wrote: Rich Morin wrote: My spouse had the problem of creating a bootable copy of A/UX on a single floppy. She decided to write a doitall program that had functionality from a number of small commands. This amortized the overhead a great deal. If you're seriously interested in this, take a look at busybox. http://busybox.lineo.org Not sure how compatible the licensing is for FreeBSD base software though. BusyBox is essentialy what crunchgen does, though with crunchgen you get the full-featured FreeBSD versions of commands, not the stripped-down sometimes functionless versions in BusyBox. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD performing worse than Linux?
On Wed, 28 Nov 2001 00:41:18 -0700 Nate Williams [EMAIL PROTECTED] wrote: FWIW, I'm seeing this as well. However, this appears to be a new occurance, as we were using a FreeBSD 3.X system for our reference test platform. I recently updated it to FreeBSD 4.4-RELEASE, and I'm getting nothing but complaints about broken connections, poor performance, and very inconsistent results. They are now considering installing Linux on this box with the hope that they can get consistent results. (Unfortunately, FreeBSD 3.X is out because I convinced them that we needed to upgrade to 4.X due to security measures, so we can't go back.) And they somehow think any variant of Linux is going to be better on this point? My recent experience with Linux would say otherwise, but that was on an Intel Architecture Labs variant that is somewhat out of date, too. Note, some of the performance issues were made better by disabling the TCP newreno implementation, but it's still poor and very inconsistent for hosts not on the local network, while the Linux box next to it gets much more consistent results. Ick. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: OT: firewire slugs available ?
John Kozubik wrote: In the near future I will be doing some research and development with IEEE 1394. Such that I will be requiring a _large_ number of firewire devices. It is not within my budget to purchase 63 x 4 cameras. Firewire CD-Rs or DVDs would be less expensive than cameras, wouldn't they? So I was trying to think of the cheapest possible IEEE 1394 device - if worst comes to worse I could just buy 252 of those ... again, not very practicle. IEEE 1394 chipsets, however, are about $8.00 each. Has anyone seen IEEE 1394 slugs - devices that perform basic functionality (in terms of participating on the bus) but not much else ? (presumably, if these devices exist, they were developed for just this type of development) Does anyone make a firewire mouse? ;^) You might want to look at one of the embedded firewire SDKs; using some of the sample code you should be able to produce 300 boneheaded firewire devices for very low cost after the purchase price of the SDK. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: What is VT_TFS?
Terry Lambert wrote: Poul-Henning Kamp wrote: *I* worked at TFS, I even kept ref.tfs.com alive after Julian went AWOL. I'm well aware of your checkered past... 8-). I guess Julian might pipe up now about the use of the acronym AWOL... Now, remind me again why historians are so picky about primary sources and secondary sources for historical information... That would be... Dennis Ritchie? 8-) 8-). Are we done now ? I guess... (Apart from Adrians story of course :-) If you think you can beat it out of him... I think we'd all like to sit around the camp fire and listen to it, while stroking our long grey beards... Do I have to grow my beard as long as Groggy's now? I'd better get started... -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Routing Performance?
Leo Bicknell wrote: On Mon, Sep 03, 2001 at 06:01:04PM -0600, Ronald G Minnich wrote: you do know that API just layed off (almost) all their alpha people, right? alpha is dead. Thank compaq any time. ron (who owns 112 Compaq Alpha boxes, and 16 API CS20s) No I didn't. That's really sad. I wonder if the impending Hewlett-Compaqard merger will hasten the Alpha into its grave. The King is Dead, Long Live the King! -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: wireless nic recommendations
Warner Losh wrote: In message [EMAIL PROTECTED] Wes Peters writes: : I've had no problems with this card, it is currently reaching about 6.5 : miles without an amplifier, using a 24 dB fruit basket antenna on the : roof of my house. What does the other end have? An omni antenna, Aironet commercial access point, and a 1w amp. Standard commercial fare, if rather expensive. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: wireless nic recommendations
Dan Cox wrote: Here is my situation. My house can't get DSL or cable. Our neighbors who live 20-30 feet away do have DSL and have agreed to share the connection. To make a long story short we have successfully set up a wireless LAN for the two houses, we've been using a windows laptop to test the connection. I would like to find out what wireless NIC's are compatible with freeBSD or some recommendations. I have a wireless ISP, my connection to the internet is a Cisco/Aironet: an0: Aironet PCI4800 port 0x6700-0x673f,0x6600-0x667f mem 0xe1001000- 0xe100107f irq 12 at device 13.0 on pci0 I've had no problems with this card, it is currently reaching about 6.5 miles without an amplifier, using a 24 dB fruit basket antenna on the roof of my house. The throughput is sufficient to hit my 300 Kbps band- width limitation enforced at the access point 24x7. The initial speed tests performed by the ISP showed speed consistent above 1,000 Kbps. You should have little problem with speed going between two houses. The Cisco cards are pretty expensive compared to other brands. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel Symbol Question
Tabor Kelly wrote: Which source file(s) are the kernel symbols defined in? By symbols I mean the symbols that the nlist() man page refers to. Let's see... The nlist() function retrieves name list entries from the symbol table of an executable file (see a.out(5)). In the case of the kernel, that would be the kernel you booted, typically /kernel. Besides the source files, is there any other place that the symbols (their names and meaning) are documented? The section 9 man pages. Actually, you're lucky if they're documented in the source... -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gethostbyXXXX_r()
Richard Seaman, Jr. wrote: On Sat, Aug 04, 2001 at 12:04:02AM -0600, Wes Peters wrote: Alfred Perlstein wrote: * Alexander Litvin [EMAIL PROTECTED] [010803 09:54] wrote: Are there any plans of making gethostbyname_r() and gethostbyaddr_r() available in FreeBSD? May be somebody already has them almost ready to be commited? Or are there any considered wrong way to go? The reason I'm asking is that I actually have a local patch implementing them here (only for DNS for now). Is it good idea to put some effort to finalaze it and submit a PR? Or I'd better not waist time on that? Please complete it, let me know when you submit the PR i'll try to get it integrated. I'll be happy to take a look at it too. I did a lot of the _r routines we have now, in some cases simply documenting ones that were there, but halted when I got to gethostbyX_r and the passwd and group variants, because they were too fugly to tackle at that time. I'll get back to the remainder someday, when I have the time, unless you beat me to it. There are some gethostby_r, getnetby_r, ... etc routines in the linuxthreads port (/usr/ports/devel/linuxthreads/files). These came from the original linuxthreads package, and have no copyright on them. I never researched the copyright status of them, but I don't think they are GPL, though you might want to do further research on their history if you use them. If they're just mutex-protected variants, I haven't bothered to create any of those. I guess they might be of use to somebody, but I very much wanted to create _r routines that were implemented properly, not just wrap the non-_r routines in a mutex, which is bass-ackwards. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
