Essen Hackthon 2015 — last day status

I committed the 64bit support for the linux base ports (disabled by default, check the commit message), but this broke the INDEX build. Portmgr was faster than me to revert it. All errors are mine. I think most of the work is done, I just need to find out what the correct way is to handle this make/fmake difference (malformed conditional).

Share/Save

Essen Hackathon Status report — 2nd day

I had a look at the open PR’s for a quick-win and found one where the dependencies where incomplete. Fixed.

Then I reviewed Alan Jude’s patch for 64bit linux_base-c6 ports (on amd64). Looks good so far. Just a few minor issues. I took the time to get familiar with reviews.FreeBSD.org and the arc command line tool, applied the patch to my source tree, worked a while on merge-conflicts, added some minor changes, and validated the download of the 32bit RPM’s of the linux_base-c6 port.

In between I also discussed/reviewed some fixes for docs with Dru, signed some PGP keys, and served as a source for a funny picture (at least what geeks/nerds consider a funny picture). I also checked how to allow multi-cast in jails. There is a PR with a patch inside, but it’s IPv6 only. I did something similar for IPv4 and compiled a kernel. No compile time issues, but as the system where I can easily test this is at home, I prefer to be in front of the box in case it panics (that tells something about my confidence level of my patch… no idea if what I do there is actually correct… ENOCLUE about the network code in the kernel).

TODO for the last day of the Hackathon:

  • validate all RPM’s (download / distinfo) of the ports which changed
  • validate the install/deinstall of the 32bit version of the ports for regression
  • validate the 64bit install/deinstall for at least the linux base port (more if time permits tomorrow)

Share/Save

FreeBSD 10.2-RC1 Now Available

The first RC build of the 10.2-RELEASE cycle is now available.

Installation images are available for the amd64, i386, ia64, powerpc, powerpc64, and sparc64 architectures.

FreeBSD/arm SD card images are available for the BEAGLEBONE, CUBOX-HUMMINGBOARD, GUMSTIX, RPI-B, PANDABOARD, and WANDBOARD kernels.

FreeBSD 10.2-RC1 is also available on several third-party hosting providers.

See the PGP-signed announcement email for installation image checksums and more information.

FDT overlays in FreeBSD

FDT overlay is an extension to FDT format that lets user to modify base FDT run-time: add new nodes, add new properties to existing nodes or modify existing properties. It’s useful when you have base board and some extension units like cape/shield for Pi/BBB or loadable FPGA logic for Zynq. I will not go into details you can find internals described on Adafruit or Raspberry Pi websites.

When dealing with overlays there are two options where to handle them: loader or kernel. Managing overlays at kernel level gives more flexibility but requires more related logic, e.g. re-init pinmux after applying overlay, re-run newbus probe/attach. On the other hand loader-level support is quite straightforward and involves nothing but DTB modifications and it’s a natural first step to adding FDT overlays to FreeBSD.

Proposed solution is to add fdt_overlays variable that contains coma-separated list of dtbo files, e.g.: “bbb-no-hdmi.dtbo,bbb-4dcape-43.dtbo”. This variable can be defined either as a loader(8) variable or as a u-boot env variable. During the boot ubldr load base DTB and right before passing control to the kernel it would go through files, load them from /boot/dtb/ direсtory on root partition and apply to the base blob. Final DTB would be passed to kernel.

You can find patch and review comments to it on Differential site: D3180. It contains:
- Extension to dtc to generate dynamic symbols and fixup info.
- ubldr fdt_overlays support

As Warner Losh mentioned it’s not clear yet how to deal with dynamic symbols support patch. It’s not part of official dtc tree though it’s accepted by RPi and BBB communities.

Essen Hackathon status report — 1st day/evening

The Essen Hackathon 2015 starts. More or less around 6pm people started to show up (including myself). The socializing session (BBQ) had some funny/interesting stories, and provided already some interesting topics to have a closer look at.

Possible candidates where I can provide some input are around DTrace: How to use it (but probably Sean Chittenden has some much more interesting DTrace things to show) and how to add SDT probes to the kernel.

On the ports side I want to get some insight into the USES framework, to see if it may be easy to convert the linuxulator ports to it or not. Maybe I can also have a deeper look into patches for the 64bit side of the linux_base ports.

Share/Save

FreeBSD 10.2-RC1 Available

The first RC build for the FreeBSD 10.2 release cycle is now available. ISO images for the amd64, armv6, i386, ia64, powerpc, powerpc64 and sparc64 architectures are available on most of our FreeBSD mirror sites.

FreeBSD 10.2-BETA2 Now Available

