What is upstream /downstream with ref to kernel
 

Read here ...
https://www.zdnet.com/article/google...roid-security/

{{
Even when these downstream customizations are meant to add security to a device, they also introduce security bugs
}}

And at the end ...

{{
... device-specific kernel modifications would be better off either being upstreamed or ...}}}

Can anyone please explain what the above mean?

Judging by a quick skim of the article linked, the first quote means: Samsung is modifying Linux kernel code to try and prevent attacks on their phones, but this could cause security problems for Android itself and/or other non-Samsung phones.

The second quote would mean that; any modifications to kernel code should be done by Google, since Google develops and maintains Android itself.

In regards to desktop and server based Linux distributions; "upstream" means the Linux Foundation, as their the ones that develop and maintain the Linux kernel itself. "Downstream" means the various Linux distribution's developers that develop and maintain the individual Linux distribution's, like Ubuntu, openSUSE, Fedora, etc, etc, etc.

Not necessarily true.

Upstream usually refers to the source that is being modified, for example for CentOS the upstream source is RedHat.

Downstream would refer to people who are modifying the source code, so RedHat would consider CentOS (and those that base their distro off of RedHat source) as "downstream".

The thread title is: "What is upstream /downstream with ref to kernel".

So does Redhat write their own kernel? No, they get it from the Linux Foundation, don't they?

I also pretty much made your above point in the second paragraph of my post #2, didn't I (you know, the point about Google making the modifications to Android's kernel - doesn't the same apply to CentOS/RedHat or Ubuntu/Linux Mint, no?)?

Honestly, the amount of nit picking at this place... no wonder I don't have much interest in this place these days...

And CentOS get their kernel from RedHat, so for CentOS, RedHat is the "upstream", and for anyone that makes their own distro based off of CentOS then CentOS is the "upstream", while ultimately for the kernel the "upstream" is, indeed, the Linux Foundation the code may have been modified at any place on the way "down".

You might say Nit Picking personally I prefer the term Improving accuracy of replies to the OP

Get over it.

Again;

Does Google write their own kernel for Android? I believe they modify the Linux kernel for Android, yes? Does the above quote/statement not imply what you're saying? ...since Google don't actually write their own kernel for Android, and merely just take the existing Linux kernel and modify it for Android, yes?

Isn't CentOS basically RHEL without the RHEL branding, no?

I was merely pointing out that I was responding to the thread's title - which was about the kernel and not about derivative distributions - although I once again also covered that and you what to nit pick and imply otherwise.

I'm sure you would say that, and at this point, I'm done with this thread.

Get over yourself.

From you replies, I think I have deduced the following ...

Downstream means adding / maintaining of kernel code in Android branch/fork/whatever its called.
Upstream means adding/ maintaining of owner's code to Linux Foundation.

Eg Samsung writes a new package. Or they can change one of their own packages. They can do anything they want to these packages. It's theirs.
These packages are added to the Linux Foundation kernel project repository.

Linux Foundation "pulls" the project to (eg) Kernel 1.0 project. In this 1.0 Kernel Project, Linux Foundation can change / fix Samsung's packages ( or not add them at all, or remove them). ( Technically, they are fixing things downstream? )

Android pulls all of it's kernel source/ binaries from Kernel 1.0 project to Android-Kernel 1.0.
Any amendments done here to the existing kernel source/binaries are considered as downstream maintenance. Are new packages considered upstream?

Samsung modifies stuff in Android-Kernel 1.0. It may or may not be their own packages (And if it was their packages, it may or may not have be modified by Linux Foundation) This is kernel modification done downstream.

Samsung ADDS New packages to the kernel, not modifying existing packages - it's their own packages. This could be considered Upstream or downstream.
However, as it is an amendment to what is fundamentally Kernel Code, I'd probably call it Downstream.

Well that's my take on it anyway.

Think of it like this:

Let's say I wrote a program, and you modify it's code; then I'm "upstream" and you're "downstream" - that's probably the easiest way to think about it.

With regards to software, upstream and downstream are directions.

Upstream is towards the origin, downstream is away from the origin.

A package or change cannot be described as upstream/downstream on its own - the term only makes sense in relation to another item in a dependency chain.

First, the article is written by "someone", there's a link to who they are. That's great, but I consider it to be subjective:Secondly they are almost entirely quoting someone else where in the second paragraph of this article, they invoke the name of a GPZ person and link to their blog, where the remainder of the article is a combination of tidbits from various other sources and largely quotes this GPZ person and their blog posts. It is unclear if this other person has been interviewed or if their public blog posts are just being referenced.

My humble opinion is that terms, are terms only, and they can mean some variety of interpretations.

But if you, baggister, wish some input interpreting what they are meaning as part of this article, here are some opinions, which you may consider or ignore.

And during the course of my composition and previews, I do see that you've provided an update/conclusion. If you're fine with that, I'm fine too:

The first quote you mentioned:Is preceded by the following:And the later quote you raised:Is missing the remainder of that sentence:My interpretations:

1. The article is some bunch of claims by someone who is writing their article, largely using the content from another one.
2. They seem to be saying that downstream is within a kernel driver and upstream is within a userspace driver.
3. What I really feel that are discussing is the correct point, or location, for addressing security.
4. Having dealt with security matters, things start at a basic level, and grow from there, and also never stops. Arguing as to whether it is best to be in lowest level drivers, the OS, or applications, I say that it should be in all of them, and that I'm not seeing any technical arguments compelling me to move towards one direction vs another. In fact, I submit that it really depends upon the situation identified as the security concern and what the proposed fixes are. In other words, I feel it varies.
5. Anyways, without getting into too much of a stump speech, those are my opinions. Those and "Would you like me to move this discussion to the Linux - Security forum where it may garner more applicable viewings and replies?"
6. Final one would also be: "Challenge others' points of view and opinions, but do so respectfully and thoughtfully ... without insult and personal attack. Differing opinions is one of the things that make this site great."
7. EDIT: I feel it also is near exacty, "What boughtonp said"

EDIT: Sorry boughtonp, I thought you were the OP - disregard this post.