struct task_struct struct blk_plugcb_list mq_list per-process lock-free queue has constituent per-device request queues Generic Block Layer (GBL) BIO, struct bio I/O scheduler request queue

Xiangfei Ding 2024 Locks? What are those? // sync version use std::sync::{ Mutex, RwLock, MutexGuard, // * RwLockReadGuard, RwLockWriteGuard, // **

Abstract This guide proposes mechanical Edition 2024 migration strategies that we would like to implement in cargo fix. In summary, there are at least two ways to rewrite the rejected if lets each with its own merits and demerits. Lifetime rules under impact The most relevant rule under the impact that is currently running, even at Edition 2024, is that the temporaries created in evaluation are only dropped up until the end the most nested enclosing block or end of the statement in a block. One example would look like the following.

The crater run is executed by assuming the iflet_rescope feature gate throughout in order to assess the impact and proposals for lints, compiler assistance and migration support. Abstract This report serves as a response to this comment. The compile error in the ecosystem due to introduction of this rule share the same trait that it leverages the behaviour that temporary values stays alive until the end of the statement, when the if let is nested in. It occurs at places that it is more convenient and waives the necessity of extra variable bindings. Still given that, the crater only observed code under Case c, or embedding complex decision-making into a much bigger expression, that can be fixed by lifting the expiring expression into a binding because the type is not significant by the definition of the comment linked above. We hoped to catch violation that fails at runtime, or use and abuse of Mutex<()> so to speak. This crater run has not catched an instance of such in the wild. We do not exclude this possibility that between now and possible landing of this rule. One may attempt to do so right after publication of this piece but we probably should develop a lint against this practice. Build failure cases

2024-04-04 Temporary lifetimesRFC needs to be approvedhttps://github.com/rust-lang/rfcs/pull/3606/ Implementation work super let change lifetimes for temporaries in tail expressions <-- edition dependentmigration? plus mara's PR

lshr exact issue ; *** IR Dump After SROAPass on _ZN4core5slice29_$LT$impl$u20$$u5b$T$u5d$$GT$9as_chunks17h9af37f4407b2f595E *** ; Function Attrs: inlinehint nonlazybind uwtable define internal void @"_ZN4core5slice29_$LT$impl$u20$$u5b$T$u5d$$GT$9as_chunks17h9af37f4407b2f595E"(ptr noalias nocapture noundef sret({ { ptr, i64 }, { ptr, i64 } }) align 8 dereferenceable(32) %0, ptr noalias noundef nonnull readonly align 8 %1, i64 noundef %2, ptr noalias noundef readonly align 8 dereferenceable(24) %3) unnamed_addr #0 { %5 = udiv i64 %2, 4 %6 = mul i64 %5, 4 %7 = icmp ule i64 %6, %2 br i1 %7, label %9, label %8 8: ; preds = %4

Marigold values developer and user experiences when it comes to Tezos ecosystem. We are very excited about the upcoming SORU announcement and have started our pilot programme to develop kernels on top of SORU. Here we would like to share our thoughts. Developer experience Software development kit (SDK) SORU has a well-documented Rust SDK. Although there are rough edges in APIs, we have listed them as issue tickets in Pistachio repository and we are progressively proposing the improvements and implementing them. Observability SORU kernels at the moment must be run on top of SORU nodes which interpret the kernels. However, kernel execution mostly remain silent. There is a lack of venue to observe the progress of the kernel execution, logging and error reporting. From the point of view of operation and engineering, this poses a major challenge in tracking and identifying potential problems. We would like to propose the following improvements:

Ticket transfer Tickets are important. On Tezos blockchain, they can be used as non-fungible tokens in smart contracts and smart rollups. There has been an overhaul of the ownership system of Tezos tickets in the latest protocol proposal. In this blog post, we will demonstrate how tickets can be transferred between different entities on the Tezos blockchain in the new proposal. From an originated contract to an implicit account Naturally, the lifecycle of a ticket starts from construction of it by a Tezos smart contract. It may be held by an implicit account, like a promise to a service to a person behind the implicit account. To "hand out" this ticket, the contract just needs to construct a contract (ticket content_ty) contract handle to the receiving implicit account, given that content_ty is the type of the ticket content. For instance, we may transfer a string ticket with the following instructions. # stack: address : <...>

Gas for Tezos protocol developers Every transaction comes with a cost attached called gas. Whenever you send a transaction, of various types of manager operation, you will mostly come across gas in the transaction receipt. It also appears in the wallet transaction interface, where it may ask you for a maximally allowable gas value for this transaction. For instance, you may see this if you submit a transaction through octez-client. This sequence of operations was run: Manager signed operations: From: [PUBLIC_KEY_HASH] .... snip .... Gas limit: 3689 <<<< snip >>>> Transaction:

Archlinux pacman -Syu wasi-libc wasi-compiler-rt wabt Installer in Rust src/lib.rs #![no_std] #[panic_handler]

Today we would like to announce an important change coming in your way. As part of our next protocol proposal, we will remove support for tickets of zero amount. Tickets of zero amount was previously allowed at the introduction of tickets initially. However, as Tezos protocol developers work on transaction and smart contract rollups, tickets of this kind has become the source of inconvenience and potential security issues. To simplify and provide more safeguards to the ticket system, a more systematic accounting method for tickets is being introduced and, along with it, tickets of zero amount will be phased out of support. Tickets of zero amount will be rejected while there are safeguards and assertions in several places. They will not be accepted as a valid value of any given ticket type, when parsing a Micheline node into a Michelson value. They will not be able to get instantiated using TICKET or SPLIT_TICKET instructions. Therefore, during execution of smart contracts, those instructions will return NONE when tickets of zero amount may be created. This will potentially impact the existing originated contract on the Tezos blockchain. However, after gathering recent Tezos mainnet data, we come to a conclusion that there is a rather low risk in carrying out this migration. Here is how. Scanning mainnet for tickets of zero amount We try to identify contracts that has recently created, stored or read tickets of zero amount. Specifically, we fixed a date, 10th of August, 2022, and replay those Tezos mainnet blocks baked after the level 2608372. First, we took the snapshot and imported it into a tezos-node.

Introduction of parameters_ty field to Transaction manager operation Motivation Currently, Transaction does not specify the Michelson type of the value in parameters field. This information is not useful because of two reasons. For transactions to originated contracts, the type of parameters is always deduced from the parameters node in the contract script. For transactions to implicit accounts, the type of parameters is by conventions always unit. However, there comes inconvience when we consider some future upgrades proposed against the protocol. Transferring tickets to implicit account. Transaction is a natural option to use for transferring tickets to implicit account. However, the type of the ticket content is an essential piece of information in order to perform ticket accounting. Without specification of this type in the manager operation itself, other options are possible but remains quirky.

Implicit <-> Implicit Intuitively, to generate this operation from tezos-client tezos-client transfer 0 from alice to bob \ --entrypoint 'receive_tickets' \ --burn-cap 0.1 \ --arg 'Pair string (Pair "0x...." (Pair "I am a ticket" 4))'