The second BETA build of the 10.2-RELEASE cycle is now available.

Installation images are available for the amd64, i386, ia64, powerpc, powerpc64, and sparc64 architectures.

FreeBSD/arm SD card images are available for the BEAGLEBONE, CUBOX-HUMMINGBOARD, GUMSTIX, RPI-B, PANDABOARD, and WANDBOARD kernels.

FreeBSD 10.2-BETA2 is also available on several third-party hosting providers.

See the PGP-signed announcement email for installation image checksums and more information.

FreeBSD 10.2-BETA2 Available

The second BETA build for the FreeBSD 10.2 release cycle is now available. ISO images for the amd64, armv6, i386, ia64, powerpc, powerpc64 and sparc64 architectures are available on most of our FreeBSD mirror sites.

Lumina Desktop 0.8.5 Released

The next version of the Lumina Desktop Environment is now available! This version includes a significant number of updates, particularly to the main desktop session/interface, so I highly recommend that you update to the new version as soon as possible. While the full list of changes is posted at the bottom of the announcement, there are a few that I want to highlight here:

  • The user button has received a significant speed boost, and can now be used for full browsing of the user’s home directory (files and directories).
  • Desktop icons have received a large number of changes in styling, amount of visible text, and functionality. There is also a new feature to automatically generate plugins for items in the user’s Desktop directory – where each plugin may be individually moved/changed (not trapped within a container like the “desktopview” plugin).
  • A new desktop plugin for monitoring the system hardware status (memory/CPU usage, CPU temperature, disk I/O). This functionality requires support for your particular OS, and is currently only available for: PC-BSD, FreeBSD, and Debian
  • A new desktop plugin container for running custom QtQuick/QML scripts. While there is only a single “sample” plugin of this type available at the present time, it is now possible for users to create their own custom interface plugins using the QML scripting language (similar to javascript or CSS). See the “New Plugins” section in the change log below for details about where these scripts need to be placed/named.

Translations:

  • Lumina has now been fully translated to German, Russian, and Spanish, and almost-completely translated to Catalan (89%), Chinese (61%), Estonian (53%), Indonesian (76%), Polish (89%), Portuguese (89%), Portuguese-Brazilian (89%), Swedish (91%), and Turkish (88%). Thank you to all our translators for all your hard work!!
  • To install the translation files on PC-BSD/FreeBSD, you will need to install the (new) x11/lumina-i18n port/package. These translations files are located in the lumina-i18n repository on GitHub, if you wish to package up the translations for your particular OS/distribution as well. Details about how to install those translation files are listed in the repository information.
  • To contribute to the translation effort, you may create an account on the PC-BSD translation website and get started today!

 Package Availability:

  • PC-BSD users currently running the EDGE package repo will be able to update their packages via the updater GUI or “pc-updatemanager” utility within the next couple days. Updates for users on the PC-BSD 10.1.2 / PRODUCTION repo will be available once 10.2-RELEASE is available later this year.
  • FreeBSD users may now update Lumina directly from the FreeBSD ports tree (x11/lumina), or wait until the FreeBSD package repository is updated with the latest changes before updating with pkg.
  • For other Linux/BSD users, please contact the packaging team for your distribution/OS to determine the availability of pre-built packages.

Source Repository

  • The Lumina-DE source repository is available on GitHub, and contains a detailed list of instructions on how to build/install Lumina on various types of systems.
  • A static archive of the sources for this release may also be downloaded directly from GitHub, to aid in the creation/distribution of pre-built packages for your particular OS.

Reporting Bugs

  • Found a bug in Lumina 0.8.5? Please report it (with as much detail as possible) to our bugs database. https://bugs.pcbsd.org

Errata

  • The new system for desktop plugin settings requires that any desktop plugins will be reset back to defaults on upgrade to this version of Lumina.
  • There is a known bug/conflict between Qt 5.4+ and Fluxbox 1.3.7 which results in the “close” button on unlocked desktop plugins having no effect when clicked. To work around this issue, you may right-click on the title for the plugin and select the “close” option from the menu to remove the desktop plugin. Alternatively, you may also remove desktop plugins from the Lumina configuration utility (lumina-config).

Contact Us

 

