Даже микрософт шлёт патчи на RUST

для разработки на языке Rust файловых систем

После патчей станут failовые системы. АЗАЗА 🤡 Понели щютку?

Драйвер использует прикреплённый к tar-файлам индекс для навигации по файлам внутри архива без перебора всего содержимого.

Годно.

Лучше бы про git притащил. :)

Лучше бы про git притащил. :)

Не про гит, а про керлен.орг. Там вообще забей. Но потенцевально это интересно больше, ибо в старом драйвере ext2, как сообщают анонимные комментаторы на опенете есть проблемы с переполнением и никакими хацкерами это не объяснить. А тут прискакивает микрософт на белом коне и спасает линакс, да ещё и пилит универсальные интерфейсы для всяких интересных фс на rust’e к этому стоит присмотреться.

В отличие от ранее доступной реализации ФС Ext2 на языке Rust - ext2-rs, новый вариант работает на уровне ядра (модуль rust_ext2), а не в пространстве пользователя. Драйвер rust_ext2 содержит около 700 строк кода на Rust и может использоваться в качестве отправной точки для разработки более сложных реализаций ФС, таких как Ext4.

ЯННП. А когда это из ведра выпилили поддержку ext2?

и может использоваться в качестве отправной точки для разработки более сложных реализаций ФС, таких как Ext4.

Угу, а может «не использоваться». Кажется дядя не вникая в суть просто посчитал, что раз оно всё начинается на «ext» то в принципе там же не сложно будет запилить мою идею в независимости от цифирки после ext.

А когда это из ведра выпилили поддержку ext2?

В 6.9 перевели в устаревшие, но ещё не выпилили.

Так а кто сомневался, что руст задумывался как замена си. Естественно, как только руст допилили до кондиционного вида - сразу начали его применять. Сейчас какие-то депрекейдет вещи перепишут на него. На этом обкатают новыя яп в боевых условиях. Когда будет всё тип-топ - сразу массово начнут переписывать всё

на Rust

в Rust

Но потенцевально это интересно больше, ибо в старом драйвере ext2, как сообщают анонимные комментаторы на опенете есть проблемы с переполнением и никакими хацкерами это не объяснить.

Переполнение стэка в мозгу комментаторов? Единственный «фатальный» недостаток ext2 который помню, только в том, что он не журналируемый и хард ребуты не всегда переживал без запуска ручной проверки fsck, что для удаленных машин без возможности применения «рук» в прямом доступе было не очень...

А когда это из ведра выпилили поддержку ext2?

В 6.9 перевели в устаревшие, но ещё не выпилили.

Аааа, ну deprecated может висеть годами.

Камент от туда:

Так он не просто устаревший, там проблема в 32-разрядных счётчиках. И автор сразу предлагает желающим «перенести в него поддержку 64-разрядных счётчиков времени, что не представляет большого труда» (opennet.ru/opennews/art.shtml?num=60853)

Но что-то очереди не наблюдается. Так что этим кем-то можешь стать именно ты!

Ну пусть развивают, мы никуда не торопимся. Дальше видно будет, загнётся или нет.

ЯННП. А когда это из ведра выпилили поддержку ext2?

Никто не выпиливал. Это просто эксперименты с разработкой на Расте. Надо же на чем-то обкатывать идеи.

В 6.9 перевели в устаревшие, но ещё не выпилили.

В устаревшие переведён драйвер ext2, а не поддержка ext2.

Поддержка ext2 обеспечивается драйвером ext4, при чем более полно, чем старым драйвером.

Негрософт умеет в стратегию. Сначала он выведет всё на Раст, а потом переведёт на MIT

Лучше бы про git притащил. :)

Да, я чо т сегодня зашел почитать новости и был расстроен. Дырявое всё.

Кстати, а чо никто на ЛОРе релиз 6.9 даже не обсуждает… Или уже настолько пофиг собственно на Линукс?

Дырявое всё.

Проверили далеко не всё! :)

В 6.9 драйвер ext2 объявили устаревшим. После его удаления останется современный драйвер ext4, который умеет работать с ext2

Даже микрософт шлёт патчи на RUST

Так говоришь, будто бы это к добру.

Ну всё, Microsoft захватил Linux и делает с ним что хочет, а люнексоедам хоть бы хны. Даже форкнуть никто не может!

там проблема в 32-разрядных счётчиках
которые переполнятся 19 января 2038 года.

Вот это аргумент! Спасибо.

В 6.9 драйвер ext2 объявили устаревшим. После его удаления останется современный драйвер ext4, который умеет работать с ext2

