Page MenuHomeFreeBSD

jrtc27 (Jessica Clarke)
User

Projects

User Details

User Since
Jul 4 2018, 7:23 PM (133 w, 5 d)

Recent Activity

Today

jrtc27 updated the diff for D28264: Fix issues in past and present CheriBSD quarterly reports.

Manually pasted reduced-context diff to work around Phabricator's UTF-8-centric views

Tue, Jan 26, 1:02 AM
jrtc27 added a comment to D28264: Fix issues in past and present CheriBSD quarterly reports.

Hmph. Phabricator does not support ISO-8859-1 (their docs say so explicitly) so it balks on these files and treats them as binary. That's going to be fun. Anyway, here's the diff:

Tue, Jan 26, 12:51 AM
jrtc27 updated the diff for D28264: Fix issues in past and present CheriBSD quarterly reports.

Rebase against shiny new repo

Tue, Jan 26, 12:46 AM

Yesterday

jrtc27 edited reviewers for D28267: Create symlinks to host tools on non-FreeBSD hosts, added: freebsdphab-AX9_cmx.ietfng.org; removed: nwf20_cl.cam.ac.uk.
Mon, Jan 25, 2:31 PM
jrtc27 accepted D28267: Create symlinks to host tools on non-FreeBSD hosts.
Mon, Jan 25, 2:13 PM

Sun, Jan 24

jrtc27 added inline comments to D27803: Add a code example to cpuset(2) showing how to modify the affinity of the current process. Improve cross referencing..
Sun, Jan 24, 12:18 AM

Sat, Jan 23

jrtc27 requested review of D28317: localedef: Fix bootstrapping on Ubuntu 16.04.
Sat, Jan 23, 10:57 PM
jrtc27 updated the summary of D28315: bsd.compiler.mk: Detect distribution-provided GCC when executed as cc.
Sat, Jan 23, 9:08 PM
jrtc27 requested review of D28315: bsd.compiler.mk: Detect distribution-provided GCC when executed as cc.
Sat, Jan 23, 9:07 PM
jrtc27 committed R10:d6327ae8c11b: Fix cross-build support for Ubuntu 16.04 (authored by jrtc27).
Fix cross-build support for Ubuntu 16.04
Sat, Jan 23, 9:00 PM

Fri, Jan 22

jrtc27 added inline comments to D28212: linux: implement PTRACE_GET_SYSCALL_INFO.
Fri, Jan 22, 6:21 PM
jrtc27 added inline comments to D27988: Reserve gaps in syscall numbers for local use.
Fri, Jan 22, 6:10 PM
jrtc27 added a comment to D28267: Create symlinks to host tools on non-FreeBSD hosts.

"freezes when building failures on macOS" in the commit message needs fixing

Fri, Jan 22, 4:29 PM
jrtc27 added inline comments to D28233: Fix a few UBSan errors in bootstrap-tools.
Fri, Jan 22, 3:34 PM
jrtc27 added inline comments to D28233: Fix a few UBSan errors in bootstrap-tools.
Fri, Jan 22, 3:12 PM
jrtc27 retitled D28233: Fix a few UBSan errors in bootstrap-tools from Fix a few UBSan errors in boostrap-tools to Fix a few UBSan errors in bootstrap-tools.
Fri, Jan 22, 3:02 PM
jrtc27 added a comment to D28264: Fix issues in past and present CheriBSD quarterly reports.

Ah, I hadn't twigged that it was going read-only so far in advance of the migration. The error message is technically correct I guess, needs a doceng approval, and this kind of thing is a bit of a special case.

Yeah, it looks like doceng@ approval is required, because gjb@ just made a commit and that went through.

Will you be applying for approval for this, or should I?

Or are you just going to wait past the conversion and redo it, or should I?

Fri, Jan 22, 2:49 AM

Thu, Jan 21

jrtc27 added inline comments to D28233: Fix a few UBSan errors in bootstrap-tools.
Thu, Jan 21, 3:04 PM
jrtc27 added inline comments to D28226: riscv: add SBI system reset extension.
Thu, Jan 21, 3:01 PM
jrtc27 added inline comments to D28026: arm64: Improve DDB backtrace support.
Thu, Jan 21, 1:04 PM
jrtc27 updated the diff for D28026: arm64: Improve DDB backtrace support.

