• NetBSD's "let's move kernel parts to the userland" RUMP project is still under heavy development, and in order to make testing of compatibility after kernel changes easier, a new command "rumptest" was added to build.sh: ``Basically you say:

  	    ./build.sh ${yourargs} tools ; ./build.sh ${yourargs} rumptest
  	

  Where yourargs are what have you, e.g. '-U -u -o -O /objs'.

  The latter builds only the rump kernel libs and uses some ld+awk magic to figure out if things go right or not. This is to avoid having to install headers and build libs (which is too slow since a full build is too slow). The magic is not a substitute for a full build, but it is n+1 times faster and works probably 99.9% of the time.

  The scheme uses a number of predefined component sets (e.g. tmpfs+vfs+rumpkern) to test linkage. They are currently listed in build.sh. This area probably needs some work in the future. It would be nice to autogenerate the combinations somehow.

  If things go well, you get something like this:

          ===> Rump build&link tests successful
          ===> build.sh ended:   Wed Nov 18 20:10:59 EET 2009 

  '' See Antti's Antti's mail to tech-kern: on how to tell if things didn't go so well, and what to do in that case.

• According to Wikipedia, ``Non-Uniform Memory Access or Non-Uniform Memory Architecture (NUMA) is a computer memory design used in multiprocessors, where the memory access time depends on the memory location relative to a processor. Under NUMA, a processor can access its own local memory faster than non-local memory, that is, memory local to another processor or memory shared between processors.''

  Supporting NUMA in a contemporary (i.e.: Intel centric) SMP-enabled operating system requires following a bunch of standards, two of which are parsing of two tables, the System Resource Affinity Table (SRAT) and the System Locality Information Table (SLIT). Both tables are accessible via the Advanced Configuration and Power Interface (ACPI), and according to the German-language Wikipedia, the SRAT is used to assign local memory to local threads to boost their performance, and the SLIT defines the "distance" of the nodes among themselves, which is used to determine the "nearest" memory if local memory is not enough.

  Now, Christop Egger has posted patches to add an ACPI SLIT parser and an ACPI SRAT parser. See the two postings for dmesg pr0n from his tests on an 8-node system.

• Staying with ACPI and Christoph Egger, he found that even though the ACPI spec defines an ACPI device for fans, BIOS vendors and OEMs do their own thing. To accommodate things like the fan sensor found in the ACPI Thermal Zone in his HP Pavillion DV9700 laptop he has proposed a driver to extend the acpitz(4) driver with fan information. That way, envstat(8) can be used to display the ran's RPMs:

  [acpitz0]
    Processor Thermal Zone:     56.000   95.000                       degC
                       fan:       2840                                 RPM 

• Staying with driver games, iMil writes me that there's documentation on getting DRI, AIGLX, Composite and Compiz going with NetBSD 5.0 available in the O(ther)NetBSD Wiki now.

  The documentation covers how to enable the Direct Rendering Manager (DRI), setting up and configuring Modular X.org, assuring that everything's in place, and how to get Compitz going. Mmm, wobbly windows at last! :-)

• While we're talking funky desktop stuff: Marc Balmer has submitted a patch to get touchpanel support for ums(4). ums(4) is for USB mice, and in contrast to mice, touch panels need to deal with absolute numbers, not relative numbers.

• Back to the guts of the kernel, another patch suggested by Christop Egger was for adding x2apic. What is x2apic? X2APIC is ``an Intel-only feature but can also be found in virtual environments with support for CPU apic id's > 0xff.

  I.e. Xen 4.0 (not yet released) supports 128 CPUs in HVM guests with the CPUs enumerated with even apic id's. That means you need x2apic for the 128th CPU :) ''

• While speaking of Xen: Xen 4.0 is coming soon, and there's a call to help testing it on NetBSD!

  Install Mercurial, check out latest Xen sources, apply a bunch of patches, build and install. Examples of commands are given, in addition to changes required for /boot.cfg etc.

  Report your findings to port-xen!

• Last one for today: Michal Gladecki, Editor-in-Chief of BSD Magazine writes: ``We are happy to announce that BSD Magazine is transforming into a free monthly online publication. The online version of BSD Magazine will stay in the same quality and form. It will look like the BSD magazine one is familiar and comfortable with. Please sign up to our newsletter at www.bsdmag.org and get every issue straight to your inbox. Also, you can now download any of the previous issues from our website. The first online issue -- 2/2010 -- is coming out in February. Please spread the word about BSD Magazine. '' Click!

