Someone said that the kernel community is sick; what is the health of the community and what can we do better?
People can be harsh, but Boris never had a problem. Of course, people choose who they work with. Julia is overall very impressed with the helpfullness of people. Sometimes there is harshness, but usually that is deserved. Grant says that 99% of the time it’s OK, but it’s the 1% that sticks. And this does keep people out of the community so it is a concern. So if you see someone saying something abusive, call them out – and Grant hopes that if he does it, you’ll call him out as well. Thomas says that there are some developers who just keep on pouring out shit even if you tell them several times how they should be changed. Being polite about it doesn’t work because then they don’t learn.
When are device trees going to go out of the kernel tree?
It would be really good to have a separate repository, but for the embedded platforms that is often really painful. There is actually already a tree on kernel.org that mirrors just the device tree part. But nobody is really working on it. Ideally the build system would first look in the kernel and then in the external tree.
When are we going to see device trees in other arches?
There is a little bit of use on x86 for specialised use cases. The test cases will actually pass on x86. But there’s not really a demand for it.
There are parts of the kernel that don’t get much love. Which parts should see work.
The parts of the kernel that get love are the parts that bug people, so if it doesn’t get love then probably nobody cares.
The core kernel is now OK, cleaning up the in-kernel users is a nobrainer. The hard work to do is the userspace interfaces. For BSD it’s relatively easy because they have userspace in-tree. The syscalls are not even the hard part, the problem is the ioctls.
There is no regression maintainer anymore, but still we don’t seem to get more regressions. How come?
We have more tools, automated testing, and in-kernel debug infrastructure. Also we have a better process now. And also the static analysis by Julia helps (it runs every day).
One way to get involved in the kernel is to analyse a bug and fix it.
There was a recent patch that adds a flag to netdev calls saying that more packets are coming, which really boosts performance. The block layer had something like that for years already. This indicates that there isn’t enough communication between subsystem developers. How can we improve?
There’s a similar issue with devm, pickup is often slow. LWN is a good source. You only go look at how it’s done somewhere else when there is a problem.
We’re adding a lot of complexity in a lot of places, is that really manageable?
We’re moving complex stuff out of the arches into the core code, which makes it easier. We’re compartmentalizing the complexity. And when it really becomes crazy, we take a step back. Sometimes it just has to be painful because Linux runs in so many situations, you have to deal with the corner cases. Complexity is also something that we think about during review: is the gain really worth adding all this code?
How small is too small?
The barrier is the amount of time that someone is willing to work on it. The work on shrinking the kernel is great, but there are very few people who are willing to pay for it. But there’s been some pushback against the tinification patches. So the question is: how much do we want to cater for people who want to do things that we consider crazy? As long as it doesn’t violate common sense, we try to accommodate with the needs. But the tinification example is one which violates common sense.