Rebase and address review comments

Thu, Jan 21, 1:04 PM
jrtc27 added a comment to D28264: Fix issues in past and present CheriBSD quarterly reports.

Don't know if I'm supposed to be able to push with a Reviewed by: + Approved by: debdrup, or if something just hates me, but I get "FATAL: VREF/APPROVERS-CHECK/doc: helper program exit status 65280", so could you please commit this for me?

This puzzled me, too, until I realized that it's past 02:00 UTC, which means the doc repo is read-only in preparation for the move to Hugo/AsciiDoctor, in accordance with Message-ID: <CAFwocyM9gA1iO2isXcDZTKRssF7xCbr=-iT8fPOsP_3Ctvf6tQ@mail.gmail.com>.

Admittedly, the error message is less than perfect.

Thu, Jan 21, 12:52 PM
jrtc27 added a comment to D28264: Fix issues in past and present CheriBSD quarterly reports.

Don't know if I'm supposed to be able to push with a Reviewed by: + Approved by: debdrup, or if something just hates me, but I get "FATAL: VREF/APPROVERS-CHECK/doc: helper program exit status 65280", so could you please commit this for me?

Thu, Jan 21, 3:19 AM
jrtc27 added inline comments to D27856: virtio: Add VirtIO PCI modern (V1) support.
Thu, Jan 21, 3:10 AM
jrtc27 updated the diff for D28264: Fix issues in past and present CheriBSD quarterly reports.

Fix unintended whitespace diff

Thu, Jan 21, 2:57 AM
jrtc27 requested review of D28264: Fix issues in past and present CheriBSD quarterly reports.
Thu, Jan 21, 2:36 AM
jrtc27 committed R10:85ad7f8da19f: virtio_mmio: Delete a stale #if 0'ed debug print (authored by jrtc27).
virtio_mmio: Delete a stale #if 0'ed debug print
Thu, Jan 21, 2:20 AM
jrtc27 added inline comments to D27856: virtio: Add VirtIO PCI modern (V1) support.
Thu, Jan 21, 2:12 AM
jrtc27 added inline comments to D27856: virtio: Add VirtIO PCI modern (V1) support.
Thu, Jan 21, 2:10 AM
jrtc27 added a comment to D28221: rtld: change a few const char* variables to bool.

The documentation for these says "When set to a nonempty string", and the GNU world does the same (e.g. see LD_TRACE_LOADED_OBJECTS=1 /bin/echo on a GNU/Linux system), so the strcmp shouldn't be added.

Thu, Jan 21, 2:05 AM
jrtc27 committed R10:513c5cd8276c: linux64: Don't pass unnecessary -S and -g to objcopy (authored by jrtc27).
linux64: Don't pass unnecessary -S and -g to objcopy
Thu, Jan 21, 1:57 AM
jrtc27 committed R10:5faeda903753: Rename i386's Linux ELF to Linux ELF32 (authored by jrtc27).
Rename i386's Linux ELF to Linux ELF32
Thu, Jan 21, 1:57 AM
jrtc27 closed D27740: linux64: Don't pass unnecessary -S and -g to objcopy.
Thu, Jan 21, 1:57 AM
jrtc27 closed D27647: Rename i386's Linux ELF to Linux ELF32.
Thu, Jan 21, 1:57 AM
jrtc27 committed R10:32cb85d0f1e8: Build VirtIO modules on all architectures (authored by jrtc27).
Build VirtIO modules on all architectures
Thu, Jan 21, 1:36 AM
jrtc27 closed D28058: Build VirtIO modules on all architectures.
Thu, Jan 21, 1:36 AM
jrtc27 closed D28073: virtio: Reduce boilerplate for device driver module definitions.
Thu, Jan 21, 1:15 AM
jrtc27 committed R10:633218ee4615: virtio: Reduce boilerplate for device driver module definitions (authored by jrtc27).
virtio: Reduce boilerplate for device driver module definitions
Thu, Jan 21, 1:15 AM
jrtc27 closed D28070: virtio_mmio: Fix V1 device probing spec conformance (section 4.2.3.1.1).
Thu, Jan 21, 1:15 AM
jrtc27 committed R10:be79a2c60fec: virtio_mmio: Fix V1 device probing spec conformance (section 4.2.3.1.1) (authored by jrtc27).
virtio_mmio: Fix V1 device probing spec conformance (section 4.2.3.1.1)
Thu, Jan 21, 1:15 AM
jrtc27 committed R10:0e72f2c54186: virtio_mmio: Fix a style(9) issue (authored by jrtc27).
virtio_mmio: Fix a style(9) issue
Thu, Jan 21, 1:14 AM
jrtc27 added a comment to D28026: arm64: Improve DDB backtrace support.

