Rather than excplicitly referencing ip_pktq and ip6_pktq in if_detach(),
instead add all pktqueues to a global list. This list is then used in
the new pktq_ifdetach() function to issue a barrier on all pktqueues.
Note that the performance of this list is not critical; it will seldom
be accessed (then pktqueues are created/destroyed and when network
interfaces are detached), and so a simple synchronization strategy using
a rwlock is sufficient.
calls; pktq_barrier() doesn't remove packets from the queue, it waits
for the packets enqueued before the barrier to drain. This, in turn,
may cause the protocols to gain additional references to the interface
that's detaching. By draining the queues first, we ensure that no
additional references will be taken after calling pr_purgeif().
Provide a new pktq_sysctl_setup() function that attaches standard
pktq sysctl nodes below a specified parent node, with either a
fixed node ID or CTL_CREATE to dynamically assign node IDs. Make
all of the sysctl handlers private to pktqueue.c, and remove the
INET- and INET6-specific pktqueue sysctl code from net/if.c.
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
nakayama