I love that colours are back with the iMacs, though their soldered storage makes them a non-starter for me. Still, I thought I would be an interesting experiement to see if PC makers care at all to compete with Apple in the AiO market segment, or whether they’re saddled with PC Screen Syndrome.
I checked a few Australian online stores this morning, and the results were as surprising as discovering that I’m a bit awkward in real life:
Acer, with the only online store that doesn’t make me want to hurl web developers into the sun, sell Aspire C27 27-inch machines from $1,400 to $1,900. Both have low-resolution, low-density 1080p displays.
Asus is the only PC maker making AiO devices with any design sense, and their laptops have HiDPI displays, so I held out hope. They sell M241, V241, V161, and V222 23.8-inch to 27-inch machines for (price withheld). All have low-resolution, low-density 1080p displays. Asus, no! You were supposed to be one of the good ones!
Dell make Inspiron 23.8 and 27-inch machines, from $1,700 to $2,300. All have low-resolution, low-density 1080p displays. Not surprised.
HP make Pavilion and HP-branded 23.8 and 27-inch machines, from $700 to $3,000. All have low-resolution, low-density 1080p displays. Clicking on their 34-inch Envy lines returned no results, but the US store says they’re 1440p, which is still low-density and resolution for the size.
Lenovo make V30a, V50a, and ThinkCentre M90a 22 to 24-inch all-in-one machines, from $1,429 to $1,629. All have low-resolution, low-density 1080p displays. Several of the ThinkPad models have excellent screens, so this was a surprise.
I’m seeing more IPS panels, which is fantastic! Some even have touch screens, something I consider a bit of a gimmick but that Apple doesn’t ship with. But these specs and prices simply don’t compete with a 24-inch iMac with a 4.5K display for $1,900, and a 27-inch 5K iMac for $2,700. You could fit four of those AiO computer screens into one iMac, and the price is barely different!
Apple have sold Retina/HiDPI screen iMacs for years, yet PC makers continue to ship displays with a lower resolution than your phone. Yes I sound like a broken record here, but it’s only because it continues to flabbergast me! That’s a word, right?
You might think the all-in-one desktop segment makes no sense. They don’t for my use cases, either. But the fact PC makers are fine ceding technical superiority to Apple in the interest of pushing 1080p panels that were outdated a decade and a half ago, and for the same money, makes as much sense as enlisting me for your basketball team. Sure I have the height, but my hand-eye coordination is off on account of looking at crappy screens!
This leads me to something I’ve been mulling over for a while now. Why have PC makers lost that spark? Is it margins? Has the mindshare and innovation moved on to phones? Is it Microsoft failing to provide compelling updates for Wintel boxes that would make effective use of the new tech? Are the bean counters in charge of engineering? It seems gaming rigs are the only place where innovation is happening anymore, and have you seen some of those designs? Even teenage Ruben would look at those RGBs and say “that’s a bit much, innit?”
I still remember a time when PC makers could tout the fact that while Apple computers looked better and arguably had a better OS, they had better tech for a cheaper price. All they can claim now in an M1 world is wider compatibility, and even then the industry seems to be moving towards ARM at break arm speed. Get it, instead of break neck speed, because it’s called… oh shut up.
I’ve never exclusively been a Mac user. I’ve tended to use the Mac as my primary desktop/laptop, but delegate as much as I can to a tower and home servers running FreeBSD, NetBSD, and/or Debian Linux as required. The former gave me the best desktop experience to run work applications, and the latter let me tinker and build to an exact specification and price. I haven’t been in the market for a pre-built PC for years, but it’s been grim every time I’ve looked.
The tech is there, PC makers. Please lift your game!
By Ruben Schade in Sydney, 2021-07-22.
The version of qemu in dports is not set up to support this, yet. Until then, you can download a prebuilt version.
More BUG meetings are happening, which is great.
I’m writing this on the road, so it’s a bit low on links. Sorry! I will have much more next week.
Anders Magnusson, writing on the Port-vax NetBSD mailing list:
Some time ago I ended up in an architectural discussion (risc vs cisc etc…) and started to think about vax. Even though the vax is considered the “ultimate cisc” I wondered if its cleanliness and nice instruction set still could be implemented efficient enough. Well, the only way to know would be to try to implement it I had an 15-year-old demo board with a small low-end FPGA (Xilinx XC3S400), so I just had to learn Verilog and try to implement something. And it just passed EVKAA.EXE:
Along with the development of a VAX implementation in an FPGA, discussions arose about possible 64-bit extensions:
For userspace; the vax architecture itself leave the door open for expanding the word size. The instructions are all defined to use only the part of a register it needs, so adding a bunch of ‘Q’ instructions are a no-brainer. Argument reference will work as before. The JMP/JSR/RET/… might need a Q counterpart, since it suddenly store/require 8 bytes instead of 4. Kernel; the hardware structures (SCB, PCB, …) must all be expanded. Memory management changed (but the existing leave much to wish for anyway). All this is probably a quite simple update to the architecture.
It’s nice to see people still putting work and effort into what is nearly a half-century old, and otherwise obsolete, instruction set.
I was searching for something related to pkgsrc, and came across some of my posts quoted on NetBSD Planet. Sure enough, my name is right there in in the footer, alongside some pretty significant names I recognise.
This made my week, I’m genuinely honoured! This also shows I need to write more about NetBSD and pkgsrc.
If this post made it to NetBSD Planet, it’d be a post about NetBSD Planet on NetBSD Planet. Which I’d then have to quote back here. Then if they quoted that, it’d be a NetBSD Planet post on a…
By Ruben Schade in Sydney, 2021-06-18.
Last month I talked about people who get angry or smug at those who run FreeBSD, Linux, and other OSs within VMs, with the implication that they’re not really using them. I pointed out that this was a) technically inaccurate and b) not the way to foster good will or new users in open source software communities.
(The title of that post was originally misspelled as Umbridge instead of Umbrage, which remains in the permalink. It’s the punny name I’ve given to network bridges on personal hypervisors for years, which leads me to instinctively misspell the actual word each time. It’s a bit ironic and especially silly given the topic at hand).
Most of the well-intentioned feedback I’ve had suggests that running an OS directly on a laptop teaches you things you can’t get on a VM. This is a good point; sometimes getting your hands dirty is the best way to learn. Workstation experience doesn’t directly translate to servers, but things like package managers, reading logs, and the boot process certainly would. Who knows, your experience replacing a broken btrfs volume with ZFS might translate into industry experience that will come in handy in the future.
My point wasn’t that running an OS directly on a laptop wasn’t useful, but that it shouldn’t pose a barrier to entry. I’m wary of gatekeepers in general, and this struck me as an especially counterproductive example.
It’s also a wash as far as elitism goes. The most competent, professional, talented people I’ve met at industry events, conferences, and at work all use the right tool for the job, whether they be kernel developers or pre-sales engineers. Unfortunately, that might mean carrying a Mac or Windows machine to use specific software, and a BSD or Linux VM. That VM may be sitting on your local machine or the cloud. Whether you run such an OS directly on your laptop is not indicative of anything useful, nor does it speak to technical competency.
By Ruben Schade in Sydney, 2021-06-11.
What really happens when you double click an icon on your desktop?
Processes are the bread and butter of your operating system. The moment you double click an icon, that particular program gets loaded in your Random Access Memory (RAM) and your operating system starts to run it. At this moment the program becomes a process. Though you can only see the execution of your process, the operating system (the Kernel) is always running a lot of processes in the background to facilitate you.
From the moment you hit that power button, everything that happens on the screen is the result of some or the other process. In this post we are going to talk about one such interface which helps in creation of your programs.
The moment a computer system comes alive, it launches a bunch of processes. For the purpose of this blog let’s call them, ‘the master processes’. These processes run in perpetuity, provided the computer is switched on. One such process is init/systemd/launchd (depending on your OS). This ‘init’ master process owns all the other processes in the computer, either directly or indirectly.
Operating systems are elegant, majestic software that work seamlessly under the hood. They do so much without even breaking a sweat (unless it’s Windows). Let's consider a scenario where you have decided to take a trip down memory lane and burst open those old photos. The ‘init master process’ just can’t terminate itself and let you look at your photos. What if you unknowingly open a malicious file, which corrupts all your data? So init doesn’t just exit, rather it employs fork() and exec() to start a new process. The fork() function is used to create child processes which are an exact copy of their parents. Whichever process calls fork, gets duplicated. The newly created process becomes the child of the original running process and the original running process is called the parent. Just how parents look after their kids, the parent process makes sure that the child process doesn't do any mischief. So now you have two exactly similar processes running in your computer.
One might think that the newly created child process doesn’t really help us. But actually, it does. Now exec() comes into the picture. What exec() does is, it replaces any process which calls it. So what if we replace the child process, the one we just thought to be useless, with our photos? That's exactly what we are going to do indeed. This will result in replacement of the fork() created child process with your photos. Therefore, the master init process is still running and you can also enjoy your photos with no threat to your data.“Neither abstraction nor simplicity is a substitute for getting it right. Sometimes, you just have to do the right thing, and when you do, it is way better than the alternatives. There are lots of ways to design APIs for process creation; however, the combination of fork() and exec() is simple and immensely powerful. Here, the UNIX designers simply got it right.” Lampson’s Law - Getting it Right
Now you could ask me, `But what about the title, some ‘posix_spawn()’ thing?´ Don’t worry, that’s next.
posix_spawn() is an alternative to the fork() + exec() routine. It implements fork() and exec(), but not directly (as that would make it slow, and we all need everything to be lightning fast). What actually happens is that posix_spawn() only implements the functionality of the fork() + exec() routines, but in one single call. However, because fork() + exec() is a combination of two different calls, there is a lot of room for customization. Whatever software you are running on your computer, calls these routines on its own and does the necessary. Meanwhile a lot is cooking in the background. Between the call to fork() and exec() there is plenty of leeway for tweaking different aspects of the exec-ing process. But posix_spawn doesn’t bear this flexibility and therefore has a lot of limitations. It does take a lot of parameters to give the caller some flexibility, but it is not enough.
Now the question before us is,
“If fork() + exec() is so much more powerful, then why have,
or use the posix_spawn() routine?” The answer to that is, that
fork() and exec() are UNIX system routines.
They are not present in operating systems that are not a derivative of UNIX.
Eg- Windows implements a family of spawn functions.
There is another issue with fork() (not exec() ), which in reality is one of the biggest reasons behind the growth of posix_spawn(). The outline of the issue is that, creating child processes in multi-threaded programs is a whole another ball game altogether.
Concurrency is one of those disciplines in operating systems where the order in which the cards are going to unravel is not always how you expect them to. Multi-threading in a program is a way to do different and independent tasks of a program simultaneously, to save time. No matter how jazzy or intelligent the above statement looks, multi-threaded programs require an eagle’s eye as they can often have a lot of holes. Though the “tasks” are different and independent, they often share a few common attributes. When these different tasks due to concurrency start running in parallel, a data race begins to access those shared attributes. To not wreak havoc, there are mechanisms through which, when modifying/accessing these common attributes (Critical Section) we can provide a sort of mutual exclusion (locks/conditional variables) - only letting one of the processes modify the shared attribute at a time. Here when things are already so intricate due to multithreading, and to top it off, we start creating child processes. Complications are bound to arise. When one of the threads from the multi-threaded program calls fork() to create a child process, fork() does clone everything (variables, their states, functions, etc) but it fails to clone other threads (though this is not required at all times).
The child process now knows only about that one thread which called fork(). But all the other attributes of the child that were inherited from the parent (locks, mutexes) are set from the parent’s address space (considering multiple threads). So there is no way for the child process to know which attributes conform to which parts of the parent. Also, those mechanisms that we used to provide mutual exclusion, like locks and conditional variables, need to be reset. This reset step is essential in letting the parent access it’s attributes. Failing this reset can cause deadlocks. To put it simply, you can see how difficult things have become all of a sudden. The posix_spawn() call is free from these limitations of fork() encountered in multi-threaded programs. However, as mentioned by me earlier, there needs to be enough rope to meet all the requirements before posix_spawn() does the implicit exec().
Hi, I am Piyush Sachdeva and I am going to start a project which will focus on relaxing one limitation of posix_spawn - changing the current directory of the child process, before the said call to exec() is made. This is not going to restrict it to the parent’s current working directory. Just passing the new directory as one of the parameters will do the trick. Resolving all the impediments would definitely be marvelous. Alas! That is not possible. Every attempt to resolve even a single hindrance can create plenty of new challenges.
As already mentioned by me, posix_spawn() is a POSIX standard. Hence the effect of my project will probably be reflected in the next POSIX release. I came across this project through Google Summer of Code 2021. It was being offered by The NetBSD Foundation Inc. However, as the slots for Google Summer of Code were numbered, my project didn’t make the selection. Nevertheless, the Core Team at The NetBSD Foundation offered me to work on the project and even extended a handsome stipend. I will forever be grateful to The NetBSD Foundation for this opportunity.
I've been wanting to learn more about compilers and toolchains in general for a while now. In June 2016, I asked about recommended readings on lexers and parsers on Twitter. However, I have to confess that I didn't go forward with reading the Dragon Book.
Instead, I got involved as a developer in the OpenBSD and NetBSD projects, and witnessing the evolution of toolchains within those systems played a big role in maintaining my interest and fascination in the topic. In retrospect, it now becomes apparent that the work I did on porting and packaging software for those systems really helped to put in perspective how the different parts of the toolchains interact together to produce binaries.
Approximately one year ago, I asked again on Twitter whether I knew anyone having worked on compilers and toolchains professionally to get real world advice on how to gain expertise in the field. I got several interesting answers and started to collect and read more resources on the topic. Some of the links I collected ended up on toolchains.net, a collection of toolchain resources which I put online in February.
But the answer that resonate the most with me was Howard's advice to learn by doing. Because I seem to be the kind of person who need to see some concrete results in order to keep motivated, that's exactly what I decided to do.
Meanwhile, I also got the opportunity to update our package and apply security fixes:
I eventually took maintainership of binutils in Pkgsrc.
Building it repeatedly with different compilers exposed different warnings, and I've also run builds through Clang's static analyzer.
All of this resulted in the opportunity to contribute to binutils itself:
Most recently, I also wrote a couple of blog posts on the topic:
And the journey continues. I'm following a different path from traditional compiler courses starting with lexers and parsers, and doing the opposite curriculum somehow, starting from binaries instead. I will be focusing on the final stages of the pipeline for now: compiling assembly to machine code and producing binaries.
My next steps are to read the full ELF specification, followed by the Linkers and Loader book, and then refresh my ASM skills. My favorite course at university was the computer architecture one and especially its MIPS assembly part, so I'm looking to revisit the subject but with ARM64 assembly this time.
I’ve been a NetBSD developer for three years and it’s been my primary operating system for a long time too – on everything: routers, laptops, Raspberry Pis, PowerPC mac minis, Vortex86 embedded boards, and servers.
I’ve recently been using FreeBSD a lot at work. We have a lot of servers and embedded boards running it, and I was given the option of installing anything I wanted on my workstation. I chose FreeBSD to maintain a separation of BSDs between my work and home life
I thought I’d write a little bit about some differences that stand out to me. Since everyone that knows me well knows that typical use cases like web hosting aren’t really my jam, and I’m more of an embedded, audio, and graphics person, maybe I can offer a more uncommon perspective.
It’s always nice to read perspectives like this.
pkg_add(1): moved the default package database location on new installations from /var/db/pkg to /usr/pkg/pkgdb, for consistency with the pkgsrc bootstrap and pkgsrc on other platforms. It can be overridden in pkg_install.conf(5).
By Ruben Schade in Sydney, 2021-06-04.
I'm not exactly sure how I first heard about the Vortex86 CPUs, I think it was either when seeing the demonstration video on KolibriOS project site showcasing the system running on a DMP EBOX machine, or when skimming NetBSD's identcpu.c code. Or did the discovery of the machine prompted me to check if the CPU would be correctly probed by the NetBSD's kernel?
For those interested, Wikipedia has an article retracing the history of the Vortex86 from its birth at Rise to our days.
Several DMP EBOX machines are available for sale at various specialized vendors, but new devices cost several hundreds of dollars which is prohibitive for such low spec systems. However, I was recently able to acquire a boxed older model on a local auction site for about $25: the EBOX 3300A-H, with a 1GHz CPU and 256MB of RAM, no less.
As I already mentioned, those machines are quite slow but they still do have a few things going for them:
I used a power meter to do measurements, and an idle system consumes 5.3W. Power consumption peaked at 6.4W when running the OpenSSL speed benchmark.
There is space for a 2.5" hard drive in the enclosure, but I don't have any IDE drives anymore so I opted to use old CompactFlash cards I had laying around. As a side note, it's actually exquisite to use those cards like glorified floppies :-)
For this post, I used a 1GB CompactFlash card and selected a minimal installation in sysinst.
The installed system takes 212M:
Filesystem Size Used Avail %Cap Mounted on /dev/wd0a 919M 212M 661M 24% / kernfs 1.0K 1.0K 0B 100% /kern ptyfs 1.0K 1.0K 0B 100% /dev/pts procfs 4.0K 4.0K 0B 100% /proc tmpfs 64M 0B 64M 0% /var/shm
On a freshly booted system, 15 processes are running and 26M of RAM are used:
load averages: 0.01, 0.00, 0.00; up 0+00:48:26 14:48:28 16 processes: 15 sleeping, 1 on CPU CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Memory: 26M Act, 6460K Exec, 12M File, 195M Free Swap: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 0 root 96 0 0K 26M usbevt 0:01 0.00% 0.00% [system] 795 root 43 0 6160K 1628K CPU 0:00 0.00% 0.00% top 555 root 85 0 12M 3472K wait 0:00 0.00% 0.00% login 630 postfix 85 0 13M 3220K kqueue 0:00 0.00% 0.00% qmgr 599 postfix 85 0 12M 3172K kqueue 0:00 0.00% 0.00% pickup 575 root 85 0 13M 2304K kqueue 0:00 0.00% 0.00% master 196 root 85 0 9780K 1960K kqueue 0:00 0.00% 0.00% syslogd 583 root 85 0 6788K 1824K wait 0:00 0.00% 0.00% sh 710 root 85 0 6276K 1448K nanoslp 0:00 0.00% 0.00% cron 733 root 85 0 6108K 1396K ttyraw 0:00 0.00% 0.00% getty 730 root 85 0 5720K 1392K ttyraw 0:00 0.00% 0.00% getty 633 root 85 0 6104K 1388K ttyraw 0:00 0.00% 0.00% getty 211 root 85 0 7316K 1360K kqueue 0:00 0.00% 0.00% dhcpcd 1 root 85 0 6600K 1340K wait 0:00 0.00% 0.00% init 689 root 85 0 5700K 1184K kqueue 0:00 0.00% 0.00% inetd 402 root 84 0 5920K 1140K kqueue 0:00 0.00% 0.00% powerd
Here is the result of running cat /proc/cpuinfo on this device:
processor : 0 vendor_id : Vortex86 SoC cpu family : 5 model : 2 model name : Vortex86DX stepping : 2 cpu MHz : 1000.05 apicid : 0 initial apicid : 0 fdiv_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu tsc cx8 clflush size : 0
For the record, OpenSSL speed benchmark results are available here.
System message buffer (dmesg output):
[ 1.000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, [ 1.000000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, [ 1.000000] 2018, 2019, 2020 The NetBSD Foundation, Inc. All rights reserved. [ 1.000000] Copyright (c) 1982, 1986, 1989, 1991, 1993 [ 1.000000] The Regents of the University of California. All rights reserved. [ 1.000000] NetBSD 9.2 (GENERIC) #0: Wed May 12 13:15:55 UTC 2021 [ 1.000000] [email protected]:/usr/src/sys/arch/i386/compile/GENERIC [ 1.000000] total memory = 255 MB [ 1.000000] avail memory = 231 MB [ 1.000000] rnd: seeded with 66 bits [ 1.000000] timecounter: Timecounters tick every 10.000 msec [ 1.000000] Kernelized RAIDframe activated [ 1.000000] running cgd selftest aes-xts-256 aes-xts-512 done [ 1.000000] timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 [ 1.000003] Generic PC [ 1.000003] mainbus0 (root) [ 1.000003] Firmware Error (ACPI): A valid RSDP was not found (20190405/tbxfroot-261) [ 1.000003] autoconfiguration error: acpi_probe: failed to initialize tables [ 1.000003] ACPI Error: Could not remove SCI handler (20190405/evmisc-312) [ 1.000003] cpu0 at mainbus0 [ 1.000003] cpu0: Vortex86DX, id 0x522 [ 1.000003] cpu0: package 0, core 0, smt 0 [ 1.000003] pci0 at mainbus0 bus 0: configuration mode 1 [ 1.000003] pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok [ 1.000003] pchb0 at pci0 dev 0 function 0: vendor 17f3 product 6021 (rev. 0x02) [ 1.000003] vga0 at pci0 dev 3 function 0: vendor 18ca product 0020 (rev. 0x00) [ 1.000003] wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation) [ 1.000003] wsmux1: connecting to wsdisplay0 [ 1.000003] drm at vga0 not configured [ 1.000003] rdcpcib0 at pci0 dev 7 function 0: vendor 17f3 product 6031 (rev. 0x02) [ 1.000003] rdcpcib0: watchdog timer configured. [ 1.000003] vte0 at pci0 dev 8 function 0: vendor 17f3 product 6040 (rev. 0x00) [ 1.000003] vte0: Ethernet address 00:1b:eb:22:16:5c [ 1.000003] vte0: interrupting at irq 10 [ 1.000003] rdcphy0 at vte0 phy 1: R6040 10/100 media interface, rev. 1 [ 1.000003] rdcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto [ 1.000003] ohci0 at pci0 dev 10 function 0: vendor 17f3 product 6060 (rev. 0x12) [ 1.000003] ohci0: interrupting at irq 11 [ 1.000003] ohci0: OHCI version 1.0, legacy support [ 1.000003] usb0 at ohci0: USB revision 1.0 [ 1.000003] ehci0 at pci0 dev 10 function 1: vendor 17f3 product 6061 (rev. 0x03) [ 1.000003] ehci0: interrupting at irq 11 [ 1.000003] ehci0: BIOS has given up ownership [ 1.000003] ehci0: EHCI version 1.0 [ 1.000003] ehci0: 1 companion controller, 2 ports: ohci0 [ 1.000003] usb1 at ehci0: USB revision 2.0 [ 1.000003] ohci1 at pci0 dev 11 function 0: vendor 17f3 product 6060 (rev. 0x12) [ 1.000003] ohci1: interrupting at irq 11 [ 1.000003] ohci1: OHCI version 1.0, legacy support [ 1.000003] usb2 at ohci1: USB revision 1.0 [ 1.000003] ehci1 at pci0 dev 11 function 1: vendor 17f3 product 6061 (rev. 0x03) [ 1.000003] ehci1: interrupting at irq 11 [ 1.000003] ehci1: BIOS has given up ownership [ 1.000003] ehci1: EHCI version 1.0 [ 1.000003] ehci1: 1 companion controller, 2 ports: ohci1 [ 1.000003] usb3 at ehci1: USB revision 2.0 [ 1.000003] rdcide0 at pci0 dev 12 function 0: RDC R1011 IDE controller (rev. 0x01) [ 1.000003] rdcide0: bus-master DMA support present [ 1.000003] rdcide0: primary channel configured to compatibility mode [ 1.000003] rdcide0: primary channel interrupting at irq 14 [ 1.000003] atabus0 at rdcide0 channel 0 [ 1.000003] rdcide0: secondary channel configured to compatibility mode [ 1.000003] rdcide0: secondary channel interrupting at irq 15 [ 1.000003] atabus1 at rdcide0 channel 1 [ 1.000003] isa0 at rdcpcib0 [ 1.000003] pckbc0 at isa0 port 0x60-0x64 [ 1.000003] attimer0 at isa0 port 0x40-0x43 [ 1.000003] pcppi0 at isa0 port 0x61 [ 1.000003] midi0 at pcppi0: PC speaker [ 1.000003] sysbeep0 at pcppi0 [ 1.000003] isapnp0 at isa0 port 0x279 [ 1.000003] attimer0: attached to pcppi0 [ 1.000003] isapnp0: no ISA Plug 'n Play devices found [ 1.000003] timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0 [ 1.064509] uhub0 at usb1: NetBSD (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1 [ 1.064509] uhub0: 2 ports with 2 removable, self powered [ 1.064509] uhub1 at usb2: NetBSD (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1 [ 1.064509] uhub1: 2 ports with 2 removable, self powered [ 1.064509] uhub2 at usb3: NetBSD (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1 [ 1.064509] uhub2: 2 ports with 2 removable, self powered [ 1.064509] uhub3 at usb0: NetBSD (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1 [ 1.064509] uhub3: 2 ports with 2 removable, self powered [ 1.064509] IPsec: Initialized Security Association Processing. [ 3.914550] uaudio0 at uhub3 port 2 configuration 1 interface 0 [ 3.914550] uaudio0: vendor 0d8c (0xd8c) C-Media USB Audio Device (0x08), rev 1.10/1.00, addr 2 [ 3.934546] uaudio0: audio rev 1.00 [ 3.934546] audio0 at uaudio0: playback, capture, full duplex, independent [ 3.934546] audio0: slinear_le:16 2ch 48000Hz, blk 11520 bytes (60ms) for playback [ 3.934546] audio0: slinear_le:16 1ch 48000Hz, blk 6000 bytes (62.5ms) for recording [ 3.934546] uhidev0 at uhub3 port 2 configuration 1 interface 3 [ 3.934546] uhidev0: vendor 0d8c (0xd8c) C-Media USB Audio Device (0x08), rev 1.10/1.00, addr 2, iclass 3/0 [ 3.944550] uhid0 at uhidev0: input=4, output=4, feature=0 [ 4.054550] wd0 at atabus1 drive 0 [ 4.054550] wd0: <Hitachi XX.V.126.96.36.199> [ 4.054550] wd0: drive supports 1-sector PIO transfers, LBA addressing [ 4.054550] wd0: 977 MB, 1987 cyl, 16 head, 63 sec, 512 bytes/sect x 2002896 sectors [ 4.064551] wd0: 32-bit data port [ 4.064551] wd0: drive supports PIO mode 4 [ 4.064551] wd0(rdcide0:1:0): using PIO mode 4 [ 4.084559] WARNING: 1 error while detecting hardware; check system log. [ 4.084559] boot device: wd0 [ 4.084559] root on wd0a dumps on wd0b [ 4.094550] root file system type: ffs [ 4.094550] kern.module.path=/stand/i386/9.2/modules [ 20.764808] wsdisplay0: screen 1 added (80x25, vt100 emulation) [ 20.784809] wsdisplay0: screen 2 added (80x25, vt100 emulation) [ 20.794810] wsdisplay0: screen 3 added (80x25, vt100 emulation) [ 20.804812] wsdisplay0: screen 4 added (80x25, vt100 emulation)
Due to the unfortunate situation regarding changes in administration on freenode.net, and the resulting chaos, we have decided to move the public NetBSD IRC chat channels from freenode to irc.libera.chat.
You can find information on connecting to Libera at https://libera.chat/
For the last few weeks, I’ve been doing lots of testing of NetBSD‘s build.sh cross-build system on lots of different platforms. Linux is readily available on AWS, as is FreeBSD. You will find NetBSD and OpenBSD in some AWS locations. It’s more difficult to get the BSDs onto AWS because the standard upload tools detect the filesystems and if they are not on the list, the image is not allowed. The BSD FFS and variants are not on the list.
Fortunately there are other tools and other ways to build images. It’s a little protracted. You need to first build a VM, convert it to VMDK, upload it to S3, create a snapshot and then convert it to an AMI.
This set of scripts (by Antoine Jacoutot) does the hard work for you and works for OpenBSD 6.5 up to 6.8. Last night, I created my own fork here which also works for 6.9. Essentially the difference is that the OpenBSD install kernel is compressed and the script now decompresses it and recompresses it where needed.
So as a result on AWS eu-west-2 (London), there are are AMIs for OpenBSD 6.5 through to 6.9. Just search for OpenBSD when you want to launch an image.
There are NetBSD images out there but I’m hoping to get around to producing some too.
I am trying to assemble a simple Hello World program with the GNU assembler (as) on a Raspberry Pi 3 B+ running NetBSD 9.1
What flags do I need to add to as or ld to make them assemble the code correctly for the architecture I am using?
$ as -o hllwrld.o hllwrld.s $ ld -o hllwrld hllwrld.o $ ./hllwrld -sh: Cannot execute ELF binary ./hllwrld $ uname -a NetBSD rpi 9.1 NetBSD 9.1 (RPI) #0: Sun Oct 18 19:24:30 UTC 2020 [email protected]:/usr/src/sys/arch/evbarm/compile/RPI evbarm
Is this aarch64 or arm64?
I know there are man pages but I am just learning assembly so I have no idea what configurations/flags/arguments I even need to be looking for.
Thanks for any help.
The NetBSD Project is pleased to announce NetBSD 9.2, the second update of the NetBSD 9 release branch.
It represents a selected subset of fixes deemed important for security or stability reasons since the release of NetBSD 9.1 in October 2020, as well some enhancements backported from the development branch. It is fully compatible with NetBSD 9.0.
I’m not even remotely well-versed enough in NetBSD to make heads or tails of the changelog, but it seems like there’s quite a few notable ones in there.
The NetBSD Project is pleased to announce NetBSD 9.2 "Nakatomi Socrates", the second update of the NetBSD 9 release branch.
As well as the usual bug, stability, and security fixes, this release includes: support for exporting ZFS filesystems over NFS, various updates to the bozotic HTTP daemon, improvements to ARM 32-bit and Linux compatibility,
fread() performance improvements, support for the TP-Link TL-WN821N V6 wireless adapter, support for the Allwinner H5 cryptographic accelerator, Pinebook Pro display brightness fixes, new defaults for
kern.maxfiles, and accessibility improvements for the default window manager configuration.
This post is the AArch64 counterpart of my "Speedbuilding LLVM/Clang in 5 minutes" article.
After publishing and sharing the previous post URL with some friends on IRC, I was asked if I wanted to try doing the same on a 160 cores ARM machine. Finding out what my answer was is left as an exercise to the reader :-)
The system I'm using for this experiment is a BM.Standard.A1.160 bare-metal machine from Oracle Cloud, which has a dual-socket motherboard with two 80 cores Ampere Altra CPUs, for a total 160 cores, and 1024 GB of RAM. This is to the best of my knowledge the fastest AArch64 server machine available at this time.
The system is running Oracle Linux Server 8.3 with up-to-date packages and kernel.
The full result of cat /proc/cpuinfo is available here.
uname -a Linux benchmarks 5.4.17-2102.201.3.el8uek.aarch64 #2 SMP Fri Apr 23 09:42:46 PDT 2021 aarch64 aarch64 aarch64 GNU/Linux
Let's start by installing required packages:
dnf in clang git lld
Unfortunately the CMake version available in the packages repository (3.11.4) is too old to build the main branch of the LLVM Git repository, and Ninja is not available either.
Let's bootstrap Pkgsrc to build and install them:
git clone https://github.com/NetBSD/pkgsrc.git cd pkgsrc/bootstrap ./bootstrap --make-jobs=160 --unprivileged ===> bootstrap started: Wed May 12 12:23:34 GMT 2021 ===> bootstrap ended: Wed May 12 12:26:08 GMT 2021
We then need to add ~pkg/bin and ~pkg/sbin to the path:
For faster Pkgsrc builds, we can edit ~/pkg/etc/mk.conf and add:
Let's build and install CMake and Ninja:
cd ~/pkgsrc/devel/cmake bmake install package clean clean-depends cd ~/pkgsrc/devel/ninja-build bmake install package clean clean-depends
The compiler used for the builds is Clang 10.0.1:
clang --version clang version 10.0.1 (Red Hat 10.0.1-1.0.1.module+el8.3.0+7827+89335dbf) Target: aarch64-unknown-linux-gnu Thread model: posix InstalledDir: /bin
Regarding linkers, we are using GNU ld and GNU Gold from binutils 2.30, and LLD 10.0.1.
GNU ld version 2.30-79.0.1.el8 GNU gold (version 2.30-79.0.1.el8) 1.15 LLD 10.0.1 (compatible with GNU linkers)
For all the following runs, I'm building from the Git repository main branch commit cf4610d27bbb5c3a744374440e2fdf77caa12040. The build directory is of course fully erased between each run.
commit cf4610d27bbb5c3a744374440e2fdf77caa12040 Author: Victor Huang <[email protected]> Date: Wed May 12 10:56:54 2021 -0500
I'm not sure what the underlying storage is, but with 1 TB of RAM there is no reason not to use a ramdisk.
mkdir /mnt/ramdisk mount -t tmpfs -o size=32g tmpfs /mnt/ramdisk cd /mnt/ramdisk
To get a baseline, let's do a full release build on this machine:
cd llvm-project mkdir build cd build cmake -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_COMPILER=clang++ \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_ENABLE_PROJECTS=clang \ ../llvm time make -j160 real 7m3.226s user 403m28.362s sys 6m41.331s
By default, CMake generates Makefiles. As documented in the "Getting Started with the LLVM System" tutorial, most LLVM developers use Ninja.
Let's switch to generating Ninja build files, and using ninja to build:
cmake -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_COMPILER=clang++ \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_ENABLE_PROJECTS=clang \ -GNinja ../llvm time ninja [4182/4182] Linking CXX executable bin/c-index-test real 4m20.403s user 427m27.118s sys 7m2.320s
By default, GNU ld is used for linking. Let's switch to using gold:
cmake -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_COMPILER=clang++ \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_ENABLE_PROJECTS=clang \ -DLLVM_USE_LINKER=gold \ -GNinja ../llvm time ninja [4182/4182] Linking CXX executable bin/c-index-test real 4m1.062s user 427m1.648s sys 6m58.282s
LLD has been a viable option for some years now. Let's use it:
cmake -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_COMPILER=clang++ \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_ENABLE_PROJECTS=clang \ -DLLVM_USE_LINKER=lld \ -GNinja ../llvm time ninja [4182/4182] Linking CXX executable bin/clang-scan-deps real 3m58.476s user 428m3.807s sys 7m14.418s
Using GNU gold instead of GNU ld results in noticeably faster builds, and switching to LLD shaves a few mores seconds from the build.
If we want to build faster, we can make some compromises and start stripping the build by removing some components.
Let's start by disabling additional architecture support:
cmake -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_COMPILER=clang++ \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_ENABLE_PROJECTS=clang \ -DLLVM_USE_LINKER=lld \ -DLLVM_TARGETS_TO_BUILD="AArch64" \ -GNinja ../llvm time ninja [3195/3195] Linking CXX executable bin/c-index-test real 3m10.312s user 326m54.898s sys 5m24.770s
We can verify the resulting Clang binary only supports AArch64 targets:
bin/clang --print-targets Registered Targets: aarch64 - AArch64 (little endian) aarch64_32 - AArch64 (little endian ILP32) aarch64_be - AArch64 (big endian) arm64 - ARM64 (little endian) arm64_32 - ARM64 (little endian ILP32)
Let's go further and disable the static analyzer and the ARC Migration Tool:
cmake -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_COMPILER=clang++ \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_ENABLE_PROJECTS=clang \ -DLLVM_USE_LINKER=lld \ -DLLVM_TARGETS_TO_BUILD="AArch64" \ -DCLANG_ENABLE_STATIC_ANALYZER=OFF \ -DCLANG_ENABLE_ARCMT=OFF \ -GNinja ../llvm time ninja [3146/3146] Creating library symlink lib/libclang-cpp.so real 3m6.474s user 319m25.914s sys 5m20.924s
Let's disable building some LLVM tools and utils:
cmake -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_COMPILER=clang++ \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_ENABLE_PROJECTS=clang \ -DLLVM_USE_LINKER=lld \ -DLLVM_TARGETS_TO_BUILD="AArch64" \ -DCLANG_ENABLE_STATIC_ANALYZER=OFF \ -DCLANG_ENABLE_ARCMT=OFF \ -DLLVM_BUILD_TOOLS=OFF \ -DLLVM_BUILD_UTILS=OFF \ -GNinja ../llvm time ninja [2879/2879] Creating library symlink lib/libclang-cpp.so real 2m59.659s user 298m47.482s sys 4m57.430s
Compared to the previous build, the following binaries were not built: FileCheck, count, lli-child-target, llvm-jitlink-executor, llvm-PerfectShuffle, not, obj2yaml, yaml2obj, and yaml-bench.
We are reaching the end of our journey here. At this point, we are done stripping out things.
Let's disable optimizations and do a last run:
cmake -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_COMPILER=clang++ \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_ENABLE_PROJECTS=clang \ -DLLVM_USE_LINKER=lld \ -DLLVM_TARGETS_TO_BUILD="AArch64" \ -DCLANG_ENABLE_STATIC_ANALYZER=OFF \ -DCLANG_ENABLE_ARCMT=OFF \ -DLLVM_BUILD_TOOLS=OFF \ -DLLVM_BUILD_UTILS=OFF \ -DCMAKE_CXX_FLAGS_RELEASE="-O0" \ -GNinja ../llvm time ninja [2879/2879] Linking CXX executable bin/c-index-test real 2m37.003s user 231m53.133s sys 4m56.675s
So this is it, this machine can build a full LLVM/Clang release build in a bit less than four minutes, and a stripped down build with optimizations disabled in two minutes. Two minutes. This is absolutely mind-blowing… The future is now!
aiomixer is an application that I've been maintaining outside of NetBSD for a few years. It was available as a package, and was a "graphical" (curses, terminal-based) mixer for NetBSD's audio API, inspired by programs like alsamixer. For some time I've thought that it should be integrated into the NetBSD base system - it's small and simple, very useful, and many developers and users had it installed (some told me that they would install it on all of their machines that needed audio output). For my particular use case, as well as my NetBSD laptop, I have some small NetBSD machines around the house plugged into speakers that I play music from. Sometimes I like to SSH into them to adjust the playback volume, and it's often easier to do visually than with mixerctl(1).
However, there was one problem: when I first wrote aiomixer 2 years ago, I was intimidated by the curses API, so opted to use the Curses Development Kit instead. This turned out to be a mistake, as not only was CDK inflexible for an application like aiomixer, it introduced a hard dependency on ncurses.
Many people think ncurses is the canonical way to develop terminal-based applications for Unix, but it's actually an implementation of the X/Open Curses specification. There's a few other Curses implementations:
NetBSD curses is descended from the original BSD curses, but contains many useful extensions from ncurses as well. We use it all over the base system, and for most packages in pkgsrc. It's also been ported to other operating systems, including Linux. As far as I'm aware, NetBSD is one of the last operating systems left that doesn't primarily depend on ncurses.
There's one crucial incompatibility, however: ncurses exposes its internal data structures, NetBSD libcurses keeps them opaque. Since CDK development is very tied to ncurses development (they have the same maintainer), CDK peeks into those structures, and can't be used with NetBSD libcurses. There are also a few places where ncurses breaks with X/Open Curses, like this case I recently fixed in irssi.
I was able to rewrite aiomixer in a few days using only my free time and NetBSD libcurses. It's now been imported to the base system. It was a good lesson in why Curses isn't actually that intimidating - while there are many functions, they're mostly variations on the same thing. Using Curses directly resulted in a much lighter and more usable application, and provided a much better fit for the types of widgets I needed.
Many people also provided testing, and I learned a lot about how different terminal attributes should be used in the process. NetBSD is probably one of the few communities where you'll get easy and direct feedback on how to not only make your software work well in a variety of terminal emulators, but also old school hardware terminals. During development, I was also able to find a strange bug in the curses library's window resizing function.
The API support was also improved, and the new version of aiomixer should work better with a wider variety of sound hardware drivers.
Since I'm done plugging my own work, I thought I might talk a bit about some other recent changes to CURRENT.
-Werror. Many minor warnings and actual-bugs were uncovered and fixed with the new compiler.
-loption to the wsfontload(8) command, allowing easy viewing of the tty fonts currently loaded into the kernel.
All of a sudden (read: without changing any parameters) my netbsd virtualmachine started acting oddly. The symptoms concern ssh tunneling.
From my laptop I launch:
$ ssh -L 7000:localhost:7000 [email protected] -N -v
Then, in another shell:
$ irssi -c localhost -p 7000
The ssh debug says:
debug1: Connection to port 7000 forwarding to localhost port 7000 requested. debug1: channel 2: new [direct-tcpip] channel 2: open failed: connect failed: Connection refused debug1: channel 2: free: direct-tcpip: listening port 7000 for localhost port 7000, connect from 127.0.0.1 port 53954, nchannels 3
I tried also with localhost:80 to connect to the (remote) web server, with identical results.
The remote host runs NetBSD:
bash-4.2# uname -a NetBSD host 5.1_STABLE NetBSD 5.1_STABLE (XEN3PAE_DOMU) #6: Fri Nov 4 16:56:31 MET 2011 [email protected]:/m/obj/m/src/sys/arch/i386/compile/XEN3PAE_DOMU i386
I am a bit lost. I tried running
tcpdump on the remote host, and I spotted these 'bad chksum':
09:25:55.823849 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 67, bad cksum 0 (->3cb3)!) 127.0.0.1.54381 > 127.0.0.1.7000: P, cksum 0xfe37 (incorrect (-> 0xa801), 1622402406:1622402421(15) ack 1635127887 win 4096 <nop,nop,timestamp 5002727 5002603>
I tried restarting the ssh daemon to no avail. I haven't rebooted yet - perhaps somebody here can suggest other diagnostics. I think it might either be the virtual network card driver, or somebody rooted our ssh.
I'm attempting to make a script which tracks how many times you execute a specific process. I want to detect when the process starts and then log it.
The psuedo-code would be something like this:
while (true) if (process started) then log(process)
Is there an easy way to do this (preferably in shell but C is also fine) on either Linux or NetBSD?
While FreeBSD and OpenBSD both switched to using LLVM/Clang as their base system compiler, NetBSD picked a different path and remained with GCC and binutils regardless of the license change to GPLv3. However, it doesn't mean that the NetBSD project endorses this license, and the NetBSD Foundation's has issued a statement about its position on the subject.
Realistically, NetBSD is more or less tied to GCC, as it supports more architectures than the other BSDs, some of which will likely never be supported in LLVM.
As of NetBSD 9.1, the latest released version, all supported platforms have recent versions of GCC (7.5.0) and binutils (2.31.1) in the base system. Newer (and older!) versions of GCC can be installed via Pkgsrc, and the following packages are available, going all the way back to GCC 3.3.6:
+---------+------------+-------------------+ | Package | Version | Release date | +---------+------------+-------------------+ | gcc10 | GCC 10.2.0 | July 23, 2020 | | gcc9 | GCC 9.3.0 | March 12, 2020 | | gcc8 | GCC 8.4.0 | March 4, 2020 | | gcc7 | GCC 7.5.0 | November 14, 2019 | | gcc6 | GCC 6.5.0 | October 26, 2018 | | gcc5 | GCC 5.5.0 | October 10, 2017 | | gcc49 | GCC 4.9.4 | August 3, 2016 | | gcc48 | GCC 4.8.5 | June 23, 2015 | | gcc3 | GCC 3.3.6 | May 3, 2005 | +---------+------------+-------------------+
The focus on GCC doesn't mean that the GNU and LLVM toolchains cannot coexist within NetBSD, and work has in fact been done during the last decade to make it happen.
Despite currently not being built by default in official NetBSD releases, LLVM has been imported in the NetBSD source tree in 2013. Daily images are built from NetBSD-current for selected platforms (at least amd64, i386 and evbarm) with the MKLLVM and HAVE_LLVM build options enabled, and contain LLVM and Clang.
Moreover, NetBSD has invested a lot of work on LLVM during the past few years, including funding some developer contracts for Kamil Rytarowski ([email protected]) and Michał Górny ([email protected]), which allowed them to work on various parts of the LLVM toolchain to add and enhance support for sanitizers, and to improve LLDB support.
They both published several dozen articles on the NetBSD blog along the way, retracing their journey. Kamil's final report about upstreaming support to LLVM sanitizers summarizes the work accomplished. Thanks to this work, sanitizer support on NetBSD is mature and mostly on par with Linux. As a result, because LLVM is upstream for GCC sanitizers, they are also available in GCC on NetBSD. Similarly, Michał's final report on his LLDB work details the achievements on the debuggers front.
As always, work continues towards keeping the toolchains up to date, and upstreaming local changes whenever possible.
This is my second and final report for the Google Summer of Code project I am working on for NetBSD.
My code can be found at github.com/teknokatze/src in the gsoc2020 branch, at the time of writing some of it is still missing. The test facilities and logs can be found in github.com/teknokatze/gsoc2020. A diff can be found at github which will later be split into several patches before it is sent to QA for merging.
The initial and defined goal of this project was to make system(3) and popen(3) use posix_spawn(3) internally, which had been completed in June. For the second part I was given the task to replace fork+exec calls in our standard shell (sh) in one scenario. Similar to the previous goal we determined through implementation if the initial motivation, to get performance improvements, is correct otherwise we collect metrics for why posix_spawn() in this case should be avoided. This second part meant in practice that I had to add and change code in the kernel, add a new public libc function, and understand shell internals.
Prior work: In GSoC 2012 Charles Zhang added the posix_spawn syscall which according to its SF repository at the time (maybe even now, I have not looked very much into comparing all other systems and libcs + kernels) is an in-kernel implementation of posix_spawn which provides performance benefits compared to FreeBSD and other systems which had a userspace implementation (in 2012).
After 1 week of reading POSIX and writing code, 2 weeks of coding and another 1.5 weeks of bugfixes I have successfully implemented posix_spawn in usage in system(3) and popen(3) internally.
The biggest challenge for me was to understand POSIX, to read the standard. I am used to reading more formal books, but I can't remember working with POSIX Standard directly before.
system(3) was changed to use posix_spawnattr_ (where we used sigaction before) and posix_spawn (which replaced execve + vfork calls).
Since the popen and popenve implementation in NetBSD's libc use a couple of shared helper functions, I was able to change both functions while keeping the majority of the changes focused on (some of ) the helper functions (pdes_child).
pdes_child, an internal function in popen.c, now takes one more argument (const char *cmd) for the command to pass to posix_spawn which is called in pdes_child.
On a high level what happens in pdes_child() and popen is that we first lock the pidlist_mutex. Then we create a file file action list for all concurrent popen() / popenve() instances and the side of the pipe not necessary, and the move to stdin/stdout. We unlock the pidlist_mutex. Finally we return the list and destroy.
In the new version of this helper function which now handles the majority of what popen/popenve did, we have to initialize a file_actions object which by default contains no file actions for posix_spawn() to perform. Since we have to have error handling and a common return value for the functions calling pdes_child() and deconstruction, we make use of goto in some parts of this function.
The close() and dup2() actions now get replaced by corresponding file_actions syscalls, they are used to specify a series of actions to be performed by a posix_spawn operation.
After this series of actions, we call _readlockenv(), and call posix_spawn with the file_action object and the other arguments to be executed. If it succeeds, we return the pid of the child to popen, otherwise we return -1, in both cases we destroy the file_action object before we proceed.
In popen and popenve our code has been reduced to the pid == -1 branch, everything else happens in pdes_child() now.
After readlockenv we call pdes_child and pass it the command to execute in the posix_spawn'd child process; if pdes_child returns -1 we run the old error handling code. Likewise for popenve.
The outcome of the first part is, that thanks to how we implement posix_spawn in NetBSD we reduced the syscalls being made for popen and system. A full test with proper timing should indicate this, my reading was based on comparing old and new logs with ktrace and kdump.
The main goal of part 2 of this project was to change sh(1) to determine which simple cases of (v)fork + exec I could replace, and to replace them with posix_spawn where it makes sense.
fork needs to create a new address space by cloning the address space, or in the case of vfork update at least some reference counts. posix_spawn can avoid most of this as it creates the new address space from scratch.
The current posix_spawn as defined in POSIX has no good way to do tcsetpgrp, and we found that fish just avoids posix_spawn for foreground processes.
Since, roughly speaking, modern BSDs handle "#!" execution in the kernel (probably since before the 1990s, systems which didn't handle this started to disappear most likely in the mid to late 90s), our main concern so far was in the evalcmd function the default cmd switch case ('NORMALCMD').
After adjusting the function to use posix_spawn, I hit an issue in the execution of the curses application htop where htop would run but input would not be accepted properly (keysequences pressed are visible). In pre-posix_spawn sh, every subprocess that sh (v)forked runs forkchild() to set up the subprocess's environment. With posix_spawn, we need to arrange posix_spawn actions to do the same thing.
The intermediate resolution was to switch FORK_FG processes to fork+exec again. For foreground processes with job control we're in an interactive shell, so the performance benefit is small enough in this case to be negligible. It's really only for shell scripts that it matters.
Next I implemented a posix_spawn file_action, with the prototype
int posix_spawn_file_actions_addtcsetpgrp(posix_spawn_file_actions_t *fa, int fildes)
The kernel part of this was implemented inline in sys/kern/kern_exec.c, in the function handle_posix_spawn_file_actions() for the new case 'FAE_TCSETPGRP'.
The new version of the code is still in testing and debugging phase and at the time of writing not included in my repository (it will be published after Google Summer of Code when I'm done moving).
According to a conversation with [email protected], the posix_spawnp() implementation we have is just itterating over $PATH calling posix_spawn until it succeeds. For some changes we might want a kernel implementation of posix_spawnp(), as the path search is supposed to happen in the kernel so the file actions are only ever run once:
some of the file actions may be "execute once only", they can't be repeated (eg: handling "set -C; cat foo >file" - file can only be created once, that has to happen before the exec (as the fd needs to be made stdout), and then the exec part of posix_spawn is attempted - if that fails, when it can't find "cat" in $HOME/bin (or whatever is first in $PATH) and we move along to the next entry (maybe /bin doesn't really matter) then the repeated file action fails, as file now exists, and "set -C" demands that we cannot open an already existing file (noclobber mode). It would be nice for this if there were "clean up on failure" actions, but that is likely to be very difficult to get right, and each would need to be attached to a file action, so only those which had been performed would result in cleanup attempts.
Ideally we could replace all of (v)fork + exec with posix_spawn. According to my mentors there is pmap synchronisation as an impact of constructing the vm space from scratch with (v)fork. Less IPIs (inter-processor interrupts) matter for small processes too.
Future directions could involve a posix_spawn action for an arbitrary ioctl.
My thanks go to fellow NetBSD developers for answering questions, most recently [email protected] for sharing invaluable sh knowledge, Riastradh and Jörg as the mentors I've interacted with most of the time and for their often in-depth explanations as well as allowing me to ask questions I sometimes felt were too obvious. My friends, for sticking up with my "weird" working schedule. Lastly would like to thank the Google Summer of Code program for continuing through the ongoing pandemic and giving students the chance to work on projects full-time.
Originally published in August 2020 on https://n0.is/gsoc-2020-final-report---report-part-2.html.
I want to use the the new NetBSD's NPF firewall on a gateway that also has the legal obligation to log the traffic for 1 year. To offload the gateway, I though to put the logging stuff (and IDS, quota management, ..) on another machine (probably on Debian).
I though of 2 solutions to do so :
Unlike FreeBSD and OpenBSD, I'm not sure if NetBSD is able to setup this king of port, and if it is, I don't know how. http://man.netbsd.org/bridge.4 indicates
The bridge driver currently does not support snooping via bpf(4).
but in an older version it was
The bridge driver currently does not support snooping via bpf(4) or transparent filtering.
So maybe there's a way, but I don't know where to start, any help ?
But how ? It has to be reliable and adapted to network log file (ie continuously written).
I would like to run a service inside a chroot in a NetBSD 9.1 amd64 system.
The service runs if invoked from OS.
The service in question is
dendrite-monolith-server. I just copied the file for ease of use to
start sitting inside the chroot in
# ldd bin/start bin/start: -lpthread.1 => /usr/lib/libpthread.so.1 -lc.12 => /usr/lib/libc.so.12
They are hard linked:
# ls -l usr/lib total 8560 -r--r--r-- 2 root pe 2079984 Feb 22 23:40 lc.12 -r--r--r-- 2 root pe 2079984 Feb 22 23:40 libc.so.12 -r--r--r-- 2 root pe 93656 Feb 22 23:40 libpthread.so.1 -r--r--r-- 2 root pe 93656 Feb 22 23:40 lpthread.1
In the chroot
MAKEDEV all to create the devices.
ld.elf_so to the chroot
# ls -l /libexec/ total 324 -r-xr-xr-x 1 0 1000 164344 Feb 22 23:47 ld.elf_so
ksh93 is statically linked:
# chroot ./ /bin/ksh93 # # /bin/start /bin/ksh93: /bin/start: not found
What's wrong or missing?
Feb 21 13:16:04 XXX /netbsd: [ 3620751.3847045] kern error: [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_fifo_underrun.c:230)cpt_set_fifo_underrun_reporting] *ERROR* uncleared pch fifo underrun on pch transcoder A
Feb 21 13:16:04 XXX /netbsd: [ 3620751.3847045] kern error: [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_fifo_underrun.c:381)intel_pch_fifo_underrun_irq_handler] *ERROR* PCH transcoder A FIFO underrun
Feb 21 14:33:25 XXX /netbsd: [ 3625392.1028982] kern error: [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_fifo_underrun.c:230)cpt_set_fifo_underrun_reporting] *ERROR* uncleared pch fifo underrun on pch transcoder A
Feb 21 14:33:25 XXX /netbsd: [ 3625392.1028982] kern error: [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_fifo_underrun.c:381)intel_pch_fifo_underrun_irq_handler] *ERROR* PCH transcoder A FIFO underrun
Feb 24 09:03:22 XXX syslogd: restart
Feb 24 09:03:22 XXX /netbsd: [ 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
I'm looking to create a function for a script where another function will be called every few seconds, however the user should be able to issue other commands to the program while this is happening. Because of this, I doubt I'll be able to use
sleep as that holds up the entire script.
I've spent about a day searching for ways to accomplish this, but so far haven't found anything that would work for me.
I'm working through examples in APUE. On a NetBSD 9.0 system, under no major load, I time a call to
grep and get an unremarkable result:
apue$ cd /usr/include apue$ time -p grep __POSIX_SOURCE */*.h > /dev/null real 0.73 user 0.01 sys 0.63
However, if I repeat the experiment several times, the system time spikes drastically (up to 15x):
apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null real 0.57 user 0.02 sys 0.54 apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null real 10.06 user 0.01 sys 10.04 apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null real 3.57 user 0.01 sys 3.56 apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null real 4.58 user 0.00 sys 4.58 apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null real 5.56 user 0.02 sys 5.53 apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null real 6.57 user 0.00 sys 6.56 apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null real 2.56 user 0.01 sys 2.54
Is this expected behavior? What could be causing such wide variance?
Update Based on the answer given by @Tim, I took a look at my Buffercache, and saw that it was fully allocated at 100% when grep was struggling with my search. After restarting the VM, the buffer usage had dropped down to around 95%.
$ sysstat bufcache /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 Load Average | 603 metadata buffers using 5565 kBytes of memory ( 0%). 15512 pages for cached file data using 62048 kBytes of memory ( 3%). 3034 pages for executables using 12136 kBytes of memory ( 1%). 6460 pages for anon (non-file) data 25840 kBytes of memory ( 1%). 468172 free pages 1872688 kBytes of memory (93%). File System Bufs used % kB in use % Bufsize kB % Util % / 577 95 5378 97 5418 97 99 Total: 577 95 5378 97 5418 97 99
NetBSD-current now has pre-built octeon bootable images (which will appear in NetBSD 10.0) for the evbmips port, so I decided to finally give it a try. I've been happily running OpenBSD/octeon on my EdgeRouter Lite for a few years now, and have previously published some notes including more detail about the CPU.
Contrary to the OpenBSD/octeon port which is very stable and runs SMP kernels, things are a little less polished on the NetBSD side for this platform. The system runs an uniprocessor kernel and there are still some stability issues.
Here is the U-Boot configuration to boot the image:
Octeon ubnt_e100# set bootcmd 'fatload usb 0 $loadaddr netbsd;bootoctlinux $loadaddr coremask=0x3 root=wedge:octeon-root' Octeon ubnt_e100# saveenv Saving Environment to Flash... Un-Protected 1 sectors Erasing Flash... . done Erased 1 sectors Writing to Flash... 4....3....2....1....done Protected 1 sectors Octeon ubnt_e100#
On first boot, the system automatically expands the filesystem:
Resizing / (NAME=octeon-root) /dev/rdk1: grow cg |************************************* | 69%
Here is the login session, for posterity:
Thu Jan 28 23:40:37 UTC 2021 NetBSD/evbmips (octeon) (constty) login:
Here is the output of running file on executables:
ELF 32-bit MSB pie executable, MIPS, N32 MIPS-III version 1 (SYSV), dynamically linked, interpreter /libexec/ld.elf_so, for NetBSD 9.99.79, not stripped
For the record, OpenSSL speed benchmark results are available here.
System message buffer (dmesg output):
[ 1.000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, [ 1.000000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, [ 1.000000] 2018, 2019, 2020, 2021 The NetBSD Foundation, Inc. All rights reserved. [ 1.000000] Copyright (c) 1982, 1986, 1989, 1991, 1993 [ 1.000000] The Regents of the University of California. All rights reserved. [ 1.000000] NetBSD 9.99.79 (OCTEON) #0: Thu Jan 28 18:52:43 UTC 2021 [ 1.000000] [email protected]:/usr/src/sys/arch/evbmips/compile/OCTEON [ 1.000000] Cavium Octeon CN5020-500 [ 1.000000] total memory = 512 MB [ 1.000000] avail memory = 496 MB [ 1.000000] timecounter: Timecounters tick every 10.000 msec [ 1.000000] mainbus0 (root) [ 1.000000] cpunode0 at mainbus0: 2 cores, crypto+kasumi, 64bit-mul, unaligned-access ok [ 1.000000] cpu0 at cpunode0 core 0: 500.00MHz [ 1.000000] cpu0: Cavium CN5020-500 (0xd0601) Rev. 1 with software emulated floating point [ 1.000000] cpu0: 64 TLB entries, 512TB (49-bit) VAs, 512TB (49-bit) PAs, 256MB max page size [ 1.000000] cpu0: 32KB/128B 4-way set-associative L1 instruction cache [ 1.000000] cpu0: 16KB/128B 64-way set-associative write-through coherent L1 data cache [ 1.000000] cpu0: 128KB/128B 8-way set-associative write-back L2 unified cache [ 1.000000] cpu1 at cpunode0 core 1: disabled (uniprocessor kernel) [ 1.000000] wdog0 at cpunode0: default period is 4 seconds [ 1.000000] iobus0 at mainbus0 [ 1.000000] iobus0: initializing POW [ 1.000000] iobus0: initializing FPA [ 1.000000] com0 at iobus0 address 0x0001180000000800: ns16650, no ERS, 16-byte FIFO [ 1.000000] com0: console [ 1.000000] com at iobus0 address 0x0001180000000c00 not configured [ 1.000000] octrnm0 at iobus0 address 0x0001180040000000 [ 1.000000] entropy: ready [ 1.000000] octtwsi at iobus0 address 0x0001180000001000 not configured [ 1.000000] octmpi at iobus0 address 0x0001070000001000 not configured [ 1.000000] octsmi0 at iobus0 address 0x0001180000001800 [ 1.000000] octpip0 at iobus0 address 0x00011800a0000000 [ 1.000000] octgmx0 at octpip0 [ 1.000000] cnmac0 at octgmx0: address=0x1180008000000: RGMII [ 1.000000] cnmac0: Ethernet address 44:d9:e7:9e:f5:9e [ 1.000000] atphy0 at cnmac0 phy 7: Atheros AR8035 10/100/1000 PHY, rev. 2 [ 1.000000] atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX-FDX, 1000baseT-FDX, auto [ 1.000000] cnmac1 at octgmx0: address=0x1180008000000: RGMII [ 1.000000] cnmac1: Ethernet address 44:d9:e7:9e:f5:9f [ 1.000000] atphy1 at cnmac1 phy 6: Atheros AR8035 10/100/1000 PHY, rev. 2 [ 1.000000] atphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX-FDX, 1000baseT-FDX, auto [ 1.000000] cnmac2 at octgmx0: address=0x1180008000000: RGMII [ 1.000000] cnmac2: Ethernet address 44:d9:e7:9e:f5:a0 [ 1.000000] atphy2 at cnmac2 phy 5: Atheros AR8035 10/100/1000 PHY, rev. 2 [ 1.000000] atphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX-FDX, 1000baseT-FDX, auto [ 1.000000] dwctwo0 at iobus0 address 0x0001180068000000 [ 1.000000] dwctwo0: Core Release: 2.65a (snpsid=4f54265a) [ 1.000000] usb0 at dwctwo0: USB revision 2.0 [ 1.000000] bootbus0 at mainbus0 [ 1.000000] timecounter: Timecounter "mips3_cp0_counter" frequency 500000000 Hz quality 100 [ 1.000003] timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0 [ 1.059978] uhub0 at usb0: NetBSD (0x0000) DWC2 root hub (0x0000), class 9/0, rev 2.00/1.00, addr 1 [ 1.059978] uhub0: 1 port with 1 removable, self powered [ 1.069975] aes: BearSSL aes_ct [ 1.069975] aes_ccm: self-test passed [ 1.069975] chacha: Portable C ChaCha [ 1.079979] blake2s: self-test passed [ 3.609971] umass0 at uhub0 port 1 configuration 1 interface 0 [ 3.620226] umass0: vendor 13fe (0x13fe) USB DISK 2.0 (0x4200), rev 2.00/1.00, addr 2 [ 3.620226] umass0: using SCSI over Bulk-Only [ 3.620226] scsibus0 at umass0: 2 targets, 1 lun per target [ 3.632383] uhub0: autoconfiguration error: illegal enable change, port 1 [ 3.639974] sd0 at scsibus0 target 0 lun 0: <, USB DISK 2.0, PMAP> disk removable [ 3.639974] sd0: 3824 MB, 959 cyl, 255 head, 32 sec, 512 bytes/sect x 7831552 sectors [ 3.659974] sd0: GPT GUID: 6e7b1b6a-2e9f-4915-946a-567dad0caaa4 [ 3.669969] dk0 at sd0: "octeon-boot", 163840 blocks at 32768, type: ntfs [ 3.669969] dk1 at sd0: "octeon-root", 7626752 blocks at 196608, type: ffs [ 3.683879] WARNING: 1 error while detecting hardware; check system log. [ 3.691430] boot device: sd0 [ 3.691430] root on dk1 [ 3.709975] root file system type: ffs [ 3.719976] kern.module.path=/stand/evbmips/9.99.79/modules [ 3.719976] WARNING: no TOD clock present [ 3.729990] WARNING: using filesystem time [ 3.734057] WARNING: CHECK AND RESET THE DATE!
I'm reviewing man(2) pages on NetBSD 9, and have seen that all of the documents (write(2), open(2), pipe(2)) mention the Standard C Library at the top.
My understanding was that system calls were independent of library functions (such as those in libc). I don't see a similar mention in the Linux System call Manual. Does this mean that invoking these methods is calling some wrapper function included in libc, instead of directly calling a kernel function? Is this generally true, or just a feature of NetBSD?