Хм... не знал что их объединили, странное решение. Я бы ещё понял объединение с ext3, но с ext4 которое совсем более другое...

Сишники улетят на Татуин на собственной тяге, если на Rust начнут переписывать подсистемы ядра.

два созданных на их основе драйвера с реализацией файловых систем ext2 и tarfs, работающих в режиме только для чтения.

Это какой-то позор

Безопасный раст такой безопасный [1]

+    unsafe extern "C" fn fill_super_callback(
+        sb_ptr: *mut bindings::super_block,
+        _fc: *mut bindings::fs_context,
+    ) -> ffi::c_int {
+        from_result(|| {
+            // SAFETY: The callback contract guarantees that `sb_ptr` is a unique pointer to a
+            // newly-created superblock.
+            let new_sb = unsafe { SuperBlock::from_raw_mut(sb_ptr) };
+
+            // SAFETY: The callback contract guarantees that `sb_ptr`, from which `new_sb` is
+            // derived, is valid for write.
+            let sb = unsafe { &mut *new_sb.0.get() };
+            sb.s_op = &Tables::<T>::SUPER_BLOCK;
+            sb.s_flags |= bindings::SB_RDONLY;
+
+            T::fill_super(new_sb)?;
+
+            // The following is scaffolding code that will be removed in a subsequent patch. It is
+            // needed to build a root dentry, otherwise core code will BUG().
+            // SAFETY: `sb` is the superblock being initialised, it is valid for read and write.
+            let inode = unsafe { bindings::new_inode(sb) };
+            if inode.is_null() {
+                return Err(ENOMEM);
+            }
+
+            // SAFETY: `inode` is valid for write.
+            unsafe { bindings::set_nlink(inode, 2) };
+
+            {
+                // SAFETY: This is a newly-created inode. No other references to it exist, so it is
+                // safe to mutably dereference it.
+                let inode = unsafe { &mut *inode };
+                inode.i_ino = 1;
+                inode.i_mode = (bindings::S_IFDIR | 0o755) as _;
+
+                // SAFETY: `simple_dir_operations` never changes, it's safe to reference it.
+                inode.__bindgen_anon_3.i_fop = unsafe { &bindings::simple_dir_operations };
+
+                // SAFETY: `simple_dir_inode_operations` never changes, it's safe to reference it.
+                inode.i_op = unsafe { &bindings::simple_dir_inode_operations };
+            }
+
+            // SAFETY: `d_make_root` requires that `inode` be valid and referenced, which is the
+            // case for this call.
+            //
+            // It takes over the inode, even on failure, so we don't need to clean it up.
+            let dentry = unsafe { bindings::d_make_root(inode) };
+            if dentry.is_null() {
+                return Err(ENOMEM);
+            }
+
+            sb.s_root = dentry;
+
+            Ok(0)
+        })
+    }
+

+impl Registration {
+    /// Creates the initialiser of a new file system registration.
+    pub fn new<T: FileSystem + ?Sized>(module: &'static ThisModule) -> impl PinInit<Self, Error> {
+        try_pin_init!(Self {
+            fs <- Opaque::try_ffi_init(|fs_ptr: *mut bindings::file_system_type| {
+                // SAFETY: `try_ffi_init` guarantees that `fs_ptr` is valid for write.
+                unsafe { fs_ptr.write(bindings::file_system_type::default()) };
+
+                // SAFETY: `try_ffi_init` guarantees that `fs_ptr` is valid for write, and it has
+                // just been initialised above, so it's also valid for read.
+                let fs = unsafe { &mut *fs_ptr };
+                fs.owner = module.0;
+                fs.name = T::NAME.as_char_ptr();
+                fs.init_fs_context = Some(Self::init_fs_context_callback);
+                fs.kill_sb = Some(Self::kill_sb_callback);
+                fs.fs_flags = 0;
+
+                // SAFETY: Pointers stored in `fs` are static so will live for as long as the
+                // registration is active (it is undone in `drop`).
+                to_result(unsafe { bindings::register_filesystem(fs_ptr) })
+            }),
+        })
+    }
+
+    unsafe extern "C" fn init_fs_context_callback(_fc: *mut bindings::fs_context) -> ffi::c_int {
+        from_result(|| Err(ENOTSUPP))
+    }
+
+    unsafe extern "C" fn kill_sb_callback(_sb_ptr: *mut bindings::super_block) {}
+}

// SAFETY: Trust me bro

