Linux kernel programming is probably like this. There are no automatic tests, so the more pedantic you are, the less bugs you'll introduce.
EDIT: The wizards are out there, for example https://pvk.ca/Blog/2019/01/09/preemption-is-gc-for-memory-r..., but they're not evenly distributed, and perhaps the insane cutting-edge code they write (and the less insane code I write) isn't necessarily dependable, since by definition they lie on the edge of human understanding.
#til and also #wtf
In all seriousness, can you recommend any resources on why is that the case and how kernel is tested?
However, the kernel is fairly hard to test because it's the kernel:
- A lot of code paths are fully dependent on hardware that can't be mocked. How would you test the bootloader, for example? Or code that depends on a certain processor architecture? The only way is to actually run the code on that hardware.
- Similarly, it's hard to test the drivers. A lot of them are made by vendors, and the only way to test is against the devices themselves. Even if you could emulate the device and connect that to the driver, there's a lot of things that you won't cover (the communication path, the device misbehaving...)
- It's hard to test things that the runtime depends on. For example, if you try and test the memory subsystem, how do you manage the memory to actually run the tests?
Kernel testing is hard for the same reasons kernel development alone is hard, you're building the thing that all other tools require to run.
Yeah, sure it is hard or even harder. But think about browsers. We run applications and we want to make sure they look and behave the same, but there are so many OS, browsers, versions, devices, ...
So do we have to buy a laptop for each? Maybe in the past, but today we "just" emulate it. The same can be done with kernel testing. Assume that the whole kernel runs emulated (which is the hard part) and then test the outout of that (in the emulator).
> Maybe in the past, but today we "just" emulate it.
"Just emulating" is almost impossible. For testing to be actually reliable, you'd need to recreate all the hardware behavior in code. OS virtualization relies on re-exposing the hardware and kernel primitives to VMs, no VM is reimplementing the Intel architecture for memory management, for example.
> then test the outout of that (in the emulator).
Another hard topic. What's the output of a kernel? In an emulator the only thing you have is access to the memory areas (RAM, screen, devices). You can't really rebuild the state of the kernel, or access internal structures that tell you information about how it is. If you're lucky and advanced enough in the boot sequence that the kernel has configured the serial port for comms and debugging, you might be able to get some information, but not that much, and it'd still be impossible to test certain parts of the boot sequence.
That's fair. But in the same way that the VM relies on that the host OS handles operations correctly, the kernel can assume the same, as long as there is a clean separation (so that one kernel doesn't influence the other).
Of course, if you have a bug in the (old/other) kernel that influences the tests themselves then that wouldn't work, but I would say that this probably makes up a very small minority of cases.
Just like if Intel runs tests for their CPUs on other CPUs and those other CPUs are buggy...
> Another hard topic. What's the output of a kernel
The kernel has an interface and if I ask it to write something and then read it back, I have an expectation about what happens. I don't need to care about the state of the kernel (neither should I) as long as the result is good. Only for certain performance-relevant things I can see that this might be a problem.
> and it'd still be impossible to test certain parts of the boot sequence
I'm neither a kernel nor a browser developer ;) but I would be interested in an example. You are probably right, but I fail to see what that would be.
You could absolutely run tests on emulated hardware, but you probably learn more about the emulator than about the kernel.
But since it covers your for all future changes, it might still be worth it, because otherwise you either have to manually retest with actual hardware or accept a higher risk of bugs.
> - A lot of code paths are fully dependent on hardware that can't be mocked. How would you test the bootloader, for example? Or code that depends on a certain processor architecture? The only way is to actually run the code on that hardware.
My incorrect assumption was that one could run those tests in some sort of a virtualised environment where the host VM provides the tested component with the correct virtual hardware. The "hardware" itself contains mocks the test can access to run assertions. In other words, testing would involve checking the side effects. Come to think of it, that doesn't sound very practical. In fact, it sounds almost impossible to scale.
Like GP said, real hardware is difficult to mock good enough to be useful for testing. If you try it in practice, your emulator will only be one bullet point in the list of platforms to support...
I had to attempt to write an interface to the floppy and serial controller for IBM PC compatibles to learn this.
[1] https://www.usenix.org/conference/raid2019/presentation/gust...
[2] https://doi.org/10.48550/arXiv.2107.12867
[3] https://www.usenix.org/conference/usenixsecurity20/presentat...
I realize that's not perfect -- not even close -- and I'm sure smarter people than me have considered that idea and rejected it. But, out of curiosity, I wonder if you know the reason why it wouldn't help at least add some marginal value?
I don't think you really can. There will be things that can be different between runs (e.g., a DMA transfer) and not necessarily mean bugs. I don't think there are many fully stateless drivers where that kind of effort would both cover a significant part of hardware behavior and yield good enough code coverage.
I wonder how Microsoft does this with Windows? A friend of mine worked on Intel GPU drivers and they had entire farms of PCs where the tested driver would be installed on top of fresh Windows installation. For kernels, you’d probably need something like that, but times a thousand…
I don’t know squat about kernel programming, though. :-)
The idea to use “fewer” for countable things was someone’s personal preference. https://www.merriam-webster.com/words-at-play/fewer-vs-less
“This rule is simple enough and looks easy enough to follow, but it's not accurate for all usage. The fact is that less is also sometimes used to refer to number among things that are counted.
“This isn't an example of how modern English is going to the dogs. Less has been used this way for well over a thousand years—nearly as long as there's been a written English language.”
See also the list of common counter examples.
I think the relevant part of the "Exceptions to the Rule" section on that page is:
> The use of less to modify ordinary plural count nouns (as in "made less mistakes") is pretty rare in writing and is usually better avoided, though it does occur frequently in speech.
The exceptions (refering to distances/sums of money/units of time and weight/ statistical enumerations, phrases like "or less", and uses of "less" immediately following a number) aren't relevant here.
But both are "fine" in that they will be correctly understood.
> both are “fine” in that they will be correctly understood.
Agree! So much! I would go further, because I think this is the most important point: there is not a way to misunderstand the use of “less” in this context, which means that correcting people is purely pedantic, and not a functional issue or helping avoid potential misunderstanding.
Not only that, but sometimes people use “less” rather than “fewer” intentionally for countable things than can have a qualitative weight to them, as @danielheath pointed out. If the parent was trying to say that the bugs themselves could be both fewer in number, and also less damaging in scope, then less and fewer have two different meanings, and less is the more correct word to use.
> use of less […] is pretty rare in writing and is usually better avoided
Yes, I chose to emphasize that the rule is not absolute. Lots of people claim the rule is absolute, and a correction implies that point of view. My point is that even if using ‘less’ is better avoided, unsolicited corrections in public are also better avoided, because the rule is not absolute and in this case cannot be mistaken or misunderstood.
Worth noting that HN comments are not formal writing, and social media by and large is closer to informal speech, so the snippet you quoted can be viewed as validating use of less in this specific case.
Fewer emphasizes number; less emphasizes quantity. So, I would ask myself if I prefer saying the number of bugs or the quantity of bugs, and then choose accordingly. I prefer number, here. On account of that, I prefer fewer.
As to myriad, though it can be used as a noun (and apparently its use as a noun predates its use as an adjective), written language for the past 150-plus years prefers the adjective. (When Garner is talking about written language, he's talking about quality writing.)
I'm not saying you're wrong. But, style is as much about a sense of style as anything. Keeping language from going to the dogs requires a bit of dressing up.
It’s fine to hone your style and exercise your own preference, I have absolutely nothing against that. Correcting people is something completely different.
Insert ironic joke here to make an open sandwich.
Until you have worked with (internationonal) accounting, you don't realize how complex it can be.