Rust part27 (378ﾚｽ)
上下前次1-新
247(1): 01/30(木)00:39 ID:N5Ev4mKi(3/3) AAS
外部ﾘﾝｸ:github.com
外部ﾘﾝｸ[md]:github.com
248(1): 01/30(木)20:50 ID:DEHLqPyE(1) AAS
>>247
ありがとう、RFCのほう探せばよかったのか
> ## Wide string representation
> Downsides:
> * These conversions have inconsistent performance characteristics between platforms. (Need to allocate on Windows, but not on Unix.)
やっと納得できる理由が出てきた、これはたしかにな…いやでもなあ、直接OsString/OsStrを触るAPIがもっと充実していれば別にString/strとの変換をそこまで気にする必要もないのでは？
一気にString/str相当のAPIを実装するのも手間だし、OsString/OsStrで何かやりたかったらとりあえずString/strと変換してなんとかしてくれ、だからここではプラットフォームごとの差を付けたくない、って方針だったのかね？
とはいえ、考えられる発展としていろいろな文字列型を一般化する抽象化を作れるはずとかちゃんと書いてあるし、まあまあ納得できる経緯説明ではある
ありがとうね
> // and ultimately other functionality typically found on vectors,
省2
249: 01/30(木)23:18 ID:tIaEaP36(1/2) AAS
>>248
>> * These conversions have inconsistent performance characteristics between platforms
こう書かれてるけどパフォーマンスという点では特にDownsideじゃないと思うんだけどね
今の実装でも発生してるし違う環境用のOsStringを1つのプログラムが実行時に混ぜて扱うわけでもないし
問題なのは内部コードにアロケーションタイミングの違いみたいなのが侵食して分岐が増えること
わかりやすい例としてはOsStr::new(“foo”)が&OsStrを返せなくてCow<OsString, OsStr>になるとか
250: 01/30(木)23:38 ID:dm9clnkq(1) AAS
そうだね
だから現状の仕様で正しくて
10年間も問題視されていない
許容できない用途が仮にあるならWindows専用のクレートを作ればいい
251: 01/30(木)23:54 ID:tIaEaP36(2/2) AAS
as_encoded_bytesの話はこれ
外部ﾘﾝｸ:github.com
252: 01/31(金)02:25 ID:r6oh8F22(1) AAS
> # Alternatives
> * A split_at(&self, pos: usize) -> (&OsStr, &OsStr) style method. This is ostensibly simpler than a slicing API. But:
> ** The OMG-WTF-8 encoding does not support this. It requires some splits to produce overlapping slices, so that left.len() + right.len() > orig.len(). The encoded bytes on one side of pos might form a valid OMG-WTF-8 string while those on the other side do not.
> *** RFC #2295 that proposes this encoding was merged five years ago (but has not been implemented).
何その絵に描いた餅を喉に詰まらせて死ぬみたいな話……
253: 02/03(月)22:01 ID:QOxyx9oM(1) AAS
ほとんどのシステムはUTF-8以外のファイル名があったら無視かエラーでいいからどうでもええわ
254: 02/06(木)13:08 ID:s+irydGq(1) AAS
2chｽﾚ:tech
ﾜｯﾁｮｲ付いてないとどこにでも出るな妖怪
255: 02/07(金)13:12 ID:2gmcoh6P(1) AAS
LinuxカーネルのメンテナがRustコードを混ぜることを「癌」と呼び、開発者間の対立が激化中 - TechFeed
外部ﾘﾝｸ:techfeed.io
争え……もっと争え……
256(1): 02/07(金)21:47 ID:Q2ziLxl4(1) AAS
Linusが一喝するまで収めるの無理やろ
257(1): 02/07(金)22:08 ID:lN1GxRH8(1) AAS
そりゃドライバーはカーネルのインターフェイスに従って動作すべきだから、ラッパーなりで隠蔽すべきなんじゃないんかね。
個別のドライバーのためにカーネル側をカスタマイズするのはインターフェイスを侵食する越権行為だから、そんなのドライバーのラッパー側でやれ、と言いたくなるのはわかる。
258(1): 02/08(土)23:53 ID:YOrLPiSI(1) AAS
>>257
それは君の理解が間違っている
今回はRust製の各デバイスドライバが独自のCバインディングを持つ不便な状況を改善するためのパッチだ
つまりカーネルのC側に手を入れるパッチではなくC側は同じままで変更は一切ない
今回の件は該当部分dma_alloc_coherent()のC⇔Rustの抽象ラッパーのコードを含めるパッチだけだ
それさえメインテナーに拒否されたため大問題になっている
259: 02/08(土)23:57 ID:dA8HOTum(1) AAS
デバドラはRustで書くのが普通になってきているから
そういう共通ラッパーという形のRustインターフェイスが色々と欲しいのよね
でもそれはいずれカーネル自体のRust化へ繋がる道になるから強く反対してるのよ
260(1): 02/09(日)00:59 ID:LgxLklST(1/3) AAS
普通に考えたら異種の言語が混ざるとデバッグと開発の障害でしかないからどこかで境目は必要
261: 02/09(日)06:01 ID:2Eyl255N(1/4) AAS
>>258
メンテナーがRust用コードのメンテナンスを拒否したということじゃないの？
Rust for Linuxでサポートするような話じゃないんかね。
262: 02/09(日)06:47 ID:2n/Om2yv(1) AAS
>>260
異種の言語を混ぜる話なんか誰もしていない
今回の事件のパッチも異種の言語を混ぜることなくCのAPIはそのままで
その上にRustの層を作る話
In response, Krummrich explained the Rust for Linux effort is creating Rust code that abstracts the C APIs for all Rust drivers and is maintained by Rust devs. In other words, the C side of the kernel stays the same, and Rust drivers use abstractions to that C code, and that these abstractions are maintained by a team centrally in rust/kernel, all of which is arguably better than drivers having their own individual C bindings.
263(1): 02/09(日)08:50 ID:lISaYUpW(1/3) AAS
最終的にRust側のメンテナが切れてSNSで晒したりしたのは良くなかったけど
技術的にはC側に迷惑かからないように十分配慮して、出てきた懸念も全て潰したにも関わらず
「とにかくRustに関わりたくないから却下」だったからまぁ切れるのも分かる
264(1): 02/09(日)09:09 ID:2Eyl255N(2/4) AAS
>>263
そのコードはcで使えるの？
使えるならともかく、Rust専用ならメンテナーが「そんなののメンテナンスで負担増えるのは嫌だからRustドライバー側でやってくれ」というのもわかる。
Rust for Linuxはこういうのの受け皿にならんのかしらん？
265(1): 02/09(日)09:24 ID:lISaYUpW(2/3) AAS
>>264
受け皿も何もそもそもRust for Linuxでやってる話だし
完全にRustドライバー側でやるからCには影響しないって言ってるわけ
具体的にメンテナンスの負担が増える理由を挙げてくれれば対応策も考えられるけど
「とにかくお前らを邪魔するためなら何でもする」って言ってるからどうしようもない
266(1): 02/09(日)10:38 ID:2Eyl255N(3/4) AAS
>>265
メンテナが「Rustは俺のサポート範囲に出てこないでドライバ内で閉じてやってくれ」と言うんだから、当面はrust fir linux でドライバーのテンプレートを作るなりCバインディングサポートライブラリを作るなりすればいいんじゃないんかね。
「Rust製の各デバイスドライバが独自のCバインディングを持つ不便な状況」というのもrust fir linuxでフレームワーク作ってサポートすれば解決するし。
上下前次1-新書関写板覧索設栞歴
あと 112 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.047s*