gregkh

8 ms·

1.
by gregkh 5mo ago
The members of the kernel security team are not allowed to tell their employers anything that happens on the security list. They are there as individual members, not as employees. And try to define "major distros" in a way that a
2.
by gregkh 2y ago
They hide structures very easily, allowing programmers to accidentally put them on the stack or use them as parameters in functions where they shouldn't be doing so. By forcing "struct" on the name, it makes it more obvious
3.
by gregkh 3y ago
The amount of resources and other stuff that the LF provides to the Linux kernel community has increased over the years, including last year. Just because new people are brought in with new projects (that the LF member companies want to ho
4.
by gregkh 3y ago
Did anyone think to actually ask the developer who is maintaining the LTS kernel versions why he made that change (back in February?), i.e. me? {sigh} No, I guess that would take too much effort, and wouldn't result in such a click-bai
5.
by gregkh 3y ago
No, the only rust code accepted into any released kernels is basic framework infrastructure so that someday, maybe, in the future, real functionality could be written in rust. There are many out-of-tree examples of rust kernel code, but as
6.
by gregkh 4y ago
This already happens today at many companies. I write a few of these a year for companies that I do not work at, and have been for the past decade or so. It's not unusual and the companies that recognize that having their developers
7.
by gregkh 4y ago
Corporate guys "manage me"? Have you talked to any corporate guys who have actually tried that and discussed the results with them? :)
8.
by gregkh 5y ago
Yes, and because of that, we created a new process for those types of issues (i.e. broken hardware problems that need more coordination.) That process is documented at https://www.kernel.org/doc/html/latest/p
9.
by gregkh 5y ago
I've described how we (the kernel security team) handles this type of things many times, and even summarized it in the past here: http://www.kroah.com/log/blog/2018/02/05/linux-kernel-releas..
10.
by gregkh 5y ago
While I did drop by a lot, you aren't describing me, but rather another Linux kernel developer who worked at IBM in our group at the time who is by far more brilliant and smarter than I. I've never smoked, and at that point in tim
11.
by gregkh 5y ago
I'm not understanding the question here at all, sorry, can you please rephrase it? And if you have questions about how this happened, look at the source for when it was merged, it's all there for everyone to review :) Also, udevd
12.
by gregkh 5y ago
The person who started udev (i.e. me), and the person who did the majority of the work on udev to make it into the proper solution for everyone (i.e. Kay Sievers), both agreed that it made more sense to move it into the systemd codebase in
13.
by gregkh 5y ago
Off the top of my head, no. The big "downside" is that it takes more work on the patch submitter side. But the benefits in the end are almost always more than worth it (easier reviewer time, easier time to track down problems, be
14.
by gregkh 5y ago
Merge the portions that you know are correct and will have no affect on anyone else now, which makes future work easier as you do not have to keep those "working" commits up to date. We do this all the time with kernel development
15.
by gregkh 5y ago
Thanks for the support. I also now have submitted a patch series that reverts the majority of all of their contributions so that we can go and properly review them at a later point in time: https://lore.kernel.org/lkml&#x2
16.
by gregkh 6y ago
Why is it "excessive"? We are running 30+ fixes a day in these kernel releases, who would benefit if we delayed in getting those known-bug/security fixes out to the world quickly and properly tested (as we are currently doin
17.
by gregkh 6y ago
So you want us to just stop fixing bugs and pushing out those fixes to users? That feels risky, if you do not want to upgrade to solve known problems, that's fine, feel free to skip upgrades. But why would you want to prevent those w
18.
by gregkh 6y ago
Time to get a new ISP? :)
19.
by gregkh 6y ago
And what would that help solve?
20.
by gregkh 6y ago
We have so many different CI systems running on the kernel on a hourly basis. We have the 0-day bot from Intel that runs so many things on all developer trees. We have kernelci running on many many different hardware platforms, and we have
21.
by gregkh 6y ago
Simplest thing to do, just run Linus's latest releases (the -rc releases), or from his git tree, on your machine and report any problem. Second-simplest thing to do is to run the linux-next branch/tree on your machines and report
22.
by gregkh 6y ago
If people don't report bugs, we don't know they are there as it "works for me!". This isn't "negativity", this is people not understanding how the process works :) And you're welcome!
23.
by gregkh 6y ago
Where in the current CI that we have today is lacking that needs to be improved? We always want more testing and testers, what is preventing everyone from helping with this?
24.
by gregkh 6y ago
I get a vacation? Hah!
25.
by gregkh 6y ago
Everyone gets older, the alternative isn't as attractive :) Seriously, the kernel averages about 200-250 new contributors every release (i.e. every 2 1/2 months). We are not starved for new contributors at the moment at all, do y
26.
by gregkh 6y ago
"regular stable kernel" lives only about 3-4 months, just long enough for the next release from Linus to feel "good enough". "longterm kernel" lives for 2+ years. I pick one each year (usually the last one rel
27.
by gregkh 6y ago
That "partially-ABI stable" is the same exact thing that Red Hat and SUSE and Debian have been doing for 20+ years now. Nothing major and exciting there, but see the presentations at the Linux Plumbers conferences for details on
28.
by gregkh 6y ago
And what would that "middle ground" look like? With the current rate of change that the kernel community develops at, including the patches backported to the stable/longterm kernels, it's impossible to try to evaluate ea
29.
by gregkh 6y ago
Android doesn't seem to mind, they require the LTS updates to be taken for their devices (well, "require" is a strong word, they are pushing harder now than they were in the past, "required" will be happening in the
30.
by gregkh 6y ago
They feel like they know better and do not want all of the fixes that the LTS kernels provide for some crazy reason. I suggest you contact them if you rely on a RHEL kernel to ask them why they do this, it's always seemed crazy. Note,

More ›