Full list of changes since version 0.8.4:

  • Desktop Icons:
    • Always support two lines of text, and uniform icon sizes
    • Allow the ability to remove files/dirs from ~/Desktop through the desktopview/applauncher plugins (as well as increase/decrease icon sizes).
    • Add a new option to automatically generate plugins for each file/dir in the users Desktop directory. This can easily be turned on/off in lumina-config.
    • Completely re-work how desktop plugins save their settings. Now it is extremely fast and much more reliable. NOTE: This change is NOT backwards compatible. On upgrade to this version of Lumina, all desktop plugins will have their settings reset to defaults.
    • Completely re-work how desktop plugins are initially placed/sized. This ensures consistency/reliability
  • New Plugins:
    • System Monitor (Desktop): This will show the current CPU/Memory/Temperature of the system, as well as list the current disk I/O (if supported by the current OS).
    • Quick Plugin (Desktop): This allows the user to load arbitrary QtQuick/QML scripts and display them within containers on the desktop. These scripts need to be located in “~/.lumina/quickplugins/quick-*.qml” or “<Lumina share directory>/quickplugins/quick-*.qml” (other .qml files may be in those directory for additional widget/scripting support, but are not considered full plugins without the “quick-” prefix on the filename). See the “quick-sample.qml” plugin for an example of how to provide additional information about your script/plugin when it is automatically made available in lumina-config.
  • XDG Standards support
    • Convert to the XDG autostart specifications completely for reading/setting/disabling auto-started applications. Previous settings will automatically be converted the new format on update to 0.8.5
    • Assign internal “unknown/<filename/extension>” mimetypes to files that do not have a mimetype in the system database (so default applications may still be registered/used).
    • Ensure that “Lumina” instead of “LUMINA” is used for XDG system registrations (where applicable).
  • Session Startup Procedures:
    • Add a small splashscreen showing the progress/stage of Lumina during the session initialization.
    • Add 1/4 second, non-blocking delay between auto-started application startups (to prevent overloading the system all at once).
    • Proceed immediately to the application autostart routines after session initialization (remove previous two-second delay).
  • Lumina Configuration Utility:
    • Change a number of options so that nothing is changed on the system until the “save” button is clicked (for uniformity).
    • Add a new widget for managing panels – allowing up to 12 panels per screen to be setup in lumina-config.
    • Add full list/add/remove support for desktop plugins (with multi-selection removals).
  •  Miscellaneous:
    • Significantly updated themes, and some updates to color schemes as well.
    • Add support for solid-color backgrounds
    • Significantly speed up the loading of the userbutton on click, and add full home dir browsing/launching/favoriting support (files/dirs)
    • Additional error detection for mis-configured luminaDesktop.conf settings.
    • Make sure to put a line break between the time/date display if both are selected to be shown on the clock plugin.
    • Additional checks/updates to the system tray routines to ensure that nothing gets “missed” on startup.
    • Clean up some handling of “wine” applications in lumina-open.
    • Add binaries in the lumina-search output for applications.
    • Add thumbnail support to a number of plugins (userbutton, desktopbar, etc)
    • Fix a number of issues in various places regarding uniform icons sizing/spacing.
    • Add full desktop re-scaling support if switching to a new monitor/resolution between sessions.
    • Force Fluxbox to completely restart when a monitor is added/removed in the middle of a session (bypassing a couple bugs in Fluxbox).
    • Modify the luminaDesktop.conf file syntax a bit so it can be read/parsed by libUCL. The internal parsing routine does have backwards compatibility for the older syntax though.
    • Bugfix for the favorites system: ensure the favorites directory exists and create it if not.
    • Fix the initial brightness detection for new FreeBSD users.
    • Clean up some case-sensitivity issues when parsing luminaDesktop.conf
    • Remove some built-in Qt context menus on various toolbars.
    • Adjust the initial window geometry check/fix routine to work better.
    • Adjust a couple default key bindings (new users only):
      • Pause key -> Lock screen (new binding)
      • Tile windows left/right -> Alt+[left/right] instead of Ctrl+[left/right] (had conflict with existing Fluxbox shortcut).

FreeBSD now has NUMA? Why’d it take so long?

I just committed "NUMA" to FreeBSD. Well, no, I didn't. I did almost no actual NUMA-y work in FreeBSD. I just exposed the existing NUMA stuff in FreeBSD out and re-enabled it.

FreeBSD-9 introduced basic NUMA awareness in the physical allocator (sys/vm/vm_phys.c.) It implemented first-touch page allocation, and then fell back to searching through the domains, round-robin style. It wasn't perfect, for some workloads it was apparently okay. But it had some shortcomings - it wasn't configurable, UMA and other subsystems didn't know about NUMA domains, and the scheduler really didn't know about NUMA domains. So I'm sure there are plenty of workloads which it didn't work for.

That was all ripped out before FreeBSD-10. FreeBSD-10 NUMA just implements round-robin physical page allocation. It still tracks the per-domain physical memory regions, but it doesn't do any kind of NUMA aware allocation. From what I can gather, it was removed until something 'better' would land.

