HackerTrans
TopNewTrendsCommentsPastAskShowJobs

aliceryhl

no profile record

comments

aliceryhl
·2 เดือนที่ผ่านมา·discuss
This is not psychosis.
aliceryhl
·4 เดือนที่ผ่านมา·discuss
Interesting. Though looking at the code, it does still check VM_MAYWRITE, so the mapping needs to be something you could remap as writable.
aliceryhl
·5 เดือนที่ผ่านมา·discuss
Ah thanks for clarifying.
aliceryhl
·5 เดือนที่ผ่านมา·discuss
Thank you. I was wondering about that.
aliceryhl
·5 เดือนที่ผ่านมา·discuss
Hmm, I read some of the decision, and now I'm not sure what to make of all of it.

When I came to the opinion from Jackson, J., I found it extremely compelling. He says this:

... But some of TWEA’s sections delegating this authority had lapsed, and “there [was] doubt as to the effectiveness of other sections.” Accordingly, Congress amended TWEA in 1941, adding the subsection that includes the “regulate ... importation” language on which the President relies today. The Reports explained Congress’s primary purpose for the 1941 amendment: shoring up the President’s ability to control foreign-owned property by maintaining and strengthening the “existing system of foreign property control (commonly known as freezing control).”

When Congress enacted IEEPA in 1977, limiting the circumstances under which the President could exercise his emergency authorities, it kept the “regulate ... importation” language from TWEA. The other two relevant pieces of legislative history—the Senate and House Reports that accompanied IEEPA—demonstrate that Congress’s intent regarding the scope of this statutory language remained the same. As the Senate Report explained, Congress’s sole objective for the “regulate ... importation” subsection was to grant the President the emergency authority “to control or freeze property transactions where a foreign interest is involved.” The House Report likewise described IEEPA as empowering the President to “regulate or freeze any property in which any foreign country or a national thereof has any interest.”

However, then I read Kavanaugh, J. who writes the following:

In 1971, President Nixon imposed 10 percent tariffs on almost all foreign imports. He levied the tariffs under IEEPA’s predecessor statute, the Trading with the Enemy Act (TWEA), which similarly authorized the President to “regulate ... importation.” The Nixon tariffs were upheld in court.

When IEEPA was enacted in 1977 in the wake of the Nixon and Ford tariffs and the Algonquin decision, Congress and the public plainly would have understood that the power to “regulate ... importation” included tariffs. If Congress wanted to exclude tariffs from IEEPA, it surely would not have enacted the same broad “regulate ... importation” language that had just been used to justify major American tariffs on foreign imports.

And I also find this compelling.

To add onto this, Roberts, C. J. says: IEEPA’s grant of authority to “regulate ... importation” falls short. IEEPA contains no reference to tariffs or duties. The Government points to no statute in which Congress used the word “regulate” to authorize taxation. And until now no President has read IEEPA to confer such power.

This seems directly contradictory to Kavanaugh, J.'s dissent! Kavanaugh, J. claims that Nixon used the word “regulate” to impose tarrifs. And apparently the word isn't just in some random other statute — Nixon did so from TWEA, the predecessor of IEEPA: when Congress enacted IEEPA in 1977 it kept the “regulate ... importation” language from TWEA. (from Jackson, J.) So the point that no President has read IEEPA to confer such power seems pretty weak, when Nixon apparently did so from TWEA.

I have no conclusion from this, but IMO both Jackson, J. and Kavanaugh, J. have pretty strong points in opposing directions.
aliceryhl
·7 เดือนที่ผ่านมา·discuss
I asked about this when they presented the project at the Linux Plumbers conference. They replied that it's not really intended to be a security boundary, and that you should not let anyone malicious load these programs.

Given this thread model, I think their project is entirely reasonable. Safe Rust will prevent accidental mistakes even if you could technically circumvent it if you really try.
aliceryhl
·7 เดือนที่ผ่านมา·discuss
I have no insight into the Asahi project, but the LKML link goes to an email from James Calligeros containing code written by Hector Martin and Sven Peter. The code may have been written a long time ago.
aliceryhl
·7 เดือนที่ผ่านมา·discuss
That's an email from James Calligeros. All this patch says is that the author is Hector Martin (and Sven Peter). The code could have been written a long time ago.
aliceryhl
·7 เดือนที่ผ่านมา·discuss
Where I'm from, it probably would not be stolen by anyone.
aliceryhl
·7 เดือนที่ผ่านมา·discuss
How?
aliceryhl
·9 เดือนที่ผ่านมา·discuss
It never made it into upstream Linux, but there is already a sample implementation that Wedson wrote in 2022: https://github.com/Rust-for-Linux/linux/pull/798
aliceryhl
·9 เดือนที่ผ่านมา·discuss
It won't be different from Tokio. When you pass a future to tokio::spawn, that will also eagerly execute the future right away.
aliceryhl
·9 เดือนที่ผ่านมา·discuss
It's trivial to implement an async runtime in the kernel. The kernel's workqueue is already essentially a runtime.
aliceryhl
·11 เดือนที่ผ่านมา·discuss
> IIRC Alice from the tokio team also suggested there hasn't been much interest in pushing through these difficulties more recently, as the current performance is "good enough".

Well, I think there is interest, but mostly for file IO.

For file IO, the situation is pretty simple. We already have to implement that using spawn_blocking, and spawn_blocking has the exact same buffer challenges as io_uring does, so translating file IO to io_uring is not that tricky.

On the other hand, I don't think tokio::net's existing APIs will support io_uring. Or at least they won't support the buffer-based io_uring APIs; there is no reason they can't register for readiness through io_uring.