Unrelated, I've been playing with git a bit over the past few days, and wile I have a number of questions building up (which will be subject to tech-repository or so), what I can say today is that the speed of "git pull" with NetBSD's git repository and my 1MBit DSL line reminds me a lot of the times when I used SUP with my 56k modem - it took forever, too. :-(

[Tags: acpi, acpitz, aiglx, Articles, bsdmac, compiz, dmesg, dri, numa, rump, slit, touchpanel, ums, x2apic, xen] [Slashdot It!]

• NetBSD implements traditional Unix file access control, which is based on permissions for reading, writing and executing for any of a file's owner, its group, and the rest of the world. Concepts in the form of Access Control Lists (ACLs) exist for more fine grained control, but they are not available with NetBSD. Yet.

  Elad Efrat is still workin on the kauth(9) framework, and as a side-product, he has implemented Access Control Lists on top of kauth(9).. The code is not fit for production use yet, but we can stay tuned to see more of this.

• When you have a machine running virtualization, you usually dedicate a portion of the machine's RAM to each of the VMs. You (usually) cannot spend more RAM for VMs than you have RAM in the host, obviously... until you use some sort of virtual memory for the VMs themseolves. Which is what the Xen "balloon" driver does, inflating a Xen VM's RAM as needed.

  Those interested in a driver can find a balloon driver for Xen3 dom0 by Cherry G. Mathew now, who's looking forward to your comments!

• Coming newly to NetBSD, developer Marc Balmer writes: ``NetBSD has had support for General Purpose Input/Output devices since the 4.0 release, when the GPIO framework from OpenBSD 3.6 was imported. Since the import of the GPIO framework into NetBSD, I have reworked larger parts of that subsystem in OpenBSD to address some problems and drawbacks''. More details on his motivation and details can be found on his homepage, and Marc has posted about his recent work on updating NetBSD's GPIO framework.

  See Marc's posting for details on changes in the API, prominent changes, security aspects and more.

• When you run a Xen DomU which has its file system on a vnd(4) disk and which has a number of disk images which are again put together into a raidframe(4) volume which may in turn contain further images for vnd(4), raidframe(4), cgd(4) and possibly others, tearing down the whole stack on system shutdown can get hairy.

  The situation is known, and David Young has put some work into this area. For now, he can properly detach raid units. See his posting for an example session.

All this goes with the usual contents of the CD, i.e. a NetBSD based lice CD with a XFCE desktop.

[Tags: jibbed, xen] [Slashdot It!]

• BSD-related radio-show "bsdtalk" has published an interview with NetBSD's Andrew Doran in its March 2009 issue. Besides covering Andrews work, the upcoming NetBSD 5.0 release is also discussed. Available as mp3 and ogg.

• Cross-compiling pkgsrc packages is a long-standing dream, and it's yet waiting for someone to do it. For the time being, Jared McNeill has come up with an HowTo on how to build 32bit packages on amd64 (and probably other 64bit systems).

• Jared McNeill's been hacking on more stuff recently, and one thing includes changes to the framebuffer console support on x86 (i.e. both i386 and amd64). In short, the recent changes are just a stop on the way to move the splashscreen code and esp. image data from the kernel to userland. I.e. that you can put something like

   menu=Boot NetBSD:vesa 1280x800;splash /logo.bmp;boot netbsd 

  into your /boot.conf in the future. But we'll see a separate announcement when that part is done. Let's stay tuned! :)

• Martti Kumparinen has tackled generating a UFS file system on a "large" (~5.5TB) disk. As the process is not straight forward, he has posted a howto that may help in the future. Any takers for adding comments and integrating this into The NetBSD Guide? :)

• Manpages are a major component of every Unix system. If you have ever tried to write such a manpage, you 'll have learned that they are in a funny text-based format similar to LaTeX and HTML, with its own processor - *roff. There are several *roff implementations, and the one used in NetBSD currently is the GNU implementation. To provide an alternative here is good for both removing GPL'd code from the NetBSD codebase, and also because groff is written in C++, which is slow to compile, and - well - requires a C++ compiler.

  A change for that situation may arise eventually, as Kristaps Dzonsons has been working on a groff replacement to format Unix manpages recently. See his posting and his homepage for further information.

• I've talked about Xen support for PCI passthrough recently, and Manuel Bouyer has finished his work to get full support for passing in access to specific PCI devices from the Xen Dom0 to DomUs. See his posting to port-xen for more details!

• Staying at Xen for a moment, David Brownlee has written instructions on Installing Windows XP in Xen under NetBSD. Just in case anyone needs to run a legacy system... :)

• The NetBSD operating system supports many different hardware and CPU platforms. For a specific platform, binaries are compiled with a specific compiler, and there is a set of binaries for each platform. This results in a rather big number of different sets of binaries - currently about 50. A different approach with historic precedence is to have one binary work on may hardware platforms, so-called "fat" binaries.

  Gregory McGarry has posted suggestions on how to modify NetBSD's toolchain to produce fat binaries. An interesting concept which would solve a number of problems (think: support, updates, pkgsrc!)

• Qt is a user-interface library found in widespread use in the Unix/Linux world. It's not exactly small, and its prerequirement of the X Window System doesn't it make a #1 choice for embedded systems at the first look. A Qt variant - Qt/Embedded - can be ran without X, though, and which thus avoids all the configuration and hardware support trouble of X in one go.

  On NetBSD, Qt/Embedded could talk to the wscons driver directly, and Valeriy 'uwe' Ushakov has posted about his work on patches to adopt Qt/Embedded to wscons. Who's first to post some screenshots?

