PTXdist: Did you know? Today: Beautify your developer's life
Simplify and beautify your developer's life. An example.
When PTXdist builds your project, it creates a subdirectory with the full root-filesystem content which can be exported via NFS.
This subdirectory can be exported by the regular kernel based NFS daemon or via the userland based NFS daemon coming with PTXdist.
We recommend the PTXdist based userland NFS daemon, because it uses the PTXdist generated list of user and permission information for each file in the root-filesystem. This feature isn't available for the kernel based NFS daemon.
If it is a development requirement to work with valid user and permission information for each file, there is no alternative to the PTXdist based userland NFS daemon. Else we will stumble across failures based on wrong user and permission information finally when we are using the root-filesystem images PTXdist creates on the target's local storage.
Whatever variant of NFS daemon we use, using a NFS based root-filesystem on our target system simplifies developer's life by ways.
Whenever we miss a software component, we now can activate it in the PTXdist menu, just let PTXdist build it and we can use it immediately on the target. There is no need anymore to copy files to the target, nor to replace full root-filesystem images. Most of the time even a reboot of the target system can be avoided.
Exceptions like the Linux kernel proves the rule. But even in the case of Linux kernel driver development, it might be possible to work on a driver module. It can be unloaded at run-time and the reworked version can be re-loaded. The reworked version just need to be re-created by PTXdist and will be exported to the target system like any other file via the NFS daemon.
You might know how painful it is to edit some configuration files with "vi" locally on the target system. Here is the good news: Thanks to the NFS daemon you can change these files with your preferred editor locally on your host instead. The change is immediately "visible" on the target system as well.
An NFS daemon makes your developer's life more beautiful and you won't drink your coffee in despair anymore, you can enjoy it instead.
So you went and got yourself one of our fancy rocket-penguin branded CandleLight dongles or, being the die hard hacker you are, went and soldered one up in your toaster oven labeled "not food safe". What's next then? How do you use this thing? Let's answer these question by grabbing a Raspberry Pi and exploring some of the possibilities.
End of January systemd 250 was added to Debian bullseye backports. With a lots of new features and fixes now comes the possibility to set the timing of CAN bus interfaces with systemd-networkd. In this blogpost I will take a look at why this helps us maintain our embedded Linux labs.
PTXdist comes with a tool to make license management more simple, namely the command: ptxdist make license-report. This tool generates a license report in pdf format, which filters the used BSP for all known licenses. To generate and comply with the license report should be seen as minimum standard, exceeding efforts should, if possible, be done.
Whenever it is a requirement to be able to switch off an embedded device without any previous preparation, the next question is about the consistence of the used filesystem. If this filesystem is used to be written with new content and this new/changed data hasn't done it's way to the persistent media when the power is cut, this new/changed data is lost.
A BSP (Board Support Package) in Embedded Software is the layer of software that lets you run your application on a specific hardware. For Pengutronix a BSP usually contains a bootloader, Linux Kernel and a userspace. DistroKit is our Demo-BSP that supports a variety of common evaluation boards. DistroKit gives you a head start if you want to develop an application on top of such an evaluation board with most of the hard problems already solved.