[continued from previous message]
These new features imply that the mac_do(4) module is able to apply credentials
change at once, since the allowed final credentials depend on the initial ones
through the configured rules. The traditional userland interface (e.g., setuid
(2), setuid(2), setgroups(2), etc.) is at odds with this requirement as it
necessitates multiple calls to reach the desired final credentials, making the
process pass by several successive states that themselves may not be allowed by
mac_do(4)'s rules. We overcome this limitation by introducing a new system
call, setcred(2), which allows to request arbitrary transitions of credentials
at once. Beside its usefulness in conjunction with mac_do(4), it has the
benefit of simplifying coding of credentials change in userland. Since it is
also extensible, it may have the potential to be adopted later by other
systems.
Pre-requisite changes are currently under review (see in particular revisions
D46886 to D46889 and D46896 to D46923). The bulk of changes in mac_do(4)/mdo(1)
proper will soon be pushed under review as well. An older version of the full
series can be seen on GitHub.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━
Scheduling Priorities: 256-queue Runqueues Sub-Project
Contact: Olivier Certner
The goal of the 256-queue runqueues sub-project is to fix FreeBSD’s POSIX
compliance in that different priority levels in the SCHED_FIFO or SCHED_RR
scheduling classes must lead to immediate preemption by threads having higher
priority. It is part of the bigger scheduling priorities revamp project aiming
at rationalizing FreeBSD scheduling interfaces, including having consistent
rtprio(2) and POSIX interface behaviors (where it makes sense), enhancing POSIX
compliance, removing duplicate code and fixing existing bugs, and enhancing the
non-standard parts both for better control and security. Expected benefits are
increased usage of FreeBSD as a soft real-time platform, e.g., for video and
audio processing in casual desktop uses to professional settings. Readers
interested in this topic are invited to consult AsiaBSDCon 2024’s paper and
EuroBSDCon 2024’s slides for a wider view, and to contact me for questions,
feedbacks or discussions.
Currently, priority levels specified either through the prio field of struct
rtprio (rtprio(2) interface) or the sched_priority one of struct sched_param,
for real-time scheduling classes (RTP_PRIO_FIFO and RTP_PRIO_REALTIME for the
former, SCHED_FIFO and SCHED_RR for the latter) as well as idle-time ones
(RTP_PRIO_IDLE), are conflated as follows: Each priority level that has the
same quotient when divided by 4 is internally treated the same. In particular,
threads being in the same such equivalence class but having higher priority
will not preempt other threads in the same class, violating POSIX expectations
for SCHED_FIFO and SCHED_RR.
To remedy this situation, we have chosen an impacting internal change on the
number of queues per runqueue, and defer to the above-mentioned EuroBSDCon
2024’s slides for more details.
The switch to 256-queue runqueues having non-trivial impacts on the ULE
scheduler, we have been analyzing it and tuning the scheduler to preserve its
previous behavior with respect to anti-starvation and the effect of nice
values. With the goal to perform further testing, we have revived Jeff
Roberson’s initial ULE’s test tool, called late (currently available on
GitHub
).
All the modifications made as part of this sub-project are currently under
review, starting with Phabricator’s review D45387 (click on the "Stack" tab
to
see the full series of reviews).
In the course of this project, we have noticed that the effect of nice values
is especially weak, and consequently have produced experimental patches to make
their effect stronger. However, it is not clear at this point whether we can
increase their effect satisfactorily enough in the current ULE setting.
We have also started another scheduler project about adapting ULE to hybrid
architectures, which might also trigger more drastic scheduler changes.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━
Wireless Update
Links:
Categorised Wireless Problem Reports URL: https://bugs.freebsd.o
g/bugzilla/showdependencytree.cgi?id=277512&hide_resolved=0
Contact: Bjoern A. Zeeb
Contact: The FreeBSD wireless mailing list
The ongoing wireless efforts are trying to bring more support for recent
chipsets as well as newer standards.
With iwlwifi(4) and rtw88(4) being supported we received patches and initial
reports for rtw89 and ath10k working for some people. Additionally ath11k,
ath12k and various chipsets supported by mt76 are waiting for someone to find
the time to finish compat code, test and debug.
Work is ongoing to update drivers to Linux v6.11 using the now bootstrapped
vendor branches, which should help maintenance a lot in the future. One
particular focus for this update is also to find ways to minimize
incompatibilities between wireless compat code versions in order to support
multiple Linux versions as needed.
After the native kern_malloc changes got committed, LinuxKPI is seeing ongoing
work for memory allocation to play better by the rules set out in Linux which
should help with DMA problems seen. There is further work pending to add
missing bus_dmamap_sync() calls.
There is work to support rtw88(4) SDIO devices (being tested on an r2s-plus)
and ongoing work to stabilize updated USB support which should start landing
once the driver updates have finished. Lastly there are more updates in the
queue to finish 11n support for LinuxKPI 802.11 compat code as well as
improving native net80211 code.
If you have questions or feedback please use the freebsd-wireless mailing list.
That way everyone will see, be able to join in, and the answers will be
publicly archived.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━
VirtIO Sockets and AF_VSOCK support
Links:
Source code URL: https://github.com/daniloegea/freebsd-src/tree/virtio_vsocks
Contact: Danilo Egea Gondolfo
The VirtIO Socket device is used to enable communication between guests and
host without networking. The AF_VSOCK protocol family enables it to be used
through the sockets API.
For the past many months I have been working on a guest driver for the VirtIO
Socket device and an implementation of the AF_VSOCK protocol family.
Originally, I wanted to get the lxd-agent daemon working on FreeBSD but the
communication with the LXD host daemon is done through VSOCKs. LXD is a nice
container and virtual machine manager based on Linux/KVM and my end goal is to
make FreeBSD a LXD first-class citizen.
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