@gnn You're currently a blocking reviewer on this

Thu, Jan 21, 1:08 AM

Wed, Jan 20

jrtc27 added inline comments to D28219: Restrict supported alignment for malloc_domainset_aligned(9) to PAGE_SIZE..
Wed, Jan 20, 5:04 PM
jrtc27 added inline comments to D28219: Restrict supported alignment for malloc_domainset_aligned(9) to PAGE_SIZE..
Wed, Jan 20, 5:03 PM
jrtc27 added inline comments to D28219: Restrict supported alignment for malloc_domainset_aligned(9) to PAGE_SIZE..
Wed, Jan 20, 3:22 AM

Tue, Jan 19

jrtc27 added inline comments to D28226: riscv: add SBI system reset extension.
Tue, Jan 19, 4:26 PM
jrtc27 added inline comments to D28226: riscv: add SBI system reset extension.
Tue, Jan 19, 4:15 PM
jrtc27 added inline comments to D28070: virtio_mmio: Fix V1 device probing spec conformance (section 4.2.3.1.1).
Tue, Jan 19, 5:26 AM

Mon, Jan 18

jrtc27 added inline comments to D28219: Restrict supported alignment for malloc_domainset_aligned(9) to PAGE_SIZE..
Mon, Jan 18, 9:55 PM
jrtc27 added a comment to D28220: rtld: Always check LD_64_/LD_32_ environment variables.

So one question is: how far makes sense to take this? Should rtld always read the ABI-specific libmap+hints and search in lib32/lib64? Only handling the ABI-specific environment variables is inconsistent.

Mon, Jan 18, 5:59 PM
jrtc27 added inline comments to D28220: rtld: Always check LD_64_/LD_32_ environment variables.
Mon, Jan 18, 5:36 PM

Sat, Jan 16

jrtc27 added inline comments to D27803: Add a code example to cpuset(2) showing how to modify the affinity of the current process. Improve cross referencing..
Sat, Jan 16, 4:37 PM

Thu, Jan 14

jrtc27 added a comment to D28054: dtrace: Fix RISC-V user stack unwinder.

Looking at other implementations, I believe oldfp should be updated on each loop iteration.

Otherwise, the change seems correct to me, assuming the discussed issues will be addressed separately. I'd like to see the build fix committed soon.

Thu, Jan 14, 2:42 PM
jrtc27 added a comment to D28091: Add -NODEBUG variant of GENERIC-MMCCAM kernel configuration..

We could split out the -NODEBUG options to std.nodebug then include that from both here and GENERIC-NODEBUG

Thu, Jan 14, 10:29 AM

Tue, Jan 12

jrtc27 added a comment to D27856: virtio: Add VirtIO PCI modern (V1) support.

Rebasing this on top of D28073 would help to reduce the diff (provided you're still happy with the concept, but if so it'd be good to land the cleanup first IMO before all the new code comes in).

Tue, Jan 12, 7:12 AM

Mon, Jan 11

jrtc27 added a comment to D28091: Add -NODEBUG variant of GENERIC-MMCCAM kernel configuration..

Hm, my instinct would be to make it include GENERIC-MMCCAM instead and then turn of debugging, especially given the name.