[1] https://lore.kernel.org/rust-for-linux/20240514131711.379322-1-wedsonaf@gmail.com/T/

Да, аргумент: ext2 нахрен не нужна, и никем не используется.

А вот кстати коммент Теодора Цо, создателя ext4, который автор новости на опеннете, переврал:

Well, if we cared we could backport the support for the expanded timestamps to ext2. I’m not sure it’s worth the effort, but it’s not that hard….

Вот еще профиль автора доброй половины новостей про Rust на опеннет. Который, по его словам, «кормит говном долбоёбов и получает за это бабки», написывая пропаганду.

там проблема в 32-разрядных счётчиках

которые переполнятся 19 января 2038 года.

Вот это аргумент! Спасибо.

Да, наступит красный год и вы покаетесь, что слушали ложных богов, а не Азуру.

Да. Всему классическому 32-битному юзерлэнду придёт кабзда. Недолго осталось. Покайтесь!

Вроде бы в glibc и ядро уже приняли патчи, дающие возможность использовать 64 битный time_t даже в 32 битном окружении?

Старый софт это не исправит. Все старые бинарные сборки, как минимум, перестанут работать с сетью по шифрованным протоколам, так как там используется текущее мировое время. А кроме этого сколько еще отвалится - не счесть.

Лол, похож на альтернативного брата близнеца царя. На любую тему есть топовые посты.

__bindgen_anon_3

Лакомка, я так понимаю, в Rust не завезли анонимные union, и оно генерирует __bindgen_anon_X. Интересно, что будет если кто то поменяет местами union в сишном коде, или изменят шаблон имени в bindgen.

НУЖНО БОЛЬШЕ FS

Файловая система tarfs позволяет монтировать архивы в формате Tar в виде файловой системы

archivemount такое делать может, но на HDD это было довольно унылое занятие.
Может на SSD ситуация получше будет, но в эпоху, когда SSD стоит дешевле пары блинов с горячей пиццей, то как-то переживать по этому вопросу смысла нет, т.к. любителям побольше даровали LVM и можно не переживать о том, куда бы диск пристроить.

Что ж тебя так корежит-то?

Там еще и аватарка соответствующая

Не ходи на опеннет и не читай психически больных людей. И будет тебе счастье в жизни.

Я помню, что заводили RFC по этому поводу. Но где ныне тот воз, хз.

Почему «даже»? MS не сразу подключилась к продвижению раста, но уже пару-тройку лет MS Research занимается растом. Ну а их поворот к Линукс и так известен.

Надо было писать так: разработчики микрософт неосилили сишечку, и выкрутились из положения при помощи Rust.

Боже, как это прекрасно!

Драйвер использует прикреплённый к tar-файлам индекс для навигации по файлам внутри архива без перебора всего содержимого.

А кто индекс прикрепляет?

Сначала он выведет всё на Раст, а потом

Закопает.

Воооот! А главное, на глазах у ликующей публики.

Сначала он выведет всё на Раст, а потом

Закопает.

Мечты, а по факту, мс переписывает на rust:

• Куски офиса.

• Выдаёт гранты на разработку адаптеров либ с++ в раст.

Походу корпорации решили закопать сишку и плюсишку.

Негрософт умеет в стратегию. Сначала он выведет всё на Раст, а потом переведёт на MIT

Ты не понимаешь как работают лицензии на программы.

Я понимаю где работают разработчики на расте и чьё авторское право на код постепенно будет вливаться всё больше :) Пока код был на сях и работал, переписывать его чтобы увести права не получилось бы. А если переписывать на другой язык, то можно тихо и незаметно подрезать себе в портфельчик.

Закопает.

Это плохо или хорошо?

Ладно, с Растом картина понятная. А вот скажите… Что насчёт планов MS на C#? Он у них остаётся предпочтительным средством создания прикладного кода или его тоже закопают в пользу чего-нибудь?

Да, еще насчёт Раста и ядра.

Раст это всё-таки ближе к нише C++.

В языке предусмотрены исключения и неявный вызов деструкторов.

Для разработки ядра, на мой взгляд, лучше подходит язык с максимально явными путями исполнения кода. Какой-нибудь Zig, что ли?

Я понимаю где работают разработчики на расте и чьё авторское право на код постепенно будет вливаться всё больше :) Пока код был на сях и работал, переписывать его чтобы увести права не получилось бы. А если переписывать на другой язык, то можно тихо и незаметно подрезать себе в портфельчик.

Ты все ещё не понимаешь как работают лицензии на программы.