4 ms·

> Do you really need tests for the read(2) syscall when Linux is running on a billion devices, and that syscall is called some 10^12 times per second globally?

> Do you really need tests for the read(2) syscall when Linux is running on a billion devices, and that syscall is called some 10^12 times per second globally? Yes, you do, because otherwise you will find that some change or new hardware will break it.

Veuxdo 4y ago
If the read(2) implementation itself never changes, then unit tests of it shouldn't ever break, I think...
sph 4y ago
If some hardware breaks it, the hardware must be seriously broken. If a change breaks it, some one will probably have called read(2) a few times before that kernel is shipped to you. A change is filtered through multiple developer and the kernel has some kind of smoke and consistency tests it is subject to. Also there are people and companies that compile their kernel from the master branch and run software on it. No one's gonna ship Linux with a broken read syscall. And if there were tests, one could still ship a broken read syscall anyway. Tests do not guarantee the absence of bugs.
- Cyph0n 4y ago
  > Also there are people and companies that compile their kernel from the master branch and run software on it. Genuinely curious: why would a company ever do this?
  - sph 4y ago
    I was thinking of Red Hat (for example), that pays kernel developers and regularly tests and backports features for its paying customers. That means having a finger of the pulse of the kernel tree, and trying changes to decide whether it might be worth to port them to their supported kernel branch (which lags behind master).
    - Cyph0n 4y ago
      Ah, Red Hat is indeed a good example. Thanks for clarifying.
  - quesera 4y ago
    > why would a company ever do this? Distro kernels are general purpose and include a lot of stuff you do not need. A custom-configured kernel is much smaller and (consequently, theoretically) more secure.
    - Cyph0n 4y ago
      Not sure I follow. A custom kernel doesn’t need to based on master.
  - lillecarl 4y ago
    If you have 100000 servers it's in your interest to test HEAD on 100 of them to be able to catch and bugs before they hit a release. That's how open-source should work!
    - Cyph0n 4y ago
      Why not run 1-2 releases behind and test/qualify a later release? A commenter below gave a good example of a company that would need to run a bleeding edge kernel (Red Hat). The vast majority of companies would never need to do that though.
      - fiedzia 4y ago
        > Why not run 1-2 releases behind and test/qualify a later release? This may work for most people, but not all. It's easier to get things fixed while developers still work on something, than weeks/months later. Also if you have not most-popular hardware/software configuration, testing done by others isn't necessarily sufficient for you.
      - sph 4y ago
        Maybe your company needs that super duper new feature that's on master. Or you're Google scale and that 0.5% improvement in IO throughput would save you millions a year. You wouldn't want to wait until it hits the stable branch if possible.
- fiedzia 4y ago
  > If some hardware breaks it, the hardware must be seriously broken. And it sometimes is. > If a change breaks it, some one will probably have called read(2) a few times before that kernel is shipped to you. I've seen to many kernel bugs on new hardware to believe this is enough. Maybe not in read(), but still in something that should work. Throwing testing on users may have been acceptable in the past, but not anymore.

Veuxdo 4y ago

If the read(2) implementation itself never changes, then unit tests of it shouldn't ever break, I think...

sph 4y ago

If some hardware breaks it, the hardware must be seriously broken. If a change breaks it, some one will probably have called read(2) a few times before that kernel is shipped to you. A change is filtered through multiple developer and the kernel has some kind of smoke and consistency tests it is subject to. Also there are people and companies that compile their kernel from the master branch and run software on it. No one's gonna ship Linux with a broken read syscall. And if there were tests, one could still ship a broken read syscall anyway. Tests do not guarantee the absence of bugs.

Cyph0n 4y ago
> Also there are people and companies that compile their kernel from the master branch and run software on it. Genuinely curious: why would a company ever do this?
- sph 4y ago
  I was thinking of Red Hat (for example), that pays kernel developers and regularly tests and backports features for its paying customers. That means having a finger of the pulse of the kernel tree, and trying changes to decide whether it might be worth to port them to their supported kernel branch (which lags behind master).
  - Cyph0n 4y ago
    Ah, Red Hat is indeed a good example. Thanks for clarifying.
- quesera 4y ago
  > why would a company ever do this? Distro kernels are general purpose and include a lot of stuff you do not need. A custom-configured kernel is much smaller and (consequently, theoretically) more secure.
  - Cyph0n 4y ago
    Not sure I follow. A custom kernel doesn’t need to based on master.
- lillecarl 4y ago
  If you have 100000 servers it's in your interest to test HEAD on 100 of them to be able to catch and bugs before they hit a release. That's how open-source should work!
  - Cyph0n 4y ago
    Why not run 1-2 releases behind and test/qualify a later release? A commenter below gave a good example of a company that would need to run a bleeding edge kernel (Red Hat). The vast majority of companies would never need to do that though.
    - fiedzia 4y ago
      > Why not run 1-2 releases behind and test/qualify a later release? This may work for most people, but not all. It's easier to get things fixed while developers still work on something, than weeks/months later. Also if you have not most-popular hardware/software configuration, testing done by others isn't necessarily sufficient for you.
    - sph 4y ago
      Maybe your company needs that super duper new feature that's on master. Or you're Google scale and that 0.5% improvement in IO throughput would save you millions a year. You wouldn't want to wait until it hits the stable branch if possible.
fiedzia 4y ago
> If some hardware breaks it, the hardware must be seriously broken. And it sometimes is. > If a change breaks it, some one will probably have called read(2) a few times before that kernel is shipped to you. I've seen to many kernel bugs on new hardware to believe this is enough. Maybe not in read(), but still in something that should work. Throwing testing on users may have been acceptable in the past, but not anymore.