Q: Please briefly introduce yourself, Samsung R&D Institute Poland, and the type of work conducted there. What projects are you currently working on?

Samsung R&D Institute Poland (SRPOL), based in Warsaw, was established in 2000 and is one of the largest R&D centers in the region. SRPOL is a vibrant research lab involved in a diverse range of projects within Samsung, including AI, Computer Vision, Mobile, Networks, IoT, Visual Display, and more.

My name is Marek Szyprowski. I graduated from the Faculty of Electronics and Information Technology at Warsaw University of Technology. After graduating in 2008, I joined Samsung R&D Institute Poland, where I became part of the Linux group and worked on low-level software development for embedded hardware. This included modifying the Linux kernel and other open-source projects to meet our company’s specific needs. Our group of low-level Linux kernel engineers quickly gained recognition in the open-source community through our contributions to the Linux kernel project, particularly in developing multimedia drivers for early Samsung Exynos SoCs.

We continued our low-level and operating system-related engineering, completing various activities related to the Tizen Operating System. This included mainly porting, adjusting vendor-provided software, and preparing board support packages, which consist of bootloader, kernel and core operating system components, for various Tizen open-source project reference hardware. We also contributed the changes required by Tizen OS to open-source projects, and actively joined the development efforts of some of them to have a real impact on their roadmap.

As a result of my open-source activities and earlier Linux kernel contributions, I was recently nominated as the sole maintainer of the Linux kernel DMA-mapping subsystem. This role involves collecting patches from developers around the world, reviewing them, and preparing them for merging with the main Linux kernel branch maintained by Linus Torvalds.

Q: Please tell us about the importance of your research field or technology. (Why is it needed, and how might it change our lives in the future?)

Open-source software is all around us—this is a fact. No one, not even a big company, can currently develop any significant software solution without using it.

This includes mobile or consumer electronic devices, as well as cloud-based services and many other appliances. Nowadays most software solutions rely on open-source components. According to the Open Source Group at Samsung Research, about 70% of the software used in Samsung products is open-source, and this number grows each year. This shows the importance of open-source as a technology.

There are different ways to be involved in open-source development. This depends heavily on the project type and particular use case, plans, and roadmap for a given software solution. One might think that the easiest approach is to integrate the code and keep needed changes locally. However, this does not work well in the long term. It’s much easier for both our company and our engineers to maintain open-source software components when we proactively participate in the development of those projects and help guide them to better serve our specific use cases.

Q: How do you stay up-to-date with the latest trends and developments in your field?

That’s a good question. The advantage of open-source technology is that it is open, which means that source code and most discussions about features, plans, or roadmaps are public—so it is possible to follow them and stay up-to-date. This can also be a disadvantage because one needs to spend time following those discussions. Major changes in large open-source projects, like the Linux kernel, are often summarized in various blogs or online journals. I try to use my time wisely to read such summaries and inspect code changes in areas of my interest, as both activities sometimes inspire me to read related public discussions.

Q: Could you tell us about your main achievements and the most rewarding moments in your research, or share a memorable episode at Samsung?

The most memorable episode was my first “large contribution” to the Linux kernel project. We were rewriting multimedia hardware drivers for early Samsung Exynos SoCs in a way that they would be accepted into the mainline Linux kernel. This would ease maintenance of the Linux kernel for Tizen’s reference hardware and prepare a good foundation for drivers for the next planned hardware.

At that time, the Linux kernel had no drivers for hardware with similar multimedia features. That required us to prepare the needed companion infrastructure in the Linux kernel—like extensions for the kernel memory management subsystem (called Contiguous Memory Allocator) and its integration with the DMA-mapping subsystem for the ARM architecture.

We discussed our proposed solution at open-source conferences like Embedded Linux Conference and Linux Plumbers. Our solution also attracted interest from other companies in the embedded hardware industry, and after some time, a consensus was reached among potential users.

We had the code ready, but none of the existing kernel maintainers was willing to merge it. Finally, I prepared a so-called ‘pull request’ containing those changes directly to Linus Torvalds (the main Linux kernel maintainer), and it was accepted! That is how I became the DMA-mapping subsystem maintainer for the first time in 2012.

Most parts of the code merged then are still used in embedded devices today. Later, I shared the maintainer role and stepped back due to other duties, but I have recently been asked to resume my role as sole maintainer of the DMA-mapping subsystem—and I agreed.

Another moment I remember well was related to Linux kernel testing. We were continuing driver development for Samsung Exynos SoCs with the aim of submitting them to the main Linux kernel repository. From time to time, we tested them along with other changes scheduled for the next Linux kernel release, and I noticed that the combination often caused regressions on our hardware platforms. I decided to build a so-called ‘test farm’—a set of development boards permanently connected to a machine and remotely bootable from a given Linux kernel image.

With some smart scripting, I managed to run semi-automated boot tests from the ‘linux-next’ branch, which contains all changes intended for the next release. I was surprised by how many regressions this simple setup could detect. I reported them as early as possible, significantly improving Linux kernel quality and allowing others to focus on their own modules or drivers. Since 2018, when I started daily kernel testing, more than 600 commits in Linux kernel v6.15 include my ‘Reported-by’ or ‘Tested-by’ tags.

Q: What is your vision for the future, and what goals would you like to achieve at Samsung Research?

I would like to continue working with various open-source projects, improve them for our company’s needs and providing better software for everyone. I also want to properly fulfill my role as the Linux kernel maintainer and keep the DMA-mapping subsystem up to date, especially making it robust and ready for upcoming hardware—across embedded systems, desktop applications, cloud, and high-performance computing.

Q: What advice would you give to aspiring researchers interested in pursuing a career in your field of expertise?

Open-source is a very diverse field, and it is good to get familiar with it first. If you want to start, I recommend checking the open-source components used in your project. Once you identify them, see whether they are just “used” or also modified. If the latter, there might be an opportunity to contribute—by submitting changes to the main project repository. This reduces future maintenance costs, as you won’t have to re-apply local changes every time the project updates.

Once you have a change you want to contribute, study how the project is developed—how developers communicate and how code is managed. Then, identify and describe your changes—why they are needed, what features they add, and what technical problems they solve. It is also important to handle the formal side: getting the necessary approvals to submit your code.

Remember, most open-source work is not rocket science, and if your feature is useful, someone else will probably implement it later if you don’t. What matters is not being afraid to modify the core code when needed—and being patient. Initial submissions are often not accepted. Maintainers usually provide feedback, so align with them or explain your approach, and try again. After a few iterations, your code will likely be accepted. That’s your first open-source contribution—and a great start.