The parent is the pci or platform device that firmware knows about.
The `drmfb' device is more of a fictitious invention of the drm stack
that exists for the convenience of the genfb abstraction which needs
device_private to be a struct genfb_softc.
Let's see if this does any better than the last attempt to rework the
logic here.
that are documented to update this field.
Exceptions are fcti{w,d}{,z}; FPSCR[FPRF] becomes undefined,
according to Power ISA. We do not overwrite this field for
these insns at the moment.
pktq_barrier() ensures that all packets enqueued before the barrier have
been dequeued before the barrier returns. However, previously, pktq_dequeue()
would return NULL when a barrier marker was encountered. If there were
packets queued up behind the marker and no additional softint were scheduled
for the pktqueue, those packets would end up stranded. pktq_dequeue() now
continues to the next slot after the marker, ensuring that processing can
continue after the barrier has been signaled.
Basically, in PVH mode (where XENFEAT_auto_translated_physmap is enabled),
the hypervisor will not map foreing ressources in our virtual address
space for us. Instead, we have to pass it an address in our physical
address space (but not mapped to some RAM) where the ressource will show up
and then enter this PA in pour page table.
For this, introduce xenmem_* which manage the PA space. In PVH mode this
is just allocated from the iomem_ex extent.
With this, I can start a PV domU, and the guest's kernel boots (and
the console works). It hangs because the backend driver can't map the
frontend ressources (yet).
Note that, per https://xenbits.xen.org/docs/unstable/support-matrix.html,
dom0 PVH support is still considered experimental by Xen.
Also print the possible owner in ddb/crash `show lock' even if the
kernel is built without LOCKDEBUG.
Output may not be as pretty before with two neatly aligned columns,
but that can be changed; for now the value of having the symbols
printed instead of just obscure hex addresses (which one's an lwp
address and which one's a code pointer? can never remember!) should
outweigh the prettiness temporarily lost.
This way they match the mtree and make sense and don't cause editors
to ask to override read-only files when editing them.
Exception: Not sure /etc/bluetooth/protocols makes as much sense to
edit, but the mtree says 644, so if you want to change it, make sure
to change it in both places -- Makefile and mtree.
XXX pullup-8
XXX pullup-9
Previously we would:
1. Install /root/.cshrc and /root/.profile with mode FILESMODE=644 as
requested in src/etc/root/Makefile and as echoed in
/etc/mtree/special.
2. Create hard links at /.cshrc and /.profile through CONFIGLINKS.
3. Because LINKSMODE was unset and defaults to NOBINMODE=444, change
the mode to 444.
This scenario is confusing, and mtree objects to it, which is bad for
warning fatigue in a security-relevant mechanism. (There are also
several other files mtree objects to out of the box -- we should fix
those too.)
With this change we install the links with the same mode as the
original files, in agreement with the mtree. The files, .cshrc and
.profile, are intended to be editable configuration files, so 644
makes sense while 444 makes no sense and gets in the way of editors
like vi.
Discussed on tech-userlevel:
https://mail-index.netbsd.org/tech-userlevel/2022/08/29/msg013498.html
XXX pullup-8
XXX pullup-9
- Treat 64-bit integer correctly for fctid{,z}.
- Respect round mode specified by FPSCR[RN].
XXX
- Set FPSCR[FR] and [FI] appropriately.
- Also set FPSCR[FPRF]?
- fctid{,z} traps on powerpc32 (confirmed on 603e and G4).
The first time each key is verified, if verification fails, we chuck
the failed key and try again with passphrase re-entry.
But if a key has already been verified, and verification fails,
assume something is wrong with the disk and fail.
bouyer