KStars is probably the most feature-rich free astronomy software around and the 3.5.9 release adds some exciting new features. HiPS (Hierarchical Progressive Surveys) is a technology that provides progressive high resolution images of the sky at different zoom levels. KStars fully supports online HiPS where data is downloaded from online servers and cached to be displayed on the Sky Map.
This second year since the RFC we are looking forward to several milestones which hopefully we will achieve:
Linux Plumbers Conference 2022 is pleased to host the Android Microconference
Continuing in the same direction as last year, this year’s Android microconference will be an opportunity to foster collaboration between the Android and Linux kernel communities. Discussions will be centered on the goal of ensuring that both the Android and Linux development moves in a lockstep fashion going forward.
Projected topics:
Please come and join us in the discussion of making Android a better partner with Linux.
We hope to see you there!
So we've had a couple of fairly small rc releases, and here we finally start to see an uptick in commits in rc4. Not what I really want to see in the middle of the release cycle, but not entirely surprising considering how quiet it's been so far.
Update: Due to an io_uring problem reported by Greg Thelen in 5.10.125, which was quickly fixed by Jens Axboe, 5.10.126 was released less than 24 hours later.
Linux Plumbers Conference 2022 is pleased to host the Open Printing Microconference
OpenPrinting has been improving the way we print in Linux. Over the years we have changed many conventional ways of printing and scanning. Over the last few years we have been emphasizing on the fact that driverless print and scan has made life easier however this does not make us stop improving. Every day we are trying to design new ways of printing to make your printing and scanning experience better than that of today.
Proposed Topics :
Please come and join us in the discussion to bring Linux printing, scanning and fax a better experience.
We hope to see you there!
As part of the continuing work to replace 1-element arrays in the Linux kernel, it’s very handy to show that a source change has had no executable code difference. For example, if you started with this:
struct foo { unsigned long flags; u32 length; u32 data[1]; }; void foo_init(int count) { struct foo *instance; size_t bytes = sizeof(*instance) + sizeof(u32) * (count - 1); ... instance = kmalloc(bytes, GFP_KERNEL); ... };And you changed only the struct definition:
- u32 data[1]; + u32 data[];The bytes calculation is going to be incorrect, since it is still subtracting 1 element’s worth of space from the desired count. (And let’s ignore for the moment the open-coded calculation that may end up with an arithmetic over/underflow here; that can be solved separately by using the struct_size() helper or the size_mul(), size_add(), etc family of helpers.)
The missed adjustment to the size calculation is relatively easy to find in this example, but sometimes it’s much less obvious how structure sizes might be woven into the code. I’ve been checking for issues by using the fantastic diffoscope tool. It can produce a LOT of noise if you try to compare builds without keeping in mind the issues solved by reproducible builds, with some additional notes. I prepare my build with the “known to disrupt code layout” options disabled, but with debug info enabled:
$ KBF="KBUILD_BUILD_TIMESTAMP=1970-01-01 KBUILD_BUILD_USER=user KBUILD_BUILD_HOST=host KBUILD_BUILD_VERSION=1" $ OUT=gcc $ make $KBF O=$OUT allmodconfig $ ./scripts/config --file $OUT/.config \ -d GCOV_KERNEL -d KCOV -d GCC_PLUGINS -d IKHEADERS -d KASAN -d UBSAN \ -d DEBUG_INFO_NONE -e DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT $ make $KBF O=$OUT olddefconfigThen I build a stock target, saving the output in “before”. In this case, I’m examining drivers/scsi/megaraid/:
$ make -jN $KBF O=$OUT drivers/scsi/megaraid/ $ mkdir -p $OUT/before $ cp $OUT/drivers/scsi/megaraid/*.o $OUT/before/Then I patch and build a modified target, saving the output in “after”:
$ vi the/source/code.c $ make -jN $KBF O=$OUT drivers/scsi/megaraid/ $ mkdir -p $OUT/after $ cp $OUT/drivers/scsi/megaraid/*.o $OUT/after/And then run diffoscope:
$ diffoscope $OUT/before/ $OUT/after/If diffoscope output reports nothing, then we’re done. 🥳
Usually, though, when source lines move around other stuff will shift too (e.g. WARN macros rely on line numbers, so the bug table may change contents a bit, etc), and diffoscope output will look noisy. To examine just the executable code, the command that diffoscope used is reported in the output, and we can run it directly, but with possibly shifted line numbers not reported. i.e. running objdump without --line-numbers:
$ ARGS="--disassemble --demangle --reloc --no-show-raw-insn --section=.text" $ for i in $(cd $OUT/before && echo *.o); do echo $i diff -u <(objdump $ARGS $OUT/before/$i | sed "0,/^Disassembly/d") \ <(objdump $ARGS $OUT/after/$i | sed "0,/^Disassembly/d") doneIf I see an unexpected difference, for example:
- c120: movq $0x0,0x800(%rbx) + c120: movq $0x0,0x7f8(%rbx)Then I'll search for the pattern with line numbers added to the objdump output:
$ vi <(objdump --line-numbers $ARGS $OUT/after/megaraid_sas_fp.o)I'd search for "0x0,0x7f8", find the source file and line number above it, open that source file at that position, and look to see where something was being miscalculated:
$ vi drivers/scsi/megaraid/megaraid_sas_fp.c +329Once tracked down, I'd start over at the "patch and build a modified target" step above, repeating until there were no differences. For example, in the starting example, I'd also need to make this change:
- size_t bytes = sizeof(*instance) + sizeof(u32) * (count - 1); + size_t bytes = sizeof(*instance) + sizeof(u32) * count;Though, as hinted earlier, better yet would be:
- size_t bytes = sizeof(*instance) + sizeof(u32) * (count - 1); + size_t bytes = struct_size(instance, data, count);But sometimes adding the helper usage will add binary output differences since they're performing overflow checking that might saturate at SIZE_MAX. To help with patch clarity, those changes can be done separately from fixing the array declaration.
© 2022, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
GitHub’s Copilot is trained on software governed by these terms, and it fails to uphold them, and enables customers to accidentally fail to uphold these terms themselves. Some argue about the risks of a “copyleft surprise”, wherein someone incorporates a GPL licensed work into their product and is surprised to find that they are obligated to release their product under the terms of the GPL as well. Copilot institutionalizes this risk and any user who wishes to use it to develop non-free software would be well-advised not to do so, else they may find themselves legally liable to uphold these terms, perhaps ultimately being required to release their works under the terms of a license which is undesirable for their goals.
Chances are that many people will disagree with DeVault's reasoning, but this is an issue that merits some discussion still.
Although email based git workflows are great for real patch discussions, they do not always make tracking the state of patches easy. Just like our other services, such as bugzilla, mailinglists and git repos, we like to provide zero maintenance infrastructure for tracking and automation of patches and testing. So we are trying to consolidate around a shared buildbot for (test) automation and patchwork for tracking the state of contributions.