Mon, Jan 11, 3:07 PM

Sun, Jan 10

jrtc27 added a comment to D28054: dtrace: Fix RISC-V user stack unwinder.

Ok, so *without* this patch I see a fatal page fault for a small integer address, but *with* this patch I see it attempting (but failing due to the buggy dtrace_fuword64 implementation) to read from a sensible address:

Sun, Jan 10, 6:09 AM

Sat, Jan 9

jrtc27 added a comment to D28054: dtrace: Fix RISC-V user stack unwinder.
In D28054#627282, @kp wrote:

What's 0xffffffc0d282d870? My guess is it's dtrace_fuword64_nocheck;

That appears to be the case, yes. dtrace.ko is loaded at 0xffffffc0d2808000, dtrace_fuword64_nocheck is 0x25870 into the module, so that's at 0xFFFFFFC0D282D870.

Sat, Jan 9, 11:38 PM
jrtc27 updated the summary of D28031: virtio: Use a common class name between virtio_mmio and virtio_pci.
Sat, Jan 9, 10:13 PM
jrtc27 updated the diff for D28031: virtio: Use a common class name between virtio_mmio and virtio_pci.

Rebased on top of D28073

Sat, Jan 9, 10:13 PM
jrtc27 requested review of D28073: virtio: Reduce boilerplate for device driver module definitions.
Sat, Jan 9, 10:05 PM
jrtc27 requested review of D28070: virtio_mmio: Fix V1 device probing spec conformance (section 4.2.3.1.1).
Sat, Jan 9, 9:35 PM
jrtc27 added a comment to D28054: dtrace: Fix RISC-V user stack unwinder.
In D28054#627033, @kp wrote:

That at the very least fixes the build error, so on those grounds alone we should commit this.

However, I do see a panic with dtrace -n 'syscall:freebsd:write:entry { ustack(); }'. I've not yet dug into it to see if it's a direct result of this. I also see that stack() doesn't appear to work and I'm pretty sure that it used to.

root@pkgbuilder:~ # dtrace -n 'syscall:freebsd:write:entry { ustack(); }' &
[1] 718
root@pkgbuilder:~ # dtrace: description 'syscall:freebsd:write:entry ' matched 1 probe
t[0] == 0x0000000000000007
t[1] == 0xffffffc0d282e4bc
t[2] == 0x000000000000000a
t[3] == 0xffffffc0002ccb52
t[4] == 0x0000000040941600
t[5] == 0xfffffffffffffe93
t[6] == 0x0a3d70a3d70a3d71
s[0] == 0x0000000000000013
s[1] == 0x0000000000000011
s[2] == 0xffffffc0d2a00018
s[3] == 0x0000000000000014
s[4] == 0x0000000000000011
s[5] == 0x0000000000000001
s[6] == 0xffffffc0d2807000
s[7] == 0x0000000000000001
s[8] == 0x0000004000000001
s[9] == 0x0000000040242566
s[10] == 0xffffffc0d2a00020
s[11] == 0xffffffd13ccff600
a[0] == 0x0000000000000009
a[1] == 0xffffffc0d2807000
a[2] == 0xffffffc0764a0c50
a[3] == 0x0000000000000000
a[4] == 0xffffffc0d2807000
a[5] == 0x0000000000004ed6
a[6] == 0xffffffd003fac000
a[7] == 0xffffffc0d2a00000
ra == 0xffffffc0d2816fba
sp == 0xffffffc0764a0830
gp == 0x0000000000000001
tp == 0x0000000000000000
sepc == 0xffffffc0d282d870
sstatus == 0x0000000000004100
panic: Fatal page fault at 0xffffffc0d282d870: 0x00000000000009
cpuid = 0
time = 1610206153
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_fetch_ksymtab() at db_fetch_ksymtab+0x170
kdb_backtrace() at kdb_backtrace+0x2c
vpanic() at vpanic+0x144
panic() at panic+0x26
do_trap_supervisor() at do_trap_supervisor+0x504
do_trap_supervisor() at do_trap_supervisor+0x64
cpu_exception_handler_supervisor() at cpu_exception_handler_supervisor+0x68
--- exception 13, tval = 0x9
KDB: enter: panic
[ thread pid 710 tid 100047 ]
Stopped at      kdb_enter+0x4c: sd      zero,0(a0)
db>
Sat, Jan 9, 8:29 PM
jrtc27 added a comment to D28058: Build VirtIO modules on all architectures.
In D28058#627077, @imp wrote:

