Kernel Versions

I see what you mean, but in the "stable" branch there aren't kernel release upgrades except for minor fixes (for example 4.19.50 to 4.19.51), so the actual kernel version isn't going to change. And yes, they refer to the master snapshots.

98% true.
There are a few exceptions like https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=2301bbdf880b8e222008fbd350cd903fdd447d3e
(ipq806x kernel was bumped from 4.9 to 4.14 in the release branch before 18.06.0-rc1)

But my point is mainly that there has been generic confusion about the relation of "snapshot" to 19.07.0 as some people apparently thought that 19.07.0 was going to be compiled from master. It is better to clearly reference to master as master, not only as "snapshot".

Just highlighting all the snapshots:
http://downloads.openwrt.org/releases/17.01-SNAPSHOT/
http://downloads.openwrt.org/releases/18.06-SNAPSHOT/
http://downloads.openwrt.org/releases/19.07-SNAPSHOT/
http://downloads.openwrt.org/snapshots/targets/

2 Likes

hmmm... why is this not downloads.openwrt.org/master/targets/ ?

BTW: Please applaude to takimata, who, with the speed of light, created a php script to scrape and format the data.

:+1: and like (click the like button)!

Still a bit WIP behind the scenes: https://openwrt.org/docs/techref/targets/target_kernelversions

EDIT: Do we need some explanatory text there (that is editable like every other wiki page), or is it sufficient to have just the plain table (and the page would not be editable)?

1 Like

Because it's a snapshot of master, not the master itself. :wink:

3 Likes

...but following the release snapshot nomenclature it could/should be ../master-snapshots/... :slight_smile:

Anyways, we are slightly drifting OT.

In my opinion that shouldn't happen. But its still a great point. Maybe the "snapshot" header should be changed to "master" sinc that kernel version table refers to each release's snapshot kernel version, right?

Another great point...

Well, there should be added a table showing the minor versions that are being used, for example 4.14.158, 4.19.88, since all the bumps made to the kernel are (or should be made) in the stable and master branches, and a description as you say, that I can Write, but when I go to the page it doesn't allow me to edit.

Good point. Since we're going by the information Git offers, we should take the kernel version for releases not from the head references (i.e. the branches, e.g. "18.06") which can (and from your example actually do) change later on, but from the tags (i.e. the tagged releases, e.g. "18.06.0"). That is a trivial change, though.

We already did that, see https://openwrt.org/docs/techref/targets/target_kernelversions

While it's certainly possible (we would only have to parse include/kernel-version.mk from the respective tag), this would make for a lengthy scraping session and a rather unwieldy table in the end. Since the minor version changes between releases, we would have not to only list "18.06" but all the minor point releases, too.

However, we could also just decide only to list the "latest point release for any release", so not "18.06" but rather "18.06.5". (Arguably there is no point to not use the latest point release, why display the others then.)

1 Like

I think kernel major version for latest HEAD [Edit: or tagged release] is plenty.

The rest is available in git or from the running device. It also tends to be treewide. (4.19 is always 4.19.123 or whatever)

Adding the minor version would also detract from readability of major version. β€œYes, your router is running 4.9 and everything else is running 4.19”

Sorry I haven't seen it until now.

What I meant was something like this:

Generic Kernel version:

Main version | Minor version
4.9          | 4.9.206
4.14         | 4.14.158
4.19         | 4.14.88

Kernel version per target:
(table you guys already made)

See what I mean?

Yes, but it doesn't work that way. Every tagged release has its own minor kernel versions. For example, 18.06.4 has 4.9.184 and 4.14.131, while 18.06.5 has 4.9.198 and 4.14.151. You can't just state a "generic minor version" for the whole table.

1 Like

Yes but shouldn't we refer to the snapshots of each version instead of each tag? cause if we refer to each tag it's going to be a big big table.

I have to come back to "Who is this table intended for and what is their use case?"

I agree that a quick, "ar71xx for 18.06 is running kernel 4.9" and "Most targets on master are running 4.19" is of some value to a small group of users.

As far as I'm concerned, knowing the minor version is only of interest to developers, and generally only for a specific device that is somehow "broken". In that case, the user should have source in front of them and the knowledge of how to quickly determine the kernel version and/or change it.

3 Likes

Snapshots of past releases (e.g. 18.06-snapshot) are, for all intents and purposes, irrelevant to the general public. I would suggest to include the respective latest point release for each major release (e.g. 18.06.5).

Generally speaking, we have all the information at our disposal. We can do the bestest, hugest table of all times, with breakdown to every tag and every minor version. I can even do that automatically on a daily basis. The issue is deciding which information actually makes sense.

Edit: and Jeff beat me to it:

I would agree. If you're so deep into the matter that you absolutely need to know the minor version it's very likely that you don't need a neat table in the wiki, you would probably dive into the source and look for yourself.

2 Likes

Minor version information is practically useless, as it changes practically weekly.

To be honest, even the major version is rather useless information for the general user populace. If you have enough knowledge to really assess the benefits/drawbacks of a certain Linux kernel version, you surely can also find out the exact kernel version in use by yourself (and are likely to use the master in any case...).

5 Likes

I see what you mean about the minor version.
You guys insist very much on not having the table or any table at all, maybe because I haven't explained its intended purpose. This distribution (OpenWRT) like any other distribution needs to have documentation, I am new to OpenWRT even though I know "a lot" (I've been in this for maybe 3-4 months) and I remember how confusing and difficult it was to learn how OpenWRT works and how it was managed, it didn't have any documentation! Everything I saw was either outdated, missing or hidden, and I want to change that. Although I see your point, beginners and basic users won't need at all the kernel version, it is completely useless. But this table isn't in the section "Basic setup" It's in the "Technical Documentation", It's meant to be seen by other linux users and developers and OpenWRT users and developers as a reference, as a central location to see the kernel version for each target in a simple and easy way, for example if I can't go on my computer cause I'm outside and I want to check the kernel version of each target I can go to the table and not have to check each folder on git to find the version in the makefile.
I hope I'm explaining it right.
About the rest of the missing configuration, wireless is one of them, the documentation doesn't have the 802.11k and 802.11v, and many more, also doesn't explain how to get wpa3 working since the last time I checked, this needs to be added and as soon as I have time I will do it. If these are only applicable to the trunk version I suggest adding a page with the available config options for each stable version, or, a icon or symbol indicating the version compatible, and that way one can know witch are available for a given distribution, but that is another topic.

I say, that there is quite the scenario.

Yeah I know Hahaha :sweat_smile::sweat_smile::sweat_smile: