In D15907#337696, @tcberner wrote:

Did you maybe apply it with svn patch and lost all the file permissions? ... well, no, then you wouldn't be able to read it :D

I'm fine with either check (<= 0 or @cem's version) with the same change applied to linux32_sysvec.c

Yeah, I buy that argument. We should check for non-negative but otherwise be permissive.

LGTM modulo one nit below

In D15952#337749, @chuck wrote:

I'm only finding two copies: sys/i386/linux/linux_sysvec.c and sys/amd64/linux/linux_sysvec.c but have updated the patch to fix those copies.

In D15952#337725, @emaste wrote:

LGTM.

We will also need to address the four copies of linux_trans_osrel (but after further investigation if desired, I have not checked exactly how the value they calculate is used).

[v3] Fix the Linux kernel version number calculation

applied Ian's comments, added definition for 'options SPIGEN_LEGACY_CDEVNAME' in opt_spi.h . builds, have not tested the bootup (yet). will do that next.

Mention Google Cloud.

I'll make buildworld only build the 1 needed target for the cross-compiler, but leave the defaults otherwise for the target compiler.

Tested on: Lamobo R1 w/ root-on-SD

We will also need to address the four copies of linux_trans_osrel (but after further investigation if desired, I have not checked exactly how the value they calculate is used).

Thanks

The updated summary is what will go into the commit message.

[v2] Fix the Linux kernel version number calculation

Restore the wrongfully deleted empty line.

Address last comments.

interesting! ok. I wonder how hard it'd be to integrate this into the existing ral driver. All of the RAL "HAL" routines right now really are almost complete drivers themselves with some shared bus management glue. HOw hard does it look to integrate it?

In D15952#337697, @cem wrote:

Right, I suggested using LINUX_KERNVER() to do this in my initial comment :-).

@mat should I ask for an exp-run now?

Ah, top level Linux Makefile emits a definition of KERNEL_VERSION using shifts.

So we need either the diff here, or an alternate diff that replaces x * 1000000 + y * 1000 + z in linux_map_osrel() with x << 16 | y << 8 | z.

Did you maybe apply it with svn patch and lost all the file permissions? ... well, no, then you wouldn't be able to read it :D

Ah, I see the comment in the bug now - yes, if Linux uses shifts we should too. It would be good to put a reference in the commit that mentions the Linux macro/etc. that calculates it though.

Looks good now. -- You can commit it, if the maintainer is fine with it too.

In D15952#337607, @cem wrote:

Ed, can you explain it in a little more detail?

I can't commit this one:

• Rebased against recent head
• Only add targets which are currently supported
• Added check for at least one enabled target
• Use for loop instead of individual target checks

Add missing \n !! :S

With @kib's requested style fix.

In D15931#337328, @ben.widawsky_intel.com wrote:

Hmmm, I was more wondering if acpi_print_gas() simply needed updating in general for newer GAS parsing in newer ACPI revisions. If instead this is a specific hack just for this table then I don't think acpi_print_gas() needs adjusting. It might be nice to recognize the special case and print it as "MSR=" or some such if that isn't a pain to do. However, if that involves a lot of mess and manual GAS parsing code then the current approach is probably fine.

The problem is, I don't know. I'd venture to guess that something somewhere uses 0x7f for address space id, and 64 for bit width, but it doesn't mean it's an MSR. If it *does* then that would be a great addition that I'm happy to add.

Could you add some MOVED entries too?

net-p2p/transmission-qt4|net-p2p/transmission-qt@qt4|...

Re-patching.

It looks fine to me, I will wait some time for John opinion.

Thanks -- if Intel would sell those EXL, that would make sense 8-)

In D15910#337582, @alc wrote:

1. In regards to pmap_enter(), we should aim to kill two birds with one stone. Recall the copy-on-write mapping bug that Kostik worked around in vm_fault(). I say worked around because the root cause is here in pmap_enter(). When the physical page mapped at va is changing, pmap_enter() should destroy the old mapping before creating the new one. Once pmap_enter() is restructured in this way, you can simply recycle the old mapping's PV entry.

In D15927#337347, @pi wrote:

Thanks -- will that be written down somewhere in the man page ? Who is selling EXL cards, because I've never found that ? And: What is LOM ?

Remove .desktop entry from pkg-plist. It will be added automatically

Yes. I would open a PR but if you get it would be nice. :-D

So, you're saying the we need testers for this configuration before we put it in the handbook as official instructions?