Does this survive universe? mips has no virtualization support at all, last I checked... A quick peek at virtio suggests that it's entirely platform neutral...

Sat, Jan 9, 7:29 PM
jrtc27 requested review of D28058: Build VirtIO modules on all architectures.
Sat, Jan 9, 6:30 AM
jrtc27 removed a reviewer for D28054: dtrace: Fix RISC-V user stack unwinder: mjg.
Sat, Jan 9, 2:48 AM
jrtc27 updated the summary of D28054: dtrace: Fix RISC-V user stack unwinder.
Sat, Jan 9, 2:47 AM
jrtc27 updated subscribers of D28054: dtrace: Fix RISC-V user stack unwinder.
In D28054#626850, @mjg wrote:

Drop me from 'reported by'.

I have no basis to comment on the patch.

Sat, Jan 9, 2:47 AM
jrtc27 requested review of D28054: dtrace: Fix RISC-V user stack unwinder.
Sat, Jan 9, 2:32 AM

Fri, Jan 8

jrtc27 added inline comments to D28026: arm64: Improve DDB backtrace support.
Fri, Jan 8, 9:28 PM
jrtc27 added inline comments to D28026: arm64: Improve DDB backtrace support.
Fri, Jan 8, 9:24 PM
jrtc27 added inline comments to D27719: arm64: don't pass user trapframe to kdb_trap().
Fri, Jan 8, 7:17 PM
jrtc27 added inline comments to D27719: arm64: don't pass user trapframe to kdb_trap().
Fri, Jan 8, 7:01 PM
jrtc27 added inline comments to D28026: arm64: Improve DDB backtrace support.
Fri, Jan 8, 6:47 PM
jrtc27 updated the summary of D28026: arm64: Improve DDB backtrace support.
Fri, Jan 8, 6:40 PM
jrtc27 added a comment to D28026: arm64: Improve DDB backtrace support.

though FAR is not saved in the trapframe so we cannot print it

I think we at least print it before calling panic() when it makes sense to do so, so this doesn't seem like a problem.

Fri, Jan 8, 6:35 PM
jrtc27 added a comment to D28031: virtio: Use a common class name between virtio_mmio and virtio_pci.

<snip>

As a separate thing I would like to update virtio_mmio to return ENXIO when probing instances with no device rather than creating pointless empty device instances as it's not particularly useful (and the AArch64 QEMU virt machine has a particularly large number of MMIO devices available for whatever reason which leads to rather silly device numbers).

I think it is useful that a transport driver has been attached. Also my recollection when I original did it this way for PCI, is that this is needed for if the device (network, block, etc) module is later loaded. In the ensuing decade, devctl has appeared, but for driver development it is nice to just be able to load/unload the module for hack/test/hack.

Oh I didn't mean if a driver wasn't available, I meant if the device ID is 0. If it's non-zero but no driver's available that would still attach ready for if the driver gets loaded later, either automatically by devd or manually by the user.

ENXIO is fine for MMIO DeviceId of 0x0. Currently the MMIO driver fails to conform to section 4.2.3.1.1 w.r.t. to this.

Fri, Jan 8, 6:15 PM
jrtc27 added a comment to D28031: virtio: Use a common class name between virtio_mmio and virtio_pci.

For reference, this is what an AArch64 QEMU virt machine shows in devinfo when using PCI:

