@denix @pdp7 I don't do any real work on it, but it is nice to have something plain-text capable that fits in my pocket.
I was at FOSDEM for the weekend and left my laptop at home but kept up with everything while away using it.
I wouldn't do "real" work with it, but if I can respond to someone in the gym at 0530 while waiting between sets or w/e then it's pretty useful.

Clarkson's farm is such a great belly-laugh inducing show :)

@broonie which seems perfectly fair. The wording I initially used to tell people not to resubmit was poor and people did the exact opposite of what I wanted them to do..

@marcan That thread pissed me off. Total "perfect is the enemy of good" behaviour & lacking in respect for contributor time.

The "In 30+ years of programming..." comment really bothered me, I'd opened up my mail client to reply before deciding to not get involved.
Why accept 30+ years of bullshit rather than try to change things? "Inflicting" the crap you have/had to deal with on other contributors isn't okay IMO.

Twisting his own words, "we need to learn to swallow that, accept the patches, and move forward. Don't be discouraging"!

Asking a contributor to resubmit a patchset because they have a v4: above information that totally belongs in the commit history is utterly fucking ridiculous IMO.
The maintainer of a driver/subsystem is not the only person whose time is valuable. /shrug

This phone autocompletes riscv to roadblock

@pdp7 it wasn't even directed at you, was about me!

Shame that the RISC-V and Kernel devrooms at FOSDEM tomorrow clash time wise.
I suppose it's convenient that most of the kernel room is about BPF/fs & meeting people is more beneficial than attending talks.
PWM talk and then try to get into the RISC-V room I guess...

I like the healthy dose of scepticism about marketing claims that meeting people in person at conferences provides :)

@monsieuricon @wagi Look how far north Ireland is, but the gulf stream does us serious favours :)

@kernellogger I know little about building kernels for commodity hardware, but for my boxes I build deb-pkg by setting LOCALVERSION on the command line when calling make. Just makes me curious if the wacky looking sed command could be avoided.

@kernellogger out of curiosity reading through, what's the difference between setting "EXTRAVERSION" as opposed to "LOCALVERSION"?

@ljs On Windows in Chrome it works automagically for lore, google search etc (iirc if you use system theme), but not for more complex sites. There's a flag that can be set in the browser that forces dark mode everywhere, but it makes very poor colour choices. I look at lore a good bit in the dark and yeah - similar eye burning affect there!

@ljs Ah cool. Usually my browser coverts stuff (like lore) automagically to dark mode, but not for elixir. Thanks!

@ljs How did you get darkmode on elixir?

re: https://social.kernel.org/notice/AS3DZjXqKnHXtM8ZEG

Problem 1:
Nick fixed about a year ago, and to quote his commit message
```
In case the DTB provided by the bootloader/BootROM is before the kernel
image or outside /memory, we won't be able to access it through the
linear mapping, and get a segfault on setup_arch(). Currently OpenSBI
relocates DTB but that's not always the case (e.g. if FW_JUMP_FDT_ADDR
is not specified), and it's also not the most portable approach since
the default FW_JUMP_FDT_ADDR of the generic platform relocates the DTB
at a specific offset that may not be available. To avoid this situation
copy DTB so that it's visible through the linear mapping.
```

Problem 2:
I fixed a few months ago. The reserved memory scanning takes place too early
during init, before paging has been enabled. As a result, once paging *is*
enabled & the tlb flushed, trying to read the label names of reserved memory
regions causes a kernel panic. Apparently we were just the first ones to try
to write a remoteproc driver for RISC-V!
The solution was moving the call to early_init_fdt_scan_reserved_mem() after
the dtb was properly mapped.

Problem 3:
If the dtb is located outside of memory regions that the kernel is aware of, it
gets remapped into a region that the kernel *is* aware of.
However, this is done before we check for any reserved memories etc. If there
happened to be a section of unusable memory in the DT, that was then carved
out using a reserved memory region with a "no-map" property, it is entirely
possible that the DT would end up there.
This was introduced by Nick's fix for problem 1 & I've been avoiding it by just
putting the dtb somewhere that I know will be accessible to the kernel, and thus
avoiding the remapping.

Problem 4:
Introduced by my fix for problem 2. RISC-V uses the top-down method for looking
up memblocks for reserved memory regions. In a sparse configuration, if there
was to be an upper-most range, all of which was intended to be used as a DMA
region, memory allocated at some point in paging_init() would consume very small
sections of this upper DMA region. This can be observed on some configurations
on PolarFire SoC, and was easy to spot with memblock debug enabled.
These small allocations mean that when, in early_init_fdt_scan_reserved_mem(),
we look up the reserved memory node that is intended to consume the whole memory
region there is no longer enough space for this mapping.
This is worse if the memory region is non-coherent as the system will then
immediately crash.

Problem 4 can be fixed by using bottom-up searching for memblocks. This may also
fix problem 3 too, I just haven't tested it.
I'm super unsure as to whether switching the search order has some consequences
that I am just not aware of, but I probably won't be any the wiser until I send
a patch!

Found another reserved memory related problem in RISC-V's early init code today. This one appears to actually have been caused by my last fix, but that makes for 4 problems in the same but of code.

I have a fix for it, but it's either adding yet another band-aid, introducing a behaviour change or trying to find the time to do significant overhaul and hope not to make it worse!

@monsieuricon I gave it 24h then reported with the original post of this thread. I figured that was sufficient and then didn't want to be pushy!

@monsieuricon I do not use an app, just the website. Going to https://social.kernel.org/main/friends produces nothing other than 500 errors for me. Notifications works though!

@monsieuricon you know, it's kinda nice to have a website be (give or take) non-functional yet not feel aggrieved.
A symptom of knowing who is running it versus it being a faceless corporation.