Re: My wish list for 6.1
Robert Watson wrote on Sat, Dec 31, 2005 at 07:12:23AM +: On Fri, 16 Dec 2005, Avleen Vig wrote: On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote: 2. SMP kernels for install. Right now we only install a UP kernel, for performance reasons. We should be able to package both a UP and SMP kernel into the release bits, and have sysinstall install both. It should also select the correct one for the target system and make that the default on boot. If people are concerned about performance, I benchmarked a 6-beta kernel SMP versus UP on a socket 939 Opteron. If those results are accurate, there's no real reason not to just use an SMP kernel on default install? This is an old thread that I'm just catching up on, but I figured I'd chime in anyway: you have to be really careful benchmarking across CPU types and configurations, as the performance characteristics of important insturctions differ a lot across hardware variations. For example, the performance of atomic operations, used to synchronize between CPUs, varies significantly by CP, bus configuration, etc. On modern opteron hardware, the performance of inter-CPU synchronization instructions is blindingly fast. On modern Xeon P4 hardware, it is incredibly slow. Well, my runs included P4s and P4-based Xeons, and hyperthreading, too. The core of the problem here is that while my parallel benchmarks are partly system-call exercising, I use apache over localhost and zero-spaced files to get the disk and network out of the equitation. I think I have a solid framework in place to run parallel benchmarks and see the tradeoffs involved, but I need to fill it with activity that exercises what we want to see. Still, I bet that my measurements are good enough to label the SMP kernel defaultable for FreeBSD installations, from a performance standpoint. After all, I *do* test parallel activity, CPU-intensive and systemcall-intensive and various mixes thereof. Remember that those people who do a lot of parallel activity and hence would suffer from the additional locks in the SMP kernel are very likely to have a SMP system, dual-cores or at least hyperthreading in first place. On the other hand, people who use very low-end hardware to do demanding tasks are very likely to build their own kernel anyway. Software optimized for the Opteron will often perform much slower on Xeon P4 hardware as a result. P3 hardware tends to behave a lot more like Opteron in terms of speed of insturctions relating to disabling interrupts, where on P4 Xeon they are proprtionally much slower. The critical section optimizations made by John Baldwin, and the movement to critical sections in UMA and kernel malloc that I made, made a big performance difference on Xeon P4 hardware, but relatively little difference on Opteron. One thing I noticed is that anything P4-based is very sensitive to spinlocks being placed on the same cache line as the data it protects. Putting a lock into a struct without cache-line crossing padding means doom for the P4-based/netburst CPUs (I'm sure it's not a good thing for Opterons either but they don't seem to mind that much). Martin -- %%% Martin Cracauer cracauer@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Fri, 16 Dec 2005, Avleen Vig wrote: On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote: 2. SMP kernels for install. Right now we only install a UP kernel, for performance reasons. We should be able to package both a UP and SMP kernel into the release bits, and have sysinstall install both. It should also select the correct one for the target system and make that the default on boot. If people are concerned about performance, I benchmarked a 6-beta kernel SMP versus UP on a socket 939 Opteron. If those results are accurate, there's no real reason not to just use an SMP kernel on default install? This is an old thread that I'm just catching up on, but I figured I'd chime in anyway: you have to be really careful benchmarking across CPU types and configurations, as the performance characteristics of important insturctions differ a lot across hardware variations. For example, the performance of atomic operations, used to synchronize between CPUs, varies significantly by CP, bus configuration, etc. On modern opteron hardware, the performance of inter-CPU synchronization instructions is blindingly fast. On modern Xeon P4 hardware, it is incredibly slow. Software optimized for the Opteron will often perform much slower on Xeon P4 hardware as a result. P3 hardware tends to behave a lot more like Opteron in terms of speed of insturctions relating to disabling interrupts, where on P4 Xeon they are proprtionally much slower. The critical section optimizations made by John Baldwin, and the movement to critical sections in UMA and kernel malloc that I made, made a big performance difference on Xeon P4 hardware, but relatively little difference on Opteron. All this seems to suggest that when comparing UP and SMP, it's useful to do it on nice opteron hardware, but also on P4 Xeon to prevent making decisions based on platform-specific properties. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Arne Schwabe writes: The emulation or whatever it was was set in the BIOS. And it worked in the BIOS. Worked when the OS got up to sysinstall, too. Just wouldn't work for the loader. Luckily, I didn't need to do anything but wait for it to boot, but I figured the BIOS was laughing at me behind my back... Same here with an ASUS A8V Deluxe. I have a similar problem with an ASUS P4something and possibly a P3. However, I have been told (it's in the archives) this may be a known problem with the BIOS/ASUS firmware, Robert Huff ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Kris Kennaway wrote on Sat, Dec 24, 2005 at 12:35:47PM +1030: Martin Cracauer wrote: I tried to model different worklods. The parallel part of my benchmark suite has CPU-heavy processes, short plain http, php, long plain http and mixtures thereof. None of these showed the SMP kernel to be an overall disadvantage on a one-processor system. What you want is to find a real-world workload that exercises a lot of mutexes. These exist, and they'll see the most pessimization from running SMP kernel on UP. Well, I would be thankful for some ideas. I'd like to develop my benchmark suite from a pure hardware testing platform into one which can be used to measure improvements in SMP kernels. However, I am fully aware that what I am doing now (CPU loaders, and small and big http over localhost, make -j x) doesn't cut it. If you want to keep hardware out of the loop, things become hairy. Martin -- %%% Martin Cracauer cracauer@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Matthew D. Fuller wrote: On Tue, Dec 27, 2005 at 12:57:58AM +1030 I heard the voice of Kris Kennaway, and lo! it spake thus: Perhaps a BIOS option. I've never encountered a system with USB keyboard that did not work in the loader. The emulation or whatever it was was set in the BIOS. And it worked in the BIOS. Worked when the OS got up to sysinstall, too. Just wouldn't work for the loader. Luckily, I didn't need to do anything but wait for it to boot, but I figured the BIOS was laughing at me behind my back... Same here with an ASUS A8V Deluxe. Arne ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Tue, 27 Dec 2005, Kris Kennaway wrote: Matthew D. Fuller wrote: On Mon, Dec 26, 2005 at 02:15:52PM +1030 I heard the voice of Kris Kennaway, and lo! it spake thus: The loader groks it just fine when you choose the 'boot with USB keyboard' boot menu option ;-) How can I choose a menu option in the loader when the keyboard doesn't work in the loader? :p Perhaps a BIOS option. I've never encountered a system with USB keyboard that did not work in the loader. I'm going to be putting a few more workstations together in the next few days, likely using PCBSD. I will twiddle every option and report back. Charles Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
My wishes are: - Get MIPS arch working (plenty of MIPS based SoC in the market) - NUMA support (see what Solaris did or is doing), - Fold IMUNES changes in to the FreeBSD tree, - rwlocks (has this been done already?), - DDB MP support - Make ULE default. Extend ULE to support per Jail CPU time slices (Solaris does this already with zones - way too cool). - native PCI-E support with QoS - 802.11 support for VAP and Mesh Networks (already available?) - make base (off-the-box) performance the best among all OSs. Wish everyone a great 2006. Ray. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Mon, Dec 26, 2005 at 02:15:52PM +1030 I heard the voice of Kris Kennaway, and lo! it spake thus: The loader groks it just fine when you choose the 'boot with USB keyboard' boot menu option ;-) How can I choose a menu option in the loader when the keyboard doesn't work in the loader? :p -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Matthew D. Fuller wrote: On Mon, Dec 26, 2005 at 02:15:52PM +1030 I heard the voice of Kris Kennaway, and lo! it spake thus: The loader groks it just fine when you choose the 'boot with USB keyboard' boot menu option ;-) How can I choose a menu option in the loader when the keyboard doesn't work in the loader? :p Perhaps a BIOS option. I've never encountered a system with USB keyboard that did not work in the loader. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Tue, Dec 27, 2005 at 12:57:58AM +1030 I heard the voice of Kris Kennaway, and lo! it spake thus: Perhaps a BIOS option. I've never encountered a system with USB keyboard that did not work in the loader. The emulation or whatever it was was set in the BIOS. And it worked in the BIOS. Worked when the OS got up to sysinstall, too. Just wouldn't work for the loader. Luckily, I didn't need to do anything but wait for it to boot, but I figured the BIOS was laughing at me behind my back... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Matthew D. Fuller wrote: On Tue, Dec 27, 2005 at 12:57:58AM +1030 I heard the voice of Kris Kennaway, and lo! it spake thus: Perhaps a BIOS option. I've never encountered a system with USB keyboard that did not work in the loader. The emulation or whatever it was was set in the BIOS. And it worked in the BIOS. Worked when the OS got up to sysinstall, too. Just wouldn't work for the loader. Luckily, I didn't need to do anything but wait for it to boot, but I figured the BIOS was laughing at me behind my back... What happens if you turn it off? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Tue, Dec 27, 2005 at 01:28:23AM +1030 I heard the voice of Kris Kennaway, and lo! it spake thus: Matthew D. Fuller wrote: The emulation or whatever it was was set in the BIOS. And it worked in the BIOS. Worked when the OS got up to sysinstall, too. Just wouldn't work for the loader. What happens if you turn it off? Then it still didn't work in the loader, and wouldn't work for the BIOS either (so I had to plugin a PS/2 keyboard to turn it back on). I don't think I let it boot long enough to see if the keyboard worked in sysinstall in that case; I presume it would. And the system's in production now, so I can't really fiddle with it anymore. It's got a Biostar (blech!) Socket A motherboard. ACPI APIC Table: VKT400 AWRDACPI http://www.biostar.com.tw/products/mainboard/board.php?name=M7VIG%20400%20(7.x) -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Kris Kennaway wrote: On Fri, Dec 16, 2005 at 10:34:09PM -0800, Avleen Vig wrote: On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote: 2. SMP kernels for install. Right now we only install a UP kernel, for performance reasons. We should be able to package both a UP and SMP kernel into the release bits, and have sysinstall install both. It should also select the correct one for the target system and make that the default on boot. If people are concerned about performance, I benchmarked a 6-beta kernel SMP versus UP on a socket 939 Opteron. If those results are accurate, there's no real reason not to just use an SMP kernel on default install? Just because it didn't manifest on this workload, doesn't mean it doesn't on others. I think this is the point :) Hm, how about this (similar to what Linuxes do): Use an SMP kernel for the installation boot, so that the install scripts can discover the SMP machines. Have two GENERIC kernels built and packaged, UP and SMP. The install scripts then install the kernel matching the absent or present SMP (like Linux distros do). Probably with an option of a manual override through a menu. Maybe better yet, install both (or allow to install both) and allow to choose the one booted through a sysinstall menu. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
I'm missing the start of the thread, so perhaps I can just cut in here. I'm to the point at home and work where I've got more USB keyboards than PS2. It seems like even my old boxes support getting into the BIOS and everything via USB keyboards... You all know where I'm going... Whenever I want to install FBSD, I have to dig up a clunky old PS2 keyboard. Not the case with Winderz, NetBSD, OpenBSD, Linux, etc. In fact, I'm pretty sure 4.11 can be installed with a USB keyboard. I may be imagining that though... Back to lurking, C ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Sun, Dec 25, 2005 at 01:46:15PM -0500 I heard the voice of Charles Sprickman, and lo! it spake thus: In fact, I'm pretty sure 4.11 can be installed with a USB keyboard. I may be imagining that though... Well, I'm pretty sure I didn't imagine installing 6.0 last month with a USB keyboard. Of course, the loader didn't grok it, but... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Matthew D. Fuller wrote: On Sun, Dec 25, 2005 at 01:46:15PM -0500 I heard the voice of Charles Sprickman, and lo! it spake thus: In fact, I'm pretty sure 4.11 can be installed with a USB keyboard. I may be imagining that though... Well, I'm pretty sure I didn't imagine installing 6.0 last month with a USB keyboard. Of course, the loader didn't grok it, but... The loader groks it just fine when you choose the 'boot with USB keyboard' boot menu option ;-) Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On 21 Dec 2005, at 16:01, Juhana Tahvanainen wrote: how about: FreeBSD-Handbook-General (guaranteed to work with all FreeBSD systems, doesn't include stuff in FreeBSD-Handbook-BRANCH.x) FreeBSD-Handbook-4.x (guaranteed to work with 4.x branch, doesn't include stuff in FreeBSD-Handbook-General) FreeBSD-Handbook-5.x (guaranteed to work with 5.x branch, doesn't include stuff in FreeBSD-Handbook-General) FreeBSD-Handbook-6.x (guaranteed to work with 6.x branch, doesn't include stuff in FreeBSD-Handbook-General) FreeBSD-Handbook-General is basically what we have now, and it sucks to maintain. Seriously though, all the interested people are on doc@; this discussion should be moved there. Ceri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Martin Cracauer wrote: I tried to model different worklods. The parallel part of my benchmark suite has CPU-heavy processes, short plain http, php, long plain http and mixtures thereof. None of these showed the SMP kernel to be an overall disadvantage on a one-processor system. What you want is to find a real-world workload that exercises a lot of mutexes. These exist, and they'll see the most pessimization from running SMP kernel on UP. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
i think you got this one wrong. what FreeBSD-Handbook-General should include: everything that spans through all FreeBSD releases i.e. # rm -rf / (that is guaranteed to work in all FreeBSD systems) but if some future release stops supporting this, then its removed from FreeBSD-Handbook-General and moved to FreeBSD-Handbook-BRANCH.x (to all branches that supports this). ---J On Wed, 21 Dec 2005, Matthew D. Fuller wrote: On Wed, Dec 21, 2005 at 06:01:37PM +0200 I heard the voice of Juhana Tahvanainen, and lo! it spake thus: how about: FreeBSD-Handbook-General is rather fixed once ready, only maintenance needed is when some future release doesnt support something anymore, that is removed and moved to FreeBSD-Handbook-BRANCH.x. Difficult to manage. You have to remember or know which branches to backport stuff to, and you can't then say OK, we won't bother with 3.x anymore, but Handbook-3.x will remain around not needing further work for people using it, as future changes might not get pushed back. It would probably be easier using something like marked sections in a single handbook to separate out version-specific stuff from more general stuff; that way, at least it's all in one place, and you could just generate handbooks for any given branch off one source. Of course, it can get ugly to look at, too.. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Kris Kennaway wrote on Sat, Dec 17, 2005 at 03:01:09AM -0500: On Fri, Dec 16, 2005 at 10:34:09PM -0800, Avleen Vig wrote: On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote: 2. SMP kernels for install. Right now we only install a UP kernel, for performance reasons. We should be able to package both a UP and SMP kernel into the release bits, and have sysinstall install both. It should also select the correct one for the target system and make that the default on boot. If people are concerned about performance, I benchmarked a 6-beta kernel SMP versus UP on a socket 939 Opteron. If those results are accurate, there's no real reason not to just use an SMP kernel on default install? Just because it didn't manifest on this workload, doesn't mean it doesn't on others. I think this is the point :) I tried to model different worklods. The parallel part of my benchmark suite has CPU-heavy processes, short plain http, php, long plain http and mixtures thereof. None of these showed the SMP kernel to be an overall disadvantage on a one-processor system. However, the tradeoffs are different. The SMP kernel further increases the tendency that FreeBSD had all along to give CPU eaters more resources, disk and network I/O less, compared to Linux. Whether this is good or bad is open for discussion. From a traffic control standpoint you can both argue that it is better to get the CPU demands out of the way instead of getting more I/O done only to have the I/Oing processes then pile up in the already overcrowded CPU-demanding corner - and you can argue that you should get I/O done ASAP so that the I/O-initiating process doesn't hang around neccessaryily long. This is for both schedulers. I don't think this tendency is directly caused by the scheduler, it is probably the I/O subsystems coercing the scheduler, not the other way round. Martin -- %%% Martin Cracauer cracauer@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Tue, 2005-12-20 at 16:51 +0100, Dirk GOUDERS wrote: Yep, I really like this. The current mess is impossible to maintain (and also impossible to read). Yesterday I tried to update the kernel configuration chapter to cover 6.0, but I gave up since there are do this for 4.X, do that for 5.X, and maybe this too for 6.X everywhere. Seems as if my imagination was correct ;-) By the way, I tried to search the archive (doc@) for a possible earlier discussion of this subject but have a hard time to find proper words to search for... http://lists.freebsd.org/pipermail/freebsd-doc/2005-October/009027.html :-) -- Joel - joel at FreeBSD dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
By the way, I tried to search the archive (doc@) for a possible earlier discussion of this subject but have a hard time to find proper words to search for... http://lists.freebsd.org/pipermail/freebsd-doc/2005-October/009027.html Thanks! Well, seems as if some people's heads are already working on this subject... Dirk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
how about: FreeBSD-Handbook-General (guaranteed to work with all FreeBSD systems, doesn't include stuff in FreeBSD-Handbook-BRANCH.x) FreeBSD-Handbook-4.x (guaranteed to work with 4.x branch, doesn't include stuff in FreeBSD-Handbook-General) FreeBSD-Handbook-5.x (guaranteed to work with 5.x branch, doesn't include stuff in FreeBSD-Handbook-General) FreeBSD-Handbook-6.x (guaranteed to work with 6.x branch, doesn't include stuff in FreeBSD-Handbook-General) ... this way layered information is minimalized and there is clear path to find something out. FreeBSD-Handbook-General is rather fixed once ready, only maintenance needed is when some future release doesnt support something anymore, that is removed and moved to FreeBSD-Handbook-BRANCH.x. FreeBSD-Handbook-BRANCH.x deals with branch in case from installation to use, having links to FreeBSD-Handbook-General when needed. FreeBSD-Handbook-BRANCH.x can also have real-life examples and comments, so need for FAQ should be covered. dunno if that is any more clear but what there is out there now, is a mess. ---J On Tue, 20 Dec 2005, Ceri Davies wrote: On Mon, Dec 19, 2005 at 10:34:23AM +0100, Dirk GOUDERS wrote: 3. Full review and update of the install docs, handbook, FAQ, etc. There are sections that are embarrassingly out of date (one section of the handbook apparently states that we only support a single brand of wifi cards). A co-worker of mine tried to install 6.0 using just the handbook install guide, and discovered that it really doesn't match reality anymore, in both big and small ways. Contact me directly if you would like his list of comments. I am wondering if it wouldn't be advantageous to have versioned documents that just cover one specific release and not to cover all realeases in single documents. I could imagine that it is harder to cover everything in single documents than to perhaps copy the existing documentation when a new branch is created and edit it to match just the new release. Maybe, I do not realize how much more work this would be but it would probably enforce regular reviews of the documentation and the readers would benefit from it. This is exactly the idea that I have been pimping to anyone who will listen for the last three months or so. I also think that it is advantageous for users who are using, say 4.2, to be able to find documentation for 4.2 without having to interpret a nest of if you have 4.x do this, if 5.0 through 5.3 do that, else do the other. I don't think it's a lot of work to just branch the handbook (and FAQ if we decide to keep it) - in fact, for me, it would be a definite win - at release time, but it just doesn't seem to be what other people want done. I would encourage those interested to ask about it on [EMAIL PROTECTED] Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Wed, Dec 21, 2005 at 06:01:37PM +0200 I heard the voice of Juhana Tahvanainen, and lo! it spake thus: how about: FreeBSD-Handbook-General is rather fixed once ready, only maintenance needed is when some future release doesnt support something anymore, that is removed and moved to FreeBSD-Handbook-BRANCH.x. Difficult to manage. You have to remember or know which branches to backport stuff to, and you can't then say OK, we won't bother with 3.x anymore, but Handbook-3.x will remain around not needing further work for people using it, as future changes might not get pushed back. It would probably be easier using something like marked sections in a single handbook to separate out version-specific stuff from more general stuff; that way, at least it's all in one place, and you could just generate handbooks for any given branch off one source. Of course, it can get ugly to look at, too.. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Sat, Dec 17, 2005 at 05:37:20AM -0500, Allen wrote: On Saturday 17 December 2005 03:55, Christian Brueffer wrote: On Sat, Dec 17, 2005 at 08:55:00AM +, Allen wrote: I know about the port tool, but what I'd love to have is a tool you could run from the CLI or the GUI that would check for updates, and then ask which ones to install, similar to Swaret on Slackware. This way people can do the usual updates if they want, and people like me can show people BSD and how great it is. You probably haven't seen ports/security/freebsd-update yet. Actually, I've seen that and it does come close... But it didn't seem to like updating the Kernel or anything similar to the base system in the time I spent with it. Look harder; those are the *only* things it will update. This is not portupgrade. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpjw89aCk0dx.pgp Description: PGP signature
Re: My wish list for 6.1
On Mon, Dec 19, 2005 at 10:34:23AM +0100, Dirk GOUDERS wrote: 3. Full review and update of the install docs, handbook, FAQ, etc. There are sections that are embarrassingly out of date (one section of the handbook apparently states that we only support a single brand of wifi cards). A co-worker of mine tried to install 6.0 using just the handbook install guide, and discovered that it really doesn't match reality anymore, in both big and small ways. Contact me directly if you would like his list of comments. I am wondering if it wouldn't be advantageous to have versioned documents that just cover one specific release and not to cover all realeases in single documents. I could imagine that it is harder to cover everything in single documents than to perhaps copy the existing documentation when a new branch is created and edit it to match just the new release. Maybe, I do not realize how much more work this would be but it would probably enforce regular reviews of the documentation and the readers would benefit from it. This is exactly the idea that I have been pimping to anyone who will listen for the last three months or so. I also think that it is advantageous for users who are using, say 4.2, to be able to find documentation for 4.2 without having to interpret a nest of if you have 4.x do this, if 5.0 through 5.3 do that, else do the other. I don't think it's a lot of work to just branch the handbook (and FAQ if we decide to keep it) - in fact, for me, it would be a definite win - at release time, but it just doesn't seem to be what other people want done. I would encourage those interested to ask about it on [EMAIL PROTECTED] Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpxdR4OjEBSb.pgp Description: PGP signature
Re: My wish list for 6.1
On Tue, 2005-12-20 at 14:22 +, Ceri Davies wrote: On Mon, Dec 19, 2005 at 10:34:23AM +0100, Dirk GOUDERS wrote: 3. Full review and update of the install docs, handbook, FAQ, etc. There are sections that are embarrassingly out of date (one section of the handbook apparently states that we only support a single brand of wifi cards). A co-worker of mine tried to install 6.0 using just the handbook install guide, and discovered that it really doesn't match reality anymore, in both big and small ways. Contact me directly if you would like his list of comments. I am wondering if it wouldn't be advantageous to have versioned documents that just cover one specific release and not to cover all realeases in single documents. I could imagine that it is harder to cover everything in single documents than to perhaps copy the existing documentation when a new branch is created and edit it to match just the new release. Maybe, I do not realize how much more work this would be but it would probably enforce regular reviews of the documentation and the readers would benefit from it. This is exactly the idea that I have been pimping to anyone who will listen for the last three months or so. I also think that it is advantageous for users who are using, say 4.2, to be able to find documentation for 4.2 without having to interpret a nest of if you have 4.x do this, if 5.0 through 5.3 do that, else do the other. I don't think it's a lot of work to just branch the handbook (and FAQ if we decide to keep it) - in fact, for me, it would be a definite win - at release time, but it just doesn't seem to be what other people want done. Yep, I really like this. The current mess is impossible to maintain (and also impossible to read). Yesterday I tried to update the kernel configuration chapter to cover 6.0, but I gave up since there are do this for 4.X, do that for 5.X, and maybe this too for 6.X everywhere. -- Joel - joel at FreeBSD dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
This is exactly the idea that I have been pimping to anyone who will listen for the last three months or so. I also think that it is advantageous for users who are using, say 4.2, to be able to find documentation for 4.2 without having to interpret a nest of if you have 4.x do this, if 5.0 through 5.3 do that, else do the other. I don't think it's a lot of work to just branch the handbook (and FAQ if we decide to keep it) - in fact, for me, it would be a definite win - at release time, but it just doesn't seem to be what other people want done. I would like to add that I could imagine that it would be easier for authors to just change/add some documentation that matches the target release and not to have to think about if version=something else ... constructs. Also, sometimes it is good to be able to just throw away things that are out-of-date. I would encourage those interested to ask about it on [EMAIL PROTECTED] Well, I would be surprised if that hasn't already been discussed. Have to search the archives... Dirk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Yep, I really like this. The current mess is impossible to maintain (and also impossible to read). Yesterday I tried to update the kernel configuration chapter to cover 6.0, but I gave up since there are do this for 4.X, do that for 5.X, and maybe this too for 6.X everywhere. Seems as if my imagination was correct ;-) By the way, I tried to search the archive (doc@) for a possible earlier discussion of this subject but have a hard time to find proper words to search for... Dirk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Tue, Dec 20, 2005 at 03:46:53PM +0100, Joel Dahl wrote: On Tue, 2005-12-20 at 14:22 +, Ceri Davies wrote: This is exactly the idea that I have been pimping to anyone who will listen for the last three months or so. I also think that it is advantageous for users who are using, say 4.2, to be able to find documentation for 4.2 without having to interpret a nest of if you have 4.x do this, if 5.0 through 5.3 do that, else do the other. I don't think it's a lot of work to just branch the handbook (and FAQ if we decide to keep it) - in fact, for me, it would be a definite win - at release time, but it just doesn't seem to be what other people want done. Yep, I really like this. The current mess is impossible to maintain (and also impossible to read). Yesterday I tried to update the kernel configuration chapter to cover 6.0, but I gave up since there are do this for 4.X, do that for 5.X, and maybe this too for 6.X everywhere. Yes, that's my major concern. I find working on the current documents too difficult. Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-- Einstein (attrib.) pgpOKAMKs1nL1.pgp Description: PGP signature
Re: My wish list for 6.1
3. Full review and update of the install docs, handbook, FAQ, etc. There are sections that are embarrassingly out of date (one section of the handbook apparently states that we only support a single brand of wifi cards). A co-worker of mine tried to install 6.0 using just the handbook install guide, and discovered that it really doesn't match reality anymore, in both big and small ways. Contact me directly if you would like his list of comments. I am wondering if it wouldn't be advantageous to have versioned documents that just cover one specific release and not to cover all realeases in single documents. I could imagine that it is harder to cover everything in single documents than to perhaps copy the existing documentation when a new branch is created and edit it to match just the new release. Maybe, I do not realize how much more work this would be but it would probably enforce regular reviews of the documentation and the readers would benefit from it. Dirk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Monday 19 December 2005 04:34, Dirk GOUDERS wrote: 3. Full review and update of the install docs, handbook, FAQ, etc. There are sections that are embarrassingly out of date (one section of the handbook apparently states that we only support a single brand of wifi cards). A co-worker of mine tried to install 6.0 using just the handbook install guide, and discovered that it really doesn't match reality anymore, in both big and small ways. Contact me directly if you would like his list of comments. The install docs really could use some updating. However I've written this little tutorial for AntiOnline on installing it, and I don't think anyone has ever made it easier, and yes I am quite proud of it :) http://www.antionline.com/showthread.php?s=threadid=259335 You don't need to sign up to read this so check it out if you'd like. I've posted this tutorial to the docs mailing list before and everyone loved it. I'd have no problem doing a similar one for the 6X series so I should be able to soon. Written on a Linux box while wearing a Free BSD shirt with a monitor that has Free BSD stickers ;) I use both and don't flame! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Monday 19 December 2005 04:34, Dirk GOUDERS wrote: Well, I did not write the quoted text, but Scott Long did. Dirk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Fri, Dec 16, 2005 at 12:42:51AM -0700, Scott Long wrote: SMP laptops are right around the corner, and we should be ready to support SMP out-of-the-box. Already here - Alienware Aurora m7700 Athlon X2 dual-core. http://www.alienware.com/product_detail_pages/Aurora_m7700/aurora-m_features.aspx?SysCode=PC-LT-AURORA-M-7700SubCode=SKU-DEFAULT -- -- David ([EMAIL PROTECTED]) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Fri, Dec 16, 2005 at 10:34:09PM -0800, Avleen Vig wrote: On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote: 2. SMP kernels for install. Right now we only install a UP kernel, for performance reasons. We should be able to package both a UP and SMP kernel into the release bits, and have sysinstall install both. It should also select the correct one for the target system and make that the default on boot. If people are concerned about performance, I benchmarked a 6-beta kernel SMP versus UP on a socket 939 Opteron. If those results are accurate, there's no real reason not to just use an SMP kernel on default install? Just because it didn't manifest on this workload, doesn't mean it doesn't on others. I think this is the point :) Kris pgpqGMYb21vAl.pgp Description: PGP signature
Re: My wish list for 6.1
On 12/17/2005 01:34:09 AM, Avleen Vig wrote: On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote: 2. SMP kernels for install. Right now we only install a UP kernel, for performance reasons. We should be able to package both a UP and SMP kernel into the release bits, and have sysinstall install both. It should also select the correct one for the target system and make that the default on boot. If people are concerned about performance, I benchmarked a 6-beta kernel SMP versus UP on a socket 939 Opteron. Must be great having boxes like that ;) You know what I'd like to see in the next Free BSD? A way to update security fixes without having to play with any source, or having to touch make world. I know the speed and so on makes some people like this, but I personally try getting people who use Windows to switch to another OS or at least show them something else exists, and it's hard to make someone want to use Free BSD when installing patches can be such a timely manner. I know about the port tool, but what I'd love to have is a tool you could run from the CLI or the GUI that would check for updates, and then ask which ones to install, similar to Swaret on Slackware. This way people can do the usual updates if they want, and people like me can show people BSD and how great it is. If those results are accurate, there's no real reason not to just use an SMP kernel on default install? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers- [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Sat, Dec 17, 2005 at 08:55:00AM +, Allen wrote: On 12/17/2005 01:34:09 AM, Avleen Vig wrote: On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote: 2. SMP kernels for install. Right now we only install a UP kernel, for performance reasons. We should be able to package both a UP and SMP kernel into the release bits, and have sysinstall install both. It should also select the correct one for the target system and make that the default on boot. If people are concerned about performance, I benchmarked a 6-beta kernel SMP versus UP on a socket 939 Opteron. Must be great having boxes like that ;) You know what I'd like to see in the next Free BSD? A way to update security fixes without having to play with any source, or having to touch make world. I know the speed and so on makes some people like this, but I personally try getting people who use Windows to switch to another OS or at least show them something else exists, and it's hard to make someone want to use Free BSD when installing patches can be such a timely manner. I know about the port tool, but what I'd love to have is a tool you could run from the CLI or the GUI that would check for updates, and then ask which ones to install, similar to Swaret on Slackware. This way people can do the usual updates if they want, and people like me can show people BSD and how great it is. You probably haven't seen ports/security/freebsd-update yet. See http://www.daemonology.net/freebsd-update/ for more information. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgptoAmSGhjWd.pgp Description: PGP signature
Re: My wish list for 6.1
On Saturday 17 December 2005 03:55, Christian Brueffer wrote: On Sat, Dec 17, 2005 at 08:55:00AM +, Allen wrote: On 12/17/2005 01:34:09 AM, Avleen Vig wrote: On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote: 2. SMP kernels for install. Right now we only install a UP kernel, for performance reasons. We should be able to package both a UP and SMP kernel into the release bits, and have sysinstall install both. It should also select the correct one for the target system and make that the default on boot. If people are concerned about performance, I benchmarked a 6-beta kernel SMP versus UP on a socket 939 Opteron. Must be great having boxes like that ;) You know what I'd like to see in the next Free BSD? A way to update security fixes without having to play with any source, or having to touch make world. I know the speed and so on makes some people like this, but I personally try getting people who use Windows to switch to another OS or at least show them something else exists, and it's hard to make someone want to use Free BSD when installing patches can be such a timely manner. I know about the port tool, but what I'd love to have is a tool you could run from the CLI or the GUI that would check for updates, and then ask which ones to install, similar to Swaret on Slackware. This way people can do the usual updates if they want, and people like me can show people BSD and how great it is. You probably haven't seen ports/security/freebsd-update yet. Actually, I've seen that and it does come close... But it didn't seem to like updating the Kernel or anything similar to the base system in the time I spent with it. Free BSD has probably one of the best methods of installing new packages with pkg_add, and pkg_add -r for grabbing them off the internet but for updates it could use some work. It won't stop me from buying Free BSD things, but it does make showing new computer users the OS a but harder. OT: If anyone wants a person to couge, the Free BSD boxers are VERY high quality and, it must be said, a pair of boxers any BOFH would wear. They look great with my Free BSD TeeShirt and Laptop covered in BSD stickers. :) - Christian -Allen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Scott Long [EMAIL PROTECTED] wrote: Guys, With code freeze for 6.1 about 6 weeks away, I'd like to put out my 'wish list' for it: What about putting 1. and 3. on the new ideas page (marked as important and including a deadline)? At least for 3. more eyes would be beneficial. 1. working kbdmux. We need this for the growing number of systems that assume that USB is the primary keyboard. Current status appears to be that the kbdmux driver breaks very easily. We need this working well enough where it can be enabled by default, and all attached keyboards Just Work. 3. Full review and update of the install docs, handbook, FAQ, etc. There are sections that are embarrassingly out of date (one section of the handbook apparently states that we only support a single brand of wifi cards). A co-worker of mine tried to install 6.0 using just the handbook install guide, and discovered that it really doesn't match reality anymore, in both big and small ways. Contact me directly if you would like his list of comments. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 BOFH excuse #130: new management ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Scott Long wrote on Fri, Dec 16, 2005 at 12:42:51AM -0700: 2. SMP kernels for install. Right now we only install a UP kernel, for performance reasons. We should be able to package both a UP and SMP kernel into the release bits, and have sysinstall install both. It should also select the correct one for the target system and make that the default on boot. If people are concerned about performance, I benchmarked a 6-beta kernel SMP versus UP on a socket 939 Opteron. The performance characteristic for the parallel tests with CPU-eaters and plain http streams in the background is different. But there certainly is no slowdown that would make us look bad when people use a SMP kernel on a one-processor machine. CPU time results: http://www.cons.org/cracauer/crabench/smpkernel.user.html Wall clock time results: http://www.cons.org/cracauer/crabench/smpkernel.wall.html General benchmark homepage (lots of AMD64 and memory benchmarking there): http://cracauer-forum.cons.org/forum/crabench.html Martin -- %%% Martin Cracauer cracauer@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Hi, Scott, On 12/16/05, Scott Long [EMAIL PROTECTED] wrote: Guys, With code freeze for 6.1 about 6 weeks away, I'd like to put out my 'wish list' for it: More-or-less OT question: Shall we switch ULE as the default scheduler on -HEAD to encourage more testing against it? Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Xin LI wrote: Hi, Scott, On 12/16/05, Scott Long [EMAIL PROTECTED] wrote: Guys, With code freeze for 6.1 about 6 weeks away, I'd like to put out my 'wish list' for it: More-or-less OT question: Shall we switch ULE as the default scheduler on -HEAD to encourage more testing against it? Cheers, Only if there is someone committed to tracking and fixing bugs. Last time we tried this, we wasted a lot of time and energy. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
Scott Long wrote: Guys, With code freeze for 6.1 about 6 weeks away, I'd like to put out my 'wish list' for it: 1. working kbdmux. We need this for the growing number of systems that assume that USB is the primary keyboard. Current status appears to be that the kbdmux driver breaks very easily. We need this working well enough where it can be enabled by default, and all attached keyboards Just Work. FWIW, I've been using this for months, on a box that I've rolled from 5, to 6 (when I started using it), and now 7 (although outdated now). It's been running perfectly, and until now I forgot I was using it. I'm using it so my machine has a ps/2 keyboard on boot for BIOS and loader screens, but then has my usb keyboard normally. I just leave the ps/2 kb on top of the system, since it doesn't reboot much. Maksim, thanks for the hard work on it so far! Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Sat, Dec 17, 2005 at 02:22:36AM +0800, Xin LI wrote: Hi, Scott, On 12/16/05, Scott Long [EMAIL PROTECTED] wrote: Guys, With code freeze for 6.1 about 6 weeks away, I'd like to put out my 'wish list' for it: More-or-less OT question: Shall we switch ULE as the default scheduler on -HEAD to encourage more testing against it? No, it's already known to have stability problems (on large SMP machines) and performance problems under load (about 10-20% slower than 4BSD), so until someone fixes those there's no point. Kris pgpuvHJw4VZp4.pgp Description: PGP signature
Re: My wish list for 6.1
On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote: 2. SMP kernels for install. Right now we only install a UP kernel, for performance reasons. We should be able to package both a UP and SMP kernel into the release bits, and have sysinstall install both. It should also select the correct one for the target system and make that the default on boot. If people are concerned about performance, I benchmarked a 6-beta kernel SMP versus UP on a socket 939 Opteron. If those results are accurate, there's no real reason not to just use an SMP kernel on default install? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
My wish list for 6.1
Guys, With code freeze for 6.1 about 6 weeks away, I'd like to put out my 'wish list' for it: 1. working kbdmux. We need this for the growing number of systems that assume that USB is the primary keyboard. Current status appears to be that the kbdmux driver breaks very easily. We need this working well enough where it can be enabled by default, and all attached keyboards Just Work. 2. SMP kernels for install. Right now we only install a UP kernel, for performance reasons. We should be able to package both a UP and SMP kernel into the release bits, and have sysinstall install both. It should also select the correct one for the target system and make that the default on boot. The easiest way to do this would be to have sysinstall boot an SMP kernel and then look at the hw.ncpu sysctl. The only problem is being able to have sysinstall fall back to booting a UP kernel for itself if the SMP one fails. This can probably be 'faked' by setting one of the SMP-disabling variables in the loader. But in any case, the point is to make the process Just Work for the user, without the user needing to know arcane loader/sysctl knobs. SMP laptops are right around the corner, and we should be ready to support SMP out-of-the-box. 3. Full review and update of the install docs, handbook, FAQ, etc. There are sections that are embarrassingly out of date (one section of the handbook apparently states that we only support a single brand of wifi cards). A co-worker of mine tried to install 6.0 using just the handbook install guide, and discovered that it really doesn't match reality anymore, in both big and small ways. Contact me directly if you would like his list of comments. Thanks! Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