root@:/ # devinfo
nexus0
  acpi0
    cpu0
    uart0
    virtio0
    virtio1
    virtio2
    virtio3
    virtio4
    virtio5
    virtio6
    virtio7
    virtio8
    virtio9
    virtio10
    virtio11
    virtio12
    virtio13
    virtio14
    virtio15
    virtio16
    virtio17
    virtio18
    virtio19
    virtio20
    virtio21
    virtio22
    virtio23
    virtio24
    virtio25
    virtio26
    virtio27
    virtio28
    virtio29
    virtio30
    virtio31
    pcib0
      pci0
        hostb0
        virtio32
          vtblk0
        virtio33
          vtnet0
        virtio34
    pci_link0
    pci_link1
    pci_link2
    pci_link3
    acpi_sysresource0
    acpi_button0
    psci0
    gic0
    generic_timer0
  cryptosoft0
  efirtc0
root@:/ # devinfo -p vtblk0
vtblk0 virtio32 pci0 pcib0 acpi0 nexus0
root@:/ # devinfo -p vtblk0 -v
vtblk0 pnpinfo vendor=0x00001af4 device=0x1001 subvendor=0x1af4 device_type=0x00000002
 virtio32 pnpinfo vendor=0x1af4 device=0x1001 subvendor=0x1af4 subdevice=0x0002 class=0x010000 at slot=1 function=0 dbsf=pci0:0:1:0
 pci0
 pcib0 pnpinfo _HID=PNP0A08 _UID=0 _CID=PNP0A03 at handle=\_SB_.PCI0
 acpi0
 nexus0 pnpinfo nexus

As a separate thing I would like to update virtio_mmio to return ENXIO when probing instances with no device rather than creating pointless empty device instances as it's not particularly useful (and the AArch64 QEMU virt machine has a particularly large number of MMIO devices available for whatever reason which leads to rather silly device numbers).

I think it is useful that a transport driver has been attached. Also my recollection when I original did it this way for PCI, is that this is needed for if the device (network, block, etc) module is later loaded. In the ensuing decade, devctl has appeared, but for driver development it is nice to just be able to load/unload the module for hack/test/hack.

Fri, Jan 8, 6:00 PM
jrtc27 added a comment to D28031: virtio: Use a common class name between virtio_mmio and virtio_pci.

For reference, this is what an AArch64 QEMU virt machine shows in devinfo when using PCI:

Fri, Jan 8, 5:23 PM
jrtc27 added a comment to D28031: virtio: Use a common class name between virtio_mmio and virtio_pci.

This would change the device names in places like devinfo, devctl, vmstat, etc, correct?

Fri, Jan 8, 5:20 PM
jrtc27 added inline comments to D28031: virtio: Use a common class name between virtio_mmio and virtio_pci.
Fri, Jan 8, 12:02 AM
jrtc27 added a comment to D28031: virtio: Use a common class name between virtio_mmio and virtio_pci.

@bryanv Does this seem sensible to you? It's a cleanup/simplification I've been meaning to do for a while as the current situation is a bit silly, unless there's a reason you can think of why this is a bad idea?

Fri, Jan 8, 12:00 AM

Thu, Jan 7

jrtc27 requested review of D28031: virtio: Use a common class name between virtio_mmio and virtio_pci.
Thu, Jan 7, 11:59 PM
jrtc27 accepted D28030: efidev: remove EFIIOC_GET_TABLE ioctl.

\o/

Thu, Jan 7, 10:11 PM
jrtc27 added inline comments to D28026: arm64: Improve DDB backtrace support.
Thu, Jan 7, 6:16 PM
jrtc27 requested review of D28026: arm64: Improve DDB backtrace support.
Thu, Jan 7, 6:14 PM

Mon, Jan 4

jrtc27 added inline comments to D27803: Add a code example to cpuset(2) showing how to modify the affinity of the current process. Improve cross referencing..
Mon, Jan 4, 1:57 AM
jrtc27 added inline comments to D27766: Various changes to DTrace FBT to avoid crashed on FreeBSD/arm64..
Mon, Jan 4, 1:53 AM · arm64, DTrace

Thu, Dec 31

jrtc27 added a comment to D27855: Summary: Revert prior VirtIO "V1" network support to simplify upcoming V1 changes.

@grehan Thanks :)

Thu, Dec 31, 4:11 AM
jrtc27 added a comment to D27855: Summary: Revert prior VirtIO "V1" network support to simplify upcoming V1 changes.

