**** BEGIN LOGGING AT Sun Aug 18 02:59:57 2019
Aug 18 12:26:32 <thinkfat_> the 4.19-rt branch of the bb linux kernel on github, is that usable?
Aug 18 12:26:39 <thinkfat_> default seems to be 4.14
Aug 18 12:27:18 <zmatt> probably depends on which non-mainline drivers you rely on (if any)
Aug 18 12:27:37 <zmatt> although the bone kernels have fewer of those than the ti kernels anyway I think
Aug 18 12:28:16 <zmatt> wait, with "bb linux kernel" do you mean rcn's "bb-kernel" repo or the beagleboard/linux repo?
Aug 18 12:35:16 <thinkfat_> zmatt: https://github.com/beagleboard/linux/tree/4.19-rt
Aug 18 12:35:51 <zmatt> ah ok 4.19-ti-rt
Aug 18 12:37:25 <zmatt> I've never seen any use for that repository since they're just snapshots of the patched tree as produced by rcn's kernel build tools, which are what I use if I want to build a customized kernel
Aug 18 12:38:08 <thinkfat_> I think I mostly care for the most recent kernel version, for maintenance reasons
Aug 18 12:38:43 <thinkfat_> and for that, a 4.19 or 4.14 kernel would be most welcome
Aug 18 12:40:43 <zmatt> I mean, if you're using debian you can just apt-get install linux-image-4.14.108-ti-r114 or linux-image-4.19.59-ti-r25 (or their -ti-rt- variant if you need it)
Aug 18 12:41:52 <zmatt> I currently still use 4.14-bone myself, I should probably look into switching to 4.19-bone at some point
Aug 18 12:44:13 <thinkfat_> Hm, on Debian I've been with ti kernels I think
Aug 18 12:44:25 <zmatt> yeah those have been the default for a while now
Aug 18 12:45:08 <zmatt> bone used to be the default and I've stuck with them (albeit with heavily customized config and some local patches)
Aug 18 12:45:27 <thinkfat_> ti kernels, they seemed to work somewhat decent, especially regarding power management, so I guess I'll stick with them.
Aug 18 12:46:15 <thinkfat_> I'm guessing the kernel would be good for a couple more boards than just the bbb, which would also be very convenient
Aug 18 12:46:17 <zmatt> yeah I think ti kernels were (and maybe still are) better if you need power management stuff, dunno what the current state is
Aug 18 12:47:00 <zmatt> if I'd need a kernel for another board I'd build a separate kernel for it anyway, but I can understand that being able to use one kernel on multiple targets can be more convenient
Aug 18 12:47:33 <thinkfat_> not the binary, but the same sources. Of course I'd build a separate kernel for each board, depending on the configuration...
Aug 18 12:48:15 <zmatt> ah, fair
Aug 18 12:48:56 <zmatt> I guess maybe if I'd make the choice today I'd use the -ti series too, dunno.
Aug 18 12:49:14 <zmatt> but at the time -bone was the obvious choice and I've had no reason to switch since then
Aug 18 12:49:18 <thinkfat_> I'm maintaining a commercial linux distribution and I'll have to support a couple of TI platforms, so if I can use the same kernel sources (with some patches maybe) for multiple boards, that's always a plus
Aug 18 12:49:33 <zmatt> so... why -rt ?
Aug 18 12:50:03 <thinkfat_> well, because all the bsps we have are -rt...
Aug 18 12:52:09 <zmatt> do your customers actually use/need it?  rt can be nice but you'd still need to ensure stuff that needs to be real-time is in a separate process/thread and has appropriate realtime priority assigned
Aug 18 12:52:25 <zmatt> otherwise it's just an overall slower and probably buggier kernel
Aug 18 12:57:32 <zmatt> replacing pretty much every spinlock (which on non-SMP machines is not a lock at all but just disables interrupts) by a priority-inheritance mutex is obviously not without downsides
Aug 18 12:59:27 <thinkfat_> zmatt: some do, yes. Otherwise I'd not go through the hassle to provide it.
Aug 18 13:00:32 <zmatt> I guess you can build both -rt and non-rt kernels from the same tree since it's still a config option... I wonder if the -rt patches still have any impact even when not using PREEMPT_RT
Aug 18 13:01:42 <thinkfat_> zmatt: if you disable PREEMPT_RT, there's no performance penalty. But there are some changes for the sake of supporting RT that cannot be simpy be configured off. But not general stuff
Aug 18 13:02:56 <thinkfat_> zmatt: anyway, we don't ship binary kernels anyway. If you build a system, you always compile a tailored kernel with just the stuff you actually need.
Aug 18 13:03:08 <zmatt> sweet
Aug 18 13:05:16 <thinkfat_> userspace comes precompiled, though. but it's also assembled to match requirements while you build the system. A minimal system is pretty much only busybox in an initramfs or initrd, couple 100k or so.
Aug 18 13:21:53 <zmatt> neat
Aug 18 13:42:10 <veremitz> zmatt: what permutations of beagle kernels are available now?! sounds like we're up to 4 'flavors' plus combinations
Aug 18 13:42:26 * veremitz throws a 'u' in there .. 
Aug 18 13:42:30 <zmatt> uhh, the same ones as always
Aug 18 13:43:41 <zmatt> in fact more flavors were around in the 3.14 days than now
Aug 18 13:44:04 <zmatt> ah no never mind it seems the xenomai kernels still exist too, I thought they'd gone
Aug 18 13:47:23 <veremitz> how does -ti compare with vanilla rcn-ee sources?! :p
Aug 18 13:47:38 <veremitz> you mention something about power management
Aug 18 13:47:57 <zmatt> I have no idea what you mean by "vanilla" ... all of these trees are maintained by rcn
Aug 18 13:48:34 <veremitz> ah thats ok then. I haven't looked at his tags recently enough :/
Aug 18 13:48:50 <veremitz> but we have -rt, non-rt, -ti, ...
Aug 18 13:49:05 <zmatt> bone, bone-rt, ti, ti-rt, ti-xenomai
Aug 18 13:49:06 <veremitz> I guess only some apply to different branches .. I could use a matrix table :D
Aug 18 13:49:13 <veremitz> gotcha
Aug 18 13:49:38 <zmatt> bone has branches for all major kernel versions I think
Aug 18 13:52:28 <zmatt> bone-rt has most of them, ti and ti-rt only LTS versions (and ti-rt only since 3.14), xenomai only a select few
Aug 18 14:13:03 <veremitz> ok cool thanks
Aug 18 14:14:52 <zmatt> (the reason is that the bone kernels are based on mainline while rcn's ti kernels are based on TI's linux repository, which only has branches for LTS releases)
Aug 18 14:21:46 <veremitz> ah, he's only partially forward-porting?
Aug 18 14:21:56 <zmatt> ?
Aug 18 14:21:57 <veremitz> some might just not apply/work :/
Aug 18 14:22:16 <veremitz> zmatt: I know rcn carries a lot of patches in his repo
Aug 18 14:22:50 <veremitz> some patches will/not apply to mainline ofc.
Aug 18 14:22:51 <zmatt> I think they typically all get forward-ported, but I haven't kept close track
Aug 18 14:22:57 <veremitz> ok
Aug 18 14:23:10 <zmatt> I've helped forward-porting uio-pruss to 4.19
Aug 18 14:23:17 <veremitz> another feature matrix would be cool :D rcn-ee[m] <=
Aug 18 14:23:35 <veremitz> good good. That's a bad LTS branch, but eh :D 4.14 or 5.x
Aug 18 14:23:50 <zmatt> a "bad LTS branch" ?
Aug 18 14:24:01 <zmatt> 5.x has no LTS yet
Aug 18 14:24:08 <veremitz> yeah it had lots of issues with arm and ppc .. whether they've all been irond out I dunno
Aug 18 14:24:14 <veremitz> indeed.
Aug 18 14:24:22 <zmatt> but 4.14 is indeed still the default I think
Aug 18 14:24:28 <zmatt> dunno what the state of 4.19 is
Aug 18 14:24:30 <veremitz> hopefully greg will post about the next 5.x LTS
Aug 18 14:24:37 <veremitz> 4.14 is fine afaik
Aug 18 14:24:43 <veremitz> I'm still running 4.4
Aug 18 14:24:48 <zmatt> oof
Aug 18 14:24:50 <veremitz> 4.19 goes EOL next year iirc.
Aug 18 14:25:21 <veremitz> except on arm.. which varies all over lol .. I have a solid BBB on 3.13?! something totally daft!
Aug 18 14:25:32 <veremitz> as its my DHCP server .. I haven't upgraded lol
Aug 18 14:25:59 <veremitz> it should be easy enough though
Aug 18 14:27:27 <zmatt> oh yeah weird, 4.14 is maintained till 2020-01, 4.19 till 2020-12 .. I'm not sure I'd call that "LTS" :P  ... but I guess it's still a lot longer than the non-LTS versions
Aug 18 14:27:58 <veremitz> aye
Aug 18 14:28:08 <veremitz> oh I got the 4.1x backwards :D
Aug 18 14:28:45 <zmatt> ok well 4.14 works fine for us
Aug 18 14:30:01 <veremitz> yup
Aug 18 14:31:55 <zmatt> oh actually LTS for 4.14 has been extended to 2024-01 it seems
Aug 18 14:32:12 <veremitz> ah.. really ..
Aug 18 14:32:20 <zmatt> well.. https://www.kernel.org/category/releases.html
Aug 18 14:32:45 <veremitz> so it has .. that musta been recent
Aug 18 14:33:09 <veremitz> and 5.4 is next LTS
Aug 18 14:33:42 <veremitz> albeit only for 2 years :/ wtf.. lol
Aug 18 14:34:16 <veremitz> so 4.9 and 4.14 are the only true *L*TS
Aug 18 14:34:29 <veremitz> 4.4 a close second :D
Aug 18 14:34:32 <zmatt> it was indeed recently bumped https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/content/releases.rst?id=a294222b772df262eb284c0503f6a6070f5bb22a
Aug 18 14:34:51 <veremitz> oh well spotted, I wondered whether there was a git repo for it ..
Aug 18 14:34:52 <zmatt> I wonder based on what criterium LTS EOL dates are bumped
Aug 18 14:35:01 <zmatt> yeah I had to search a bit
Aug 18 14:35:42 <zmatt> it looks like all of the LTS releases so far had their EOL date bumped
Aug 18 14:36:03 <veremitz> does indeed
Aug 18 14:36:20 <veremitz> I guess there's probably an estimated 'life' and depending on stability ..
Aug 18 14:37:30 <veremitz> ah its a pelican site .. noice
Aug 18 14:42:25 <veremitz> what's ideal is I now have a git source to do CI testing from, so ++ty for that
Aug 18 14:42:46 <zmatt> hmm?
Aug 18 14:42:49 <veremitz> and .. if I can spot the bit of code, we can add a 'git log' to announce emails :D
Aug 18 14:58:44 <veremitz> https://git.kernel.org/pub/scm/docs/kernel/website.git/tree/plugins/releases.py#n574 <= so copy that line with s/ds/l/ for a git log :D perfect!
Aug 18 14:59:06 <veremitz> (and the following ones ..)
Aug 18 14:59:09 <veremitz> fabulous!
Aug 18 14:59:19 <veremitz> two mini problems solved! \o/
**** BEGIN LOGGING AT Sun Aug 18 22:16:43 2019
**** ENDING LOGGING AT Mon Aug 19 02:59:57 2019