FreeBSD Work (week #2) This is ONLY week 2...

As I mentioned two weeks ago, I’ve transitioned into a new role at Intel. The team is very new and so a lot of my part right now is helping out in organizing the game plan.

Last week I attended BSDCan 2018 as well as the FreeBSD dev summit. That trip in addition to feedback I got both here on my blog and twitter has helped me compile a decent list of things to do. Thank you all for the feedback so far. For the sake of soliciting possibly more feedback, here is the list. Do remember that I’m employed by Intel and that if you want to recommend something there should be at least some way to tie that back for being good for Intel’s product, and reputation.

HW Feature EnablingIntel 100GbEMake it work well.
Performance Monitoringpmc/pcmMake sure VTune works well on Intel products.
ScalabilityNUMA improvementsMake systemwide NUMA support better. I need to add more detail here.
HW Feature EnablingIntel GraphicsCreate native Intel graphics driver.
HW Feature EnablingThunderbolt 3
HW Feature Enabling3D XPoint
HW Feature Enabling (Security)Control-flow Enforcement Technology (CET)
HW Feature EnablingVolume Management Device (VMD)
Scalabilityinotify/fsevents equivalent.Kqueue doesn't scale well.
ScalabilitytaskqueuesThis was noted at DevSummit, but I don't have details.
Power ManagementImprove framework.Provide support for opportunistic S0iX
Power ManagementHibernateS4 Support
HW Feature Enabling (Security)MKTME Support
HW Feature Enabling (security)TPMImproved TPM support. Need to get more specifics
Security/StabilityFuzzingImprove syzkaller
VirtualizationBhyveMake something better than
VirtualizationGraphics PassthroughVT-d
WirelessImprove 802.11AC stack
WirelessIntel 802.11AC support
PerformanceDecrease boot time.parallel AP start
Feature EnablingeBPF verifier
JanitorialUnify i386, xmd64, and x86 directories
?nvme rehashMentioned in DevSummit, but no details.
NetworkingALTQ ReplacementI don't even know what this means yet...
GraphicsHelp i915 drm-next-kmod work
ToolsAMT tools

25 thoughts on “FreeBSD Work (week #2) This is ONLY week 2...

    1. The current OpenBSD PF version is incompatible with previous versions of PF, like the one included in FreeBSD.

      Because OpenBSD have very short support cycles and significantly smaller user base, it’s easier to expect from their users to follow breaking changes.
      On the other hand FreeBSD have rather long support cycles and tends to avoid breaking changes in the name of the POLA.

      You should also remember that the internals of PF version included in FreeBSD are very different from the OpenBSD’s version. A lot of code was rewritten to adjust for better SMP utilisation and smaller lock congestion.

      Based on this constrains, port of the new syntax/version would be rather uneasy, long, and introducing unwanted breaking changes.

      1. Newer PF is also included in Solaris 11.x and Aleksander Nedevdicky from Oracle pushed a lot of SMP patches upstream (e.g. to OpenBSD) where they were merged IIRC. So perhaps it’s not that bad as you suggest it to be…

  1. Asa FreeBSD user both on servers and desktops for 15 years I’m looking forward to the contributions from the team!

  2. Maybe, udisk implementation as most DE still relies on HAL for tasks like automounting, however I fail to see how this can promote Intel products.

  3. Kqueue does not scale? That’s the first time I’ve ever heard those words. Does anyone have any more information on what this is referring too??

    1. That is a well know fact actually. The main problem of kqueue is the fact it does need to open one file descriptor for each file. Try to use kqueue to watch a huge number of files (like half million at least) and the problem will appear be very quick, specially the high a mount of memory usage.

      Kqueue was actually created to monitor UNIX sockets.

  4. Make FreeBSD stop being so leaky. Sysctl, for instance, leak a lot of important information to any one willing to see it. 😉

  5. Great part of the SMP work were already made on (DragonFly BSD)[]. The code base is very different since DFBSD was forked about two decades ago but there is a path already.

    The most difficult part would probably be FreeBSD Kernerl/Network-Meisters do agree to accept DFBSD code, what means accept Matthew Dillon[1] code, who was fired many years ago exacly because he wanted to implement SMP improvements (similar to what happened recently with John Marino[2] when he wanted to fix the FreeBSD ports system (mess)[] and hit the ego of ‘someone’ with influence and was silent fired with (no reason)[]).

    [1] not to say the guy wrote HammerFS(2) amost alone.
    [2] also created (ports-mgmt/synth)[] which the same people didn’t like the success of it.

  6. More ‘lobbying’ than developing, but any interest and/or chance to try to bring AdaCore close —> looking to Ada/SPARK languages popularization?

    Also, an interesting initiative from AdaCore, HERE.

    Thanks! 😀

  7. If a native graphics driver is important enough to Intel, this implies that they are trying to increase support for desktop/laptop/workstation FreeBSD users. I don’t see how there is much of an advantage to Intel for doing this, but as long as it’s on the list, how about looking into better input device support?

    FreeBSD doesn’t have a real evdev/udev implementation. AFAIK all Linux input drivers interface with evdev, and most modern applications that want to talk to an input device ( Xorg, Games, Emulators etc ) primarily support evdev/udev.

    Without this, application support for touchscreens, drawing tablets, multitouch trackpads, and even simpler devices like gamepad controllers will continue to be abysmal/non-existent.

    Again, not sure how it helps Intel, but it goes hand-in-hand with better graphics support.

    1. I’ve been personally working on improving power management, and my colleague has been helping to move forward the nvdimm work being done by kib@. I’ll /hopefully/ be giving a smallish talk at MeetBSD about this in a bit more detail.

  8. Any chance to finally get (after all these years of waiting) inotify/fsevents equivalent to the FreeBSD?
    Modern systems host very large filesystems and if one need to sync changes on some milions files hierarchy, then kqueue/kevent solutions are useless…

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.