Everything those commits did is necessary for V1. It's not sufficient per the spec, granted, but having the commits to support _some_ V1 implementations is strictly better than supporting _none_. If you have commits to introduce the missing parts of the V1 feature negotiation sequence then add them, but don't revert what's already there only to reintroduce it later. Otherwise you will break TinyEMU and the FPGA-based system we have built atop its VirtIO implementation.

It is so wrong and incomplete that I have zero interest in trying to sort out the merge conflicts in the patches series I have for V1 support. This is so far away from _some_ V1 support that it is effectively _none_. Fix TinyEMU: it would appear it otherwise supports legacy but has a bug that requires VIRTIO_F_VERSION_1 to be negotiated.

That is grossly incorrect. There are a couple of deficiencies, and as I just said, everything I did is required for V1.

No, it is not just "a couple". I would advise you to read the VirtIO V1 spec. Or look at D27856 that starts to add V1 support. The OASIS TC did not spend years to develop a V1 specification that just ... negotiates VIRTIO_F_VERSION_1 on top of legacy VirtIO. Doing so here is so far from any V1 support that it is wrong pointless.

Thu, Dec 31, 3:23 AM
jrtc27 added a comment to D27855: Summary: Revert prior VirtIO "V1" network support to simplify upcoming V1 changes.

Everything those commits did is necessary for V1. It's not sufficient per the spec, granted, but having the commits to support _some_ V1 implementations is strictly better than supporting _none_. If you have commits to introduce the missing parts of the V1 feature negotiation sequence then add them, but don't revert what's already there only to reintroduce it later. Otherwise you will break TinyEMU and the FPGA-based system we have built atop its VirtIO implementation.

It is so wrong and incomplete that I have zero interest in trying to sort out the merge conflicts in the patches series I have for V1 support. This is so far away from _some_ V1 support that it is effectively _none_. Fix TinyEMU: it would appear it otherwise supports legacy but has a bug that requires VIRTIO_F_VERSION_1 to be negotiated.

Thu, Dec 31, 12:07 AM

Wed, Dec 30

jrtc27 added inline comments to D27857: Add VirtIO modern support to virtqueue.
Wed, Dec 30, 11:53 PM
jrtc27 added inline comments to D27856: virtio: Add VirtIO PCI modern (V1) support.
Wed, Dec 30, 11:51 PM
jrtc27 added a comment to D27855: Summary: Revert prior VirtIO "V1" network support to simplify upcoming V1 changes.

Everything those commits did is necessary for V1. It's not sufficient per the spec, granted, but having the commits to support _some_ V1 implementations is strictly better than supporting _none_. If you have commits to introduce the missing parts of the V1 feature negotiation sequence then add them, but don't revert what's already there only to reintroduce it later. Otherwise you will break TinyEMU and the FPGA-based system we have built atop its VirtIO implementation.

Wed, Dec 30, 11:32 PM

Sun, Dec 27

jrtc27 added inline comments to D27669: efirt: enter runtime environment to deref efi_cfgtbl.
Sun, Dec 27, 7:29 PM

Dec 23 2020

jrtc27 requested review of D27740: linux64: Don't pass unnecessary -S and -g to objcopy.
Dec 23 2020, 5:02 PM

Dec 21 2020

jrtc27 added a comment to D27699: Fix the types in some Linux syscall definitions.

LGTM. I wonder why we ended up with these - in the case of itimerspec, sigevent etc. were the structs identical?

Dec 21 2020, 5:47 PM
jrtc27 requested review of D27699: Fix the types in some Linux syscall definitions.
Dec 21 2020, 5:28 PM

Dec 18 2020

jrtc27 closed D27670: usb: Replace ITUNERNET vendor with MICROCHIP and improve product names.
Dec 18 2020, 11:32 PM
jrtc27 committed rS368774: usb: Replace ITUNERNET vendor with MICROCHIP and improve product names.
usb: Replace ITUNERNET vendor with MICROCHIP and improve product names
Dec 18 2020, 11:32 PM