mirror of
https://git.proxmox.com/git/proxmox
synced 2025-05-02 21:01:24 +00:00
8841b389e3
In the uncommon circumstance that calls to `read()` end up reading any number of bytes other than 4096, the subsequently read bytes become misaligned, causing blocks of zeroes to be written unnecessarily. To illustrate, imagine you have a 12KiB file: [x][x][x][x][ ][ ][ ][ ][x][x][x][x] └──4096──┘ └──4096──┘ └──4096──┘ The first and last block are filled with some data, whereas the middle block is empty and will therefore result in only zeroes being read. In order for the empty block to be skipped with `seek()`, the entire buffer has to be filled with zeroes. If, for example, the first `read()` ends up putting only 3KiB into the buffer, the empty block in the middle won't be detected properly, as the buffer will now always contain some data. What results are four misaligned reads: [x][x][x][x][ ][ ][ ][ ][x][x][x][x] ├─────┘ ├────────┘ ├────────┘ │ 1 2 3 4 This is fixed by ensuring chunks of 4KiB are always read into the buffer, except when the last block is truncated. In order to prevent frequent small reads, the incoming reader is also buffered via `io::BufReader`. Signed-off-by: Max Carrara <m.carrara@proxmox.com> |
||
|---|---|---|
| .cargo | ||
| proxmox-api-macro | ||
| proxmox-apt | ||
| proxmox-async | ||
| proxmox-auth-api | ||
| proxmox-borrow | ||
| proxmox-client | ||
| proxmox-compression | ||
| proxmox-http | ||
| proxmox-http-error | ||
| proxmox-human-byte | ||
| proxmox-io | ||
| proxmox-lang | ||
| proxmox-ldap | ||
| proxmox-login | ||
| proxmox-metrics | ||
| proxmox-notify | ||
| proxmox-openid | ||
| proxmox-rest-server | ||
| proxmox-router | ||
| proxmox-schema | ||
| proxmox-section-config | ||
| proxmox-serde | ||
| proxmox-shared-memory | ||
| proxmox-sortable-macro | ||
| proxmox-subscription | ||
| proxmox-sys | ||
| proxmox-tfa | ||
| proxmox-time | ||
| proxmox-uuid | ||
| .gitignore | ||
| build.sh | ||
| bump.sh | ||
| Cargo.toml | ||
| Makefile | ||
| README.rst | ||
| rustfmt.toml | ||
Local cargo config
==================
This repository ships with a ``.cargo/config`` that replaces the crates.io
registry with packaged crates located in ``/usr/share/cargo/registry``.
A similar config is also applied building with dh_cargo. Cargo.lock needs to be
deleted when switching between packaged crates and crates.io, since the
checksums are not compatible.
To reference new dependencies (or updated versions) that are not yet packaged,
the dependency needs to point directly to a path or git source.
Steps for Releases
==================
- Run ./bump.sh <CRATE> [patch|minor|major|<VERSION>]
-- Fill out changelog
-- Confirm bump commit
- Build packages with `make deb`.
-- Don't forget to commit updated d/control!
Adding Crates
=============
1) At the top level:
- Generate the crate: ``cargo new --lib the-name``
- Sort the crate into ``Cargo.toml``'s ``workspace.members``
2) In the new crate's ``Cargo.toml``:
- In ``[package]`` set:
authors.workspace = true
license.workspace = true
edition.workspace = true
exclude.workspace = true
repository.workspace = true
- Add a meaningful ``description``
- Copy ``debian/copyright`` and ``debian/debcargo.toml`` from another subcrate.
Adding a new Dependency
=======================
1) At the top level:
- Add it to ``[workspace.dependencies]`` specifying the version and any
features that should be enabled throughout the workspace
2) In each member's ``Cargo.toml``:
- Add it to the desired dependencies section with ``workspace = true`` and no
version specified.
- If this member requires additional features, add only the extra features to
the member dependency.
Updating a Dependency's Version
===============================
1) At the top level:
- Bump the version in ``[workspace.dependencies]`` as desired.
- Check for deprecations or breakage throughout the workspace.
Notes on Workspace Inheritance
==============================
Common metadata (like authors, license, ..) are inherited throughout the
workspace. If new fields are added that are identical for all crates, they
should be defined in the top-level ``Cargo.toml`` file's
``[workspace.package]`` section, and inherited in all members explicitly by
setting ``FIELD.workspace = true`` in the member's ``[package]`` section.
Dependency information is also inherited throughout the workspace, allowing a
single dependency specification in the top-level Cargo.toml file to be used by
all members.
Some restrictions apply:
- features can only be added in members, never removed (this includes
``default_features = false``!)
- the base feature set at the workspace level should be the minimum (possibly
empty!) set required by all members
- workspace dependency specifications cannot include ``optional``
- if needed, the ``optional`` flag needs to be set at the member level when
using a workspace dependency