However, nothing (yet) has landed. So I decided I'd take a look into it. I found that for a lot of simple workloads (ie, where you're doing lots of anonymous memory allocation - eg, you're doing math crunching) the FreeBSD-9 model works fine. It's also a perfectly good starting point for experimenting.

So all my NUMA work in -HEAD does is provide an API to exactly the above. It doesn't teach the kernel APIs about domain aware allocations - there's currently no way to ask for memory from a specific domain when calling UMA, or contigmalloc, etc. The scheduler doesn't know about NUMA, so threads/processes will migrate off-socket very quickly unless you explicitly limit things. Devices don't yet do NUMA local work - the ACPI code is in there to enumerate which NUMA domain they're in, but it's not used anywhere just yet.

Then what is it good for?

If you're doing math workloads where you read in data into memory, do a bunch of work, and spit it out - it works fine. If you're running bhyve instances, you can run them using numactl and have them pinned to a local NUMA domain. Those coarse-grained things work fine. You can also change the system default back to round-robin and use first-touch or fixed-domain for specific processes. It's useful for exactly the same subset of tasks as it was in FreeBSD-9, but now it's at least configurable.

So what's next?

Well, my main aim is to get the minimum done so kernel side work is NUMA aware. This includes UMA, contigmalloc, malloc, mbuf allocation and such. It'd be nice to tag VM objects with a domain allocation policy, but that's currently out of scope. I'd also like to plumb in domain configuration into devices and allow devices to allocate memory for different driver threads with different policies.

But the first thing that showed up is that KVA allocation and superpages get in the way of malloc/contigmalloc working. Allocating memory in FreeBSD first allocates KVA space, then back-fills it with pages. As far as malloc/contigmalloc is concerned, KVA is KVA and it finds the first available space in a time-fast way. It then backfills it with physical pages. The superpage reservation bits (sys/vm/vm_reserv.[ch]) join together regions that are contiguous and in the same superpage and turn it into an allocation from the same superpage. These have no idea about NUMA domains. So, if you allocate a 4KiB page via malloc() from domain 0 and then try to allocate a 4KiB page from domain 1, it will likely mess it up:

  • First page gets allocated - first KVA, then the underlying 2mb superpage is allocated and a 4k page is returned - from physical memory domain 0;
  • Second page gets allocated - first KVA, and if it's adjacent or within the same 2mb superpage as the above allocation, it'll "fake" the page allocation via refcounting and it'll really be that same underlying superpage - but it's from physical memory domain 0.
I have to teach both vm_reserv and the KVA allocator about NUMA domains, enough so domain specific allocations don't use KVA that's adjacent. It was suggested that I create a second layer of KVA allocators that allocate KVA from the main resource allocator in superpage chunks (here it's 2mb) and then I do domain-specific allocations from them. It'll change how things get fragmented a bit, but it does mean that I won't fall afoul of things.

So, I'll do the above as an experiment and I'll push the VM policy evaluation up a little into malloc/contigmalloc. I'll see how that experiment goes and I'll post diffs for testing/evaluation.

The importance of mentoring, or "how I got involved in FreeBSD"..

Here's how I was introduced into this UNIX world, or "wait, WHO was your WHAT?"

So, here's 11ish or so year old Adrian. It's the early 90s. I was hiding in my bedroom, trying to make another crystal set out of random parts and scraping away the paint at my windowsill. In walks my Aunty, who introduces her new boyfriend.

"Hi, I'm Julian." he said. That wasn't all that interesting.

"Oh, are you making a crystal set?" .. ok, so that was interesting.

And, that was that. Suddenly, someone role-model-y shows up in my life out of the blue. There I was, an 11 year old who felt very mostly alone most of the time, and someone shows up who I can look up to and think I can relate to. So, I'm a sponge for everything he shows me. Whenever he comes over, he has some new story to tell, some new thing to show me. He would show me better ways of building transistor switch circuits when I was in the "make large arcs with car alternator" phase of my early teens. And, when I saved up and bought a PC, he started to show me programming.

Now, I was already programming. My parents had saved up and bought me an Amstrad CPC464. We had a second-hand commodore 64 for a short while, but that eventually somehow stopped working and I didn't have the clue to fix it. But I was programming Locomotive BASIC and dabbling in Z80 assembly when I was 12, and had "upgraded" to Turbo Pascal 6 when I hit high school. (Yes, school taught Turbo Pascal at Grade 10 level, and I decided to learn it a bit earlier. That's .. wow, that dates me.) I hadn't yet really stumbled into C yet. I had heard about it, but I didn't have anything that could write it.