Other work that's underway is PCI passthrought: This feature that was available with Xen2 on NetBSD was changed in Xen3, and kernel support for DomUs to access specific devices on a PCI bus is underway. Currently, NetBSD DomUs need a Linux Dom0 to pass access to the PCI bus, but this is expected to change soon. First steps to pass single PCI devices from a NetBSD Dom0 to a DomU are made, and we can look forward for more of this to come. Again, see posting to port-xen for more details.

The last item is just a quick heads-up in reply to Manuel's posting: Jean-Yges Migeon is currently working to get saving and restoring of DomUs as well as the associated migration of domains between several Dom0s -- i.e. to move a running DomU from one machine to another -- working.

[Tags: pae, xen] [Slashdot It!]

As installing a different bootloader is suboptimal, possibly dangerous, and has (had?) issues on 64bit platforms, grub was not such a nice option.

Now, Robert Swindells has finished making changes to NetBSD's native boot loader to allow it to load the Xen hypervisor by itself, without needing grub any more!

This makes installation of NetBSD/Xen even easier: Just drop in a Xen-enabled kernel, add an entry to the boot.cfg file, and reboot.

I can even envision that Xen could be installed in future versions of NetBSD/i386 and NetBSD/amd64 by default. Then all that's really needed would be to add the management tools after installing NetBSD. Any takers? :-)

[Tags: grub, xen] [Slashdot It!]

• Introduction
• Release engineering, Sendmail, and kauth
• PaX, fileassoc, and Veriexec
• Linux compat, XFree86, pkgsrc, proplib, and Xen
• Filesystems
• iSCSI and optical disc support
• Bluetooth, mobile devices, agr
• Google Summer of Code
• Hackathons and funding

So far, NetBSD never got PAE-support, as its amd64-port worked early and very well, so people with demand for more than 4GB ram usually moved to an appropriate hardware platform, and called it good. One case where PAE support was an issue is Xen, though: Linux usually has PAE enabled these days with Xen3 Dom0s, and DomUs running on a PAE-enabled Dom0 also have to support PAE. As a consequence, it was not easily possible to use NetBSD DomUs with contemporary Linux/Xen distributions.

Thanks to long-term NetBSD/Xen-hacker Manuel Bouyer, this has changed now: Manuel has added support for PAE to the NetBSD/Xen port, and he has merged the corresponding CVS branch to NetBSD-current now. There are separate kernels, XEN3PAE_DOMU and INSTALL_XEN3PAE_DOMU, which have PAE-support enabled, and which are expected to show up in daily builds soonish.

While this work does not add PAE support for NetBSD/i386 in general, it brings it a big step forward, and it may just be a matter of time until NetBSD/i386 also gets PAE support.

Implementation details can be found in src/sys/arch/i386/include/pte.h and src/sys/arch/i386/include/pmap.h, btw -- see Manuel's mails to port-xen for more information.

[Tags: pae, xen] [Slashdot It!]

Manuel also outlined his future plans: ``Once bouyer-xenamd64 is merged, I'll start a new branch to work on switching xeni386 to the new x86 pmap and xenamd64 bootstrap codes, and merge back code from xen/i386 to i386/i386. I'll also look at x86pae support in Xen, as using the x86 pmap should make this much easier.''

Esp. the bit about PAE is very desirable, as it currently stops NetBSD from working as domU with a Linux dom0 that has PAE enabled (which is the default nowadays). Every Linux user that wants to try NetBSD in a Xen domU currently has to make sure he has a non-PAE kernel first, which is suboptimal.

[Tags: amd64, xen] [Slashdot It!]

Too much focus on Linux and too little focus on NetBSD, but it may still serve as useful material when trying to tell your boss/buddy/whatever what Xen is and why it is yet another reason for going NetBSD.

(While there: anyone up for providing patches to bring the NetBSD/Xen HowTo up to speed for Xen3 from the start? Send your patches to www [at] NetBSD.org!)

[Tags: Articles, xen] [Slashdot It!]

Just for the record (and to hit the spot of this blog :-): Panix, who is one of the oldes ISPs in business ever, has a longstanding relationship with NetBSD: They use NetBSD for many of their services, and current and former Panix employees are active NetBSD developers.

[Tags: hosting, xen] [Slashdot It!]

In related news, Manuel has updated the packages for the latest Xen release (3.0.3) and a new one to support HVM (which needs X, in order to emulate a VGA console via Qemu, see above). With that package, it was possible to boot systems that were not specifically prepared for use with Xen, e.g. NetBSD/i386, Linux and Windows XP! See Manuel's second posting and the followups.

[Tags: qemu, xen] [Slashdot It!]

(And no, I'm not sponsored by them; Rainer Brinkmöller pointed me at them)

Update: The x|encon Support Team told me that what they offer is a plain blockdevice which can be setup wit a NetBSD XEN3_DOMU_INSTALL kernel then to everyones' likes.

[Tags: hosting, xen] [Slashdot It!]

cpu* at mainbus?

vcpu* at hypervisor?

See Manuel's mail for more information.

[Tags: xen] [Slashdot It!]