4 ms·

The response [0] from a Linux kernel maintainer means this is dead on arrival. [0] https://lore.kernel.org/dri-devel/8719bf65-6906-0426-1ce4-b08970727a08@amd.

The response [0] from a Linux kernel maintainer means this is dead on arrival. [0] https://lore.kernel.org/dri-devel/8719bf65-6906-0426-1ce4-b08970727a08@amd.com/ https://lore.kernel.org/dri-devel/8719bf65-6906-0426-1ce4-b0...

rincebrain 3y ago
(I work for Google, not on anything related, opinions my own, etc) I would suspect it's not going to be dead unless the maintainers think the fundamental premise, not the architecture, is broken - if it's been brought up on a real piece of hardware, it's almost certainly because it was solving a real problem being experienced, and even if it involves reworking it completely, getting it upstreamed is much better than maintaining an enormous local delta.
rewmie 3y ago
To sum things up: > I strongly suggest that you read up on the basic of this before proposing any solution. Ouch.
pantalaimon 3y ago
Eh that sounds more like the API was abused/used wrong - not that the whole idea is fundamentally flawed. That’s just what code review is there to spot, not something that can’t be fixed.
jeffbee 3y ago
My experience watching google try to contribute to upstream kernel is their proposals are almost always based on things that have already been in production at google for years. So when I see an upstream gatekeeper accusing someone of not understanding what they are proposing, I am skeptical. The thing that is “dead on arrival” here is probably the ability of the general public to enjoy something that google already uses.
- rewmie 3y ago
  > So when I see an upstream gatekeeper accusing someone of not understanding what they are proposing, I am skeptical. Your comment reads like a textbook example of an appeal to authority. Google engineers don't walk over water, and what Google accepts in their internal networks considering on Google's tightly locked internal security infrastructure might not map to real world security environments. It also boggles the mind how you somehow presume a Linux kernel maintainer who repeatedly pointed out the failures of the proposed patch does not know what he is talking about. Unbelievable. > The thing that is “dead on arrival” here is probably the ability of the general public to enjoy something that google already uses. I'd wager that what the general public enjoys is working code with an excellent security track record thanks to the outstanding work by Linux kernel maintainers, who repeatedly stop broken submissions from being accepted.
  - jeffbee 3y ago
    > working code with an excellent security track record It seems we are talking about different projects.
    - rewmie 3y ago
      > It seems we are talking about different projects. Please point out a operating system that you feel has a better security track record than Linux.
      - medler 3y ago
        Pretty much any other Unix-like operating system. FreeBSD for example
        rewmie 3y ago
        So far in 2023 all CVEs reported on Linux had at most a CVE score of 0-1, which is also the score of all CVEs reported for FreeBSD. https://www.cvedetails.com/cvss-score-charts.php?product_id=47&fromform=1 https://www.cvedetails.com/cvss-score-charts.php?product_id=... What exactly is your definition of security track record? Do you have any, or are you parroting cliches?
medler 3y ago
> Yes, I have seen that and this is completely utterly nonsense. I have absolutely no idea how you came to the conclusion that this would work. I’m shocked someone would talk like this publicly from their company email. AMD doesn’t seem like a company I would want to work for.
- blueflow 3y ago
  If you are taking MR's from the public you are somewhat DDoS'ed with patches that are of low quality and will likely cause problems in your codebase. I totally understand that not everyone has the patience to deal with that with tactful language. Not implying that this mail must be an example of this.

rincebrain 3y ago

(I work for Google, not on anything related, opinions my own, etc) I would suspect it's not going to be dead unless the maintainers think the fundamental premise, not the architecture, is broken - if it's been brought up on a real piece of hardware, it's almost certainly because it was solving a real problem being experienced, and even if it involves reworking it completely, getting it upstreamed is much better than maintaining an enormous local delta.

rewmie 3y ago

To sum things up: > I strongly suggest that you read up on the basic of this before proposing any solution. Ouch.

pantalaimon 3y ago

Eh that sounds more like the API was abused/used wrong - not that the whole idea is fundamentally flawed. That’s just what code review is there to spot, not something that can’t be fixed.

jeffbee 3y ago

My experience watching google try to contribute to upstream kernel is their proposals are almost always based on things that have already been in production at google for years. So when I see an upstream gatekeeper accusing someone of not understanding what they are proposing, I am skeptical. The thing that is “dead on arrival” here is probably the ability of the general public to enjoy something that google already uses.

rewmie 3y ago
> So when I see an upstream gatekeeper accusing someone of not understanding what they are proposing, I am skeptical. Your comment reads like a textbook example of an appeal to authority. Google engineers don't walk over water, and what Google accepts in their internal networks considering on Google's tightly locked internal security infrastructure might not map to real world security environments. It also boggles the mind how you somehow presume a Linux kernel maintainer who repeatedly pointed out the failures of the proposed patch does not know what he is talking about. Unbelievable. > The thing that is “dead on arrival” here is probably the ability of the general public to enjoy something that google already uses. I'd wager that what the general public enjoys is working code with an excellent security track record thanks to the outstanding work by Linux kernel maintainers, who repeatedly stop broken submissions from being accepted.
- jeffbee 3y ago
  > working code with an excellent security track record It seems we are talking about different projects.
  - rewmie 3y ago
    > It seems we are talking about different projects. Please point out a operating system that you feel has a better security track record than Linux.
    - medler 3y ago
      Pretty much any other Unix-like operating system. FreeBSD for example
      - rewmie 3y ago
        So far in 2023 all CVEs reported on Linux had at most a CVE score of 0-1, which is also the score of all CVEs reported for FreeBSD. https://www.cvedetails.com/cvss-score-charts.php?product_id=47&fromform=1 https://www.cvedetails.com/cvss-score-charts.php?product_id=... What exactly is your definition of security track record? Do you have any, or are you parroting cliches?

medler 3y ago

> Yes, I have seen that and this is completely utterly nonsense. I have absolutely no idea how you came to the conclusion that this would work. I’m shocked someone would talk like this publicly from their company email. AMD doesn’t seem like a company I would want to work for.

blueflow 3y ago
If you are taking MR's from the public you are somewhat DDoS'ed with patches that are of low quality and will likely cause problems in your codebase. I totally understand that not everyone has the patience to deal with that with tactful language. Not implying that this mail must be an example of this.