As I alluded to in my previous post, I am now back in Santa Barbara (or rather Goleta). This means I have some additional resources from my lab and professors, but also a lot of additional responsibilities from my classes, dealing with my apartment, etc. This means that I will have a smaller amount of time to work on GSoC, but I will make sure to work on the project as much as I can and continue to keep you all updated. ...
Now that midterm evaluations have come out, it is time to reflect on my experiences and the progress that I’ve made. Overall, I am proud of the progress that I have made, but I know that there is a lot more work left to do. For this week, I have been able to get a test suite running for libcups. However, there is a lot more testing to be done since libcups is a lot more complex and less self-contained than other libraries like zlib or pdfio. ...
Although libcups has been the most challenging project to port and has taken a lot longer than I initially thought, I feel like I am finally a lot closer to getting the library operational. Even though I am not quite done with getting everything prepared for compilation unlike what I said I would do earlier, I have gone through and added code for all of the parts where Mbed TLS is needed. ...
This week was again spent mostly on refactoring libcups to support Mbed TLS, and besides some slight issues, I should be able to finish implementing it soon and then make some additional header files (or forks) to implement the rest of the functionality needed from libc and mDNS Responder so that I can get a test application to compile. Another thing to note is that I feel like I have learned a lot about TLS and cryptography just from working with Mbed TLS. I used to not pay too much attention to the field of cryptography in my work and research, but now I realize more and more that cryptography is definitely relevant to this field of embedded systems and my research in computer architecture. ...
I want to start by saying that porting libcups is significantly more complex than porting zlib or PDFio, and I was definitely wrong in saying that I could port it quickly. Although setting up the build scripts and environment is relatively simple, like with zlib and PDFio, I also have to make significant additions and changes to the source code in multiple libraries. Mbed TLS The first challenge comes in the form of Zephyr’s TLS library, Mbed TLS. Since the design methodologies of OpenSSL, GNU TLS, and Mbed TLS differ, I first had to modify Mbed TLS to expose previously static functions (mainly for cupsAreCredentialsValidForName). Since the contributors didn’t want users to have access to functions like x509_crt_verify_name that are practically needed to implement some of the libcups functions (maybe due to security concerns), this sort of modification is unofficial and can be quite murky. ...
This week marks the point where zlib and PDFio are wrapped up for now. This update is fairly short since there has not been a lot of new stuff going on this week, since most of the work has been with testing, and I celebrated Independence Day last Friday. I can now proudly say that zlib passes the provided example and infcover tests at least on the ESP32. Luckily, I did not have to go digging around in GDB very much since the problems seemed to just be in the compile options and library choice. Now that I have enforced the _POSIX_C_SOURCE parameter and switched to newlib, things have been going fine so far. ...
This week was mainly a continuation of my work during week 1. I continued work on zlib by conducting more rigorous testing, covering the relevant tests within the default CMakeLists. Overall, I think that zlib is mostly functional at the current state and should provide general compression and decompression functionality. Notes on zlib There are still some things to keep in mind on the current state of zlib; first of which is building the test application, especially since I have to use a file system like littlefs. In gzlib.c and related source files for “gz” prefixed functions, file i/o functionality is required, and I figured that littlefs would be a good fit since it is designed for use in embedded applications. However, it seems that some platforms, such as my native_sim and qemu_riscv64/32, struggle with building the application with littlefs or with interacting with the filesystem. I have found that real hardware (i.e., the ESP32) works the best for building and running the application. However, the application still fails two coverage tests (cover_wrap and cover_back) in the provided CMake tests. Therefore, I will have to look into OpenOCD so I can get a debugger running. On the other hand, I’m able to pass all the tests not involving file i/o on native_sim, likely since there are differences between the C libraries on native_sim and other platforms (e.g., I think I am able to include header files on my system but not in the Zephyr libc). Another factor to keep in mind is that I also decreased the parameters for max LZ77 window bits and default memory level to avoid a heap overflow on my ESP32. Lastly, I have a few remarks on the Kconfig option CONFIG_POSIX_API. Although this page states that the option should not be used for new Zephyr applications, the truth is that unistd.h still uses a #ifdef CONFIG_POSIX_API block around some important functions like read(), write(), etc. Therefore, I have set the option as a dependency for zlib. ...
Now that this inaugural week is done, I have some time to reflect on what I’ve learned and what did/did not go well. I’ve learned that I definitely work best at the beginning of my day, as I can basically devote my time entirely to the project for a few hours before dealing with other things and working more intermittently throughout pretty much the rest of the day. However, there are some things that can distract me from keeping up the momentum for those first few hours. Therefore, I think that starting work earlier and adapting my environment to be free of those distractions is something I should look towards. ...
About the Project Printers are a technology that we often think should “just work,” but in reality, there are often many hoops to jump through when dealing with a printer’s drivers. It is a common experience when dealing with printers to struggle to get a document printed when trying every which way on an OS like modern Windows, but then all the problems suddenly disappear when using an Apple device. This is in large part thanks to Apple’s AirPrint, which is the oldest and most widely supported driverless printing protocol. The driverless nature is important as it prevents the issue of having printer drivers that may not be updated to support the user’s current operating system. However, AirPrint is not an open standard, and only Apple operating systems are designed with it in mind. This leads us to IPP Everywhere, a driverless printing protocol that is an open standard, and its pivotal role in the modern open-source printing stack developed by OpenPrinting. This would theoretically allow any operating system that supports the printing stack to print, as long as the printer supports IPP Everywhere. ...