Julian explained task switching to me one day during a walk along the beach. He explained that computers can just appear to be doing multiple things at once - but the CPU only does one thing at a time, and you can just switch things really quickly to give the appearance that it's multitasking. With that bright spark planted in my head, I went home and started dreaming up ways to make my Z80 based CPC do something like this.

My mother dragged me to McDonalds to apply for a job the moment I was legally able to (14 years, 9 months) and I saw a computer at a second hand shop - it was a $500 IBM PC/AT, with EGA monitor, two floppy disks and a printer. We put down a down-payment and I paid it off myself with my minimum wage money. Once I had that home I quickly erm, "acquired" a copy of Turbo Pascal for home and was off drawing funny little fractals.

So yes - it's Julian's fault I discovered FreeBSD. Yes, this is Julian Elischer. One day he showed me his computer, running something called BSD. He was trying to explain bourne shell scripting and the installer. I nodded, very confused, and eventually went back to the VGA programming book he lent me. He also showed me fractint running in X on his monochome 486 DX2-50 laptop. I had no idea what was going on under the scenes, only that the fractals were much more interesting than the ones I was drawing. So I took the VGA book home and started learning how to use the higher resolutions available. One thing stuck in my mind: so much bit-plane work. Ugh. One other thing stuck in my mind - reading from VGA memory is one of the slowest things you can do. Don't do it. Ever. (Do you hear that console driver authors? Don't do it. It's bad.)

One day he explained pointers to me. I had erm, "acquired" a copy of Turbo C 2.0 from a friend after failing to make much traction with the less friendly versions (Tiny C, for example.) I had coded up a few things, but I didn't really "get" it. So he sat me down with a pen and paper, and drew diagrams to explain what was going on. I remember that lightbulb going off in the back of my mind, as I dimly connected the whole idea of types and sizes together - and that was it. I was off and doing bad things to C code.

I eventually saved up enough for an updated 286 motherboard, then an updated graphics card (full VGA!), then a sound blaster card, and finally a 486-DX33 motherboard. He introduced me to his friend Peter (who had, and I believe still has, a rather extensive electronics collection) and handed me a FreeBSD-1.1 CDROM. I took it home, put it in, and .. it didn't do anything. My 486 had a soundblaster pro + CD-ROM, and .. well, FreeBSD-1.1 didn't speak to that hardware. So, I eventually put Slackware Linux 3.0 on the thing, and became a Linux nerd for a bit.

I did eventually try FreeBSD-1.1 on it - after putting a lot of FreeBSD bits on a lot of floppies - but I couldn't figure out what to do when it booted. This is going to sound silly - but the lack of colorls turned me off. I know, it seems silly now, but that's honestly why I went back to Slackware.

I eventually went back to FreeBSD in the 2.x era once I had an IDE CDROM and I was working part time at an ISP after (high) school finished. Yes, I figured out how to get colorls to work, I got in trouble disagreeing with a Michael (O, not M) at iiNet about Squid on Linux versus FreeBSD, and well.. stuff. Here was this 17yo kid disagreeing with things and acting like he knew everything. I'm sure it was endearing.

Fast-forward a couple years, and I had been hacking on FreeBSD here and there. I got in a little erm, "trouble" before I finished high school, which phk reminded me of - when they granted me a commit bit. I forget when this was, but I wouldn't have been much older than 20.

So - this is why mentoring kids is important. It may seem like a waste of time; it may seem like they don't understand, but we were all there once. We wanted someone to relate to, someone to look up to, and something interesting to do. Julian was that person for me, and I owe both him and my mother (of course) pretty much everything about my existence in this silly little computer industry.

(This is also why you don't skimp on hardware support for popular, if cheaper platforms and "shiny" looking features if you want people to adopt your stuff -  but that's a different rant.)

Ok, that's done. I'm going back to hacking on VGA/VESA boot loader support for FreeBSD-HEAD. That's long overdue, and I want my pretty splash screen.

FreeBSD 10.2-BETA1 Now Available

The first BETA build of the 10.2-RELEASE cycle is now available.

Installation images are available for the amd64, armv6, i386, ia64, powerpc, powerpc64, and sparc64 architectures.

Additionally, FreeBSD 10.2-BETA1 is available on several third-party hosting providers.

See the PGP-signed announcement email for installation image checksums and more information.

FreeBSD 10.2-BETA1 Available

The first BETA build for the FreeBSD 10.2 release cycle is now available. ISO images for the amd64, armv6, i386, ia64, powerpc, powerpc64 and sparc64 architectures are available on most of our FreeBSD mirror sites.