Проверок будет не больше чем в сишке, но писать их будет проще.

Я делал макрос CheckRet, который позволяет работать с кодами ошибок как с исключениями. Работает в голом Си.

#define CheckRet(err) {status_t _err = (err); if (_err < B_OK) return _err;}

Пример использования:

status_t Do()
{
  CheckRet(Do1());
  if (!Do2()) {
    return B_ERROR;
  } else {
    AutoLock lock;
    CheckRet(Do3());
  }
  CheckRet(Do4());
  return B_OK;
}

Ну сам он вряд ли возьмётся допиливать раст для применения в ядре, а дальше все зависит от тех людей кто тащит раст в ядро

Ок, и что делать, если Do1() создаёт какой-то объект и его надо уничтожить перед аварийным выходом?

И определение AutoLock lock; внутри блока Линус не пропустит. Все переменные должны определяться в начале функции.

Ок, и что делать, если Do1() создаёт какой-то объект и его надо уничтожить перед аварийным выходом?

Тогда надо использовать C++ и RAII.

И определение AutoLock lock; внутри блока Линус не пропустит.

В нормальных ядрах (Windows NT, Haiku, Zircon) пропустят, как и C++. Под ядро Линукс у меня писать нет никакого желания. Но если очень хочется, то есть GCC расширения Си для RAII, в Линуксе уже и так полно GCC расширений.

Да вроде там есть вариант не включать SIMD, но использовать их, вручную сохраняя стек. Хз как там с планированием в ядре, но если прерывания процесса извне нету, то можно 128 и никаких проблем с context switch.

soft-float что ли, что-то такое. В том смылсе, что конпиль это сделает сам.

i128 и u128 в Rust не SIMD, а такие же как числа как и i64, u32 и т.д. Сложно сказать, как это будет работать на условной аппаратуре с аппаратной поддержкой, но на x86 используются обычные регистры. Хотя компилятор вправе сгенерировать вызов функции для программной реализации сложных операций (__divti3), но это необходимо не всегда (bitand).

С моей точки зрения критика от Линуса полностью оправдана, т.к. польза от таких больших чисел в ядре довольно сомнительна.

Тогда надо использовать C++ и RAII.

Это только через труп Линуса. Подозреваю, что какую-то роль в этом сыграли OOP junkies, которые любят тащить отношения is-a, has-a между понятиями сформировавшимися для обеспечения общения между людьми в проектирование программного обеспечения.

Это только через труп Линуса.

RAII в GNU C есть. И C++ в ядре Линукс работает, не позволяет только религия.

что делать, если Do1() создаёт какой-то объект и его надо уничтожить перед аварийным выходом?

по возможности использовать управляемые ресурсы

https://www.kernel.org/doc/Documentation/driver-model/devres.txt

определение AutoLock lock; внутри блока Линус не пропустит. Все переменные должны определяться в начале функции.

какой-то миф

https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/etnaviv/etnavi...

на вообще сам этот макрос конечно выглядит криво - я бы не взял

С cleanup attribute и какой-то матерью что-то похожее на RAII можно сделать, но не забывать писать return_pass_ownership(foo), вместо return foo; всё-таки придётся программисту.

по возможности использовать управляемые ресурсы

Вместо zero-cost возможностей компилятора надо городить рантайм механизмы с накладными расходами. И это в ядре с жёсткими требованиями по использованию ресурсов. Мазохисты из GNU в своём репертуаре…

Вместо zero-cost возможностей компилятора надо городить рантайм механизмы с накладными расходами

такие ресурсы не расчитаны на постоянное выделение/освобождение, обычное место - код инициализации

И это в ядре с жёсткими требованиями по использованию ресурсов

ты что-то путаешь, вероятно с какой-то микрроконтроллерной ОС

Вместо zero-cost возможностей компилятора надо городить рантайм механизмы с накладными расходами. И это в ядре с жёсткими требованиями по использованию ресурсов. Мазохисты из GNU в своём репертуаре…

У программирования чего угодно 2 подхода, когда память есть и её условно предостаточно, и когда памяти нет. И писать ядра для микрокамней – это про неиспользование памяти по возможности.

У программирования чего угодно 2 подхода, когда память есть и её условно предостаточно, и когда памяти нет.

RAII выигрывает по всем показателям: оно не потребляет дополнительную память и не исполняет лишний код рантайма. Это по сути автоматически расставленные вызовы освобождения ресурсов. Отказ от RAII в языках с ручным управлением памятью означает профнепригодность.

ты что-то путаешь, вероятно с какой-то микрроконтроллерной ОС

Оно и заметно смотря как расжирнело и замедлилось ядро Линукс.

какой-то миф

Этот код вообще немного нарушает положения из https://www.kernel.org/doc/html/latest/process/coding-style.html : 13 локальных переменных, 5 уровней индентации. Но, ОК, значит это guidelines, а не жёсткие правила.

Этот код даже близко не является альтернативой let. Потому что в let не name, а pattern.

Ты не знаешь раста даже на уровне хэллоуворлдщика, но при этом уже судишь что он менее красив и лаконичен. Слишком жирно.

Ну и сплю и вижу как язык без паттерн-матчинга, слайсов, итераторов, и т.д. является более лаконичным https://i.imgur.com/1Cv8J3x.jpg

Ну и сплю и вижу как язык без паттерн-матчинга, слайсов, итераторов, и т.д. является более лаконичным

Это только вершина айсберга. Мне, например, – а я всего лишь на уровне хелловорда знаю Раст – наиболее лаконичными показались

use serde::{Serialize, Deserialize};

#[derive(Serialize, Deserialize, PartialEq, Debug)]
struct Entity {
    x: f32,
    y: f32,
}

#[derive(Serialize, Deserialize, PartialEq, Debug)]
struct World(Vec<Entity>);

Ref.: https://github.com/pravega/bincode2

M4 вряд ли такое вывезет.

Этот код даже близко не является альтернативой let. Потому что в let не name, а pattern.

А ты изначальное сообщение читал или просто от безысходности хочешь в меня коричневое ткнуть? Смотри:

Проверок будет не больше чем в сишке, но писать их будет проще. Не if (bla(&val) == -1) goto cleanup; , a let val = bla()?;

«знак равенства» между конструкциями был поставлен не мной, я лишь показал как сократить сишную часть уравнения. А ещё мир не вращается вокруг вашего божественного раста, предсталяешь, в vim скриптах, например, тоже есть let, и там это просто объявление переменной.

Ты не знаешь раста даже на уровне хэллоуворлдщика, но при этом уже судишь что он менее красив и лаконичен. Слишком жирно.

Я себя ни разу растоэкспертом не называл. А для оценки крастоы и лаконичности достаточно взглянуть на количество спецсимволов в коде и прочего непотребства.

Ну и сплю и вижу как язык без паттерн-матчинга, слайсов, итераторов, и т.д. является более лаконичным

Ну тут даже комментировать то нечего. Все есть и уже не один десяток лет. Запретили себе все, вкрутили какой-то костыль и назвали его слайсом, модно и поумничать на форумах можно.

Меня вот другие вопросы заинтересовали, когда я ваш раст трогал - почему простейший хеллоу ворлд на расте (на системном низкоуровневом языке):

$ cat 1.rs
fn main() {
    println!("Hello, world!");
}

$ nm -u c_app | wc
      6      12     259

$ nm -u rust_app | wc
     72     144    3188

дергает >10 раз больше функций из динамических либ, тянет libdl.so и pthead, хотя ничего из этого я не использовал, ну видимо какая-то очень модная техника. С улыбкой вспоминаю статью какого-то чудика, который рассказывал про отсутсвие рантайма у рсата и что он просто создан для микроконтроллеров )).

Я вчера еще для теста скомпилил grex (небольшая консольная утилита), так это чудо накачало мне пол интернета, buildir раздулась до около 300МБ, чудно.

Я себя ни разу растоэкспертом не называл. А для оценки крастоы и лаконичности достаточно взглянуть на количество спецсимволов в коде и прочего непотребства.

Ты меня конечно извини, но это очень сильно похоже на гадание по фотографии.

Отказ от RAII в языках с ручным управлением памятью означает профнепригодность

в gcc есть RAII для С только я не видел чтобы его кто-то использовал кроме systemd

https://lwn.net/Articles/589433/

вот тут стало интересно

есть какие то сравнения старых и новых ядер?

или личный опыт?

есть какие то сравнения старых и новых ядер?

сколько занимает места в структуре двусвязный список ?

пара указателей

Сколько занимает один буфер кадра хотя бы 1080p ?

8 мегабайт

Кукаретики могут дальше кукарекать как распухло ядро от лишнего килобайта данных

не про размер а про скорость был разговор

вот интересно как чувствуют себя новые ядра на старом железе по сравнению со старыми

Я просто забью, пытаться переубедить тебя - бесполезная трата времени (:

Захочешь узнать в чём ты не прав или выяснить почему так, а не иначе - гугл в помощь.

играет джаз

сегодня он пускает Раст, а завтра всё ядро продаст!

поддержу

Я просто забью, пытаться переубедить тебя - бесполезная трата времени (:

Понимаю, мне тоже было бы сложно ответить на вопрос «почему раст такой жирный и минимальный main() линкуется со всем на свете».

Захочешь узнать в чём ты не прав или выяснить почему так, а не иначе - гугл в помощь.

Т.е. ты меня неправым уже назначил, здорово. Помнится ты с группой поддержки совсем недавно крутил пальцем у моего виска, когда я говорил о использовании вектора растаманами в модулях. Группа поддержки раста часто даже не понимает что именно вкручивают в ядро и что от этого хотят получить. Это ведь не первая тема, я помню как игнорились вопросы в духе: «что именно вы вкручиваете в ядро? Почему не можете просто линковаться с ядерными функциями без каких-то закладок в исходники?». И тебе успехов.

Понимаю, мне тоже было бы сложно ответить на вопрос «почему раст такой жирный и минимальный main() линкуется со всем на свете».

Это уже обсосали со всех сторон…

По умолчанию в Rust используется статическое связывание. Поэтому в простом «hello world» находится std/etc. Именно её ты и считаешь, а не простую программу на Rust.

$ cat main.rs
fn main() {
    println!("Hello, world!");
}
$ rustc -O -C prefer-dynamic main.rs
$ nm -u main | wc
      7      14     355

Понимаю, мне тоже было бы сложно ответить на вопрос «почему раст такой жирный и минимальный main() линкуется со всем на свете».

Ах если бы. Мне просто лень каждый раз одно и то же объяснять необучаемым. Этот коммент неплохо было бы где-нибудь закрепить: Broot v1.0.2 (консольная утилита для поиска и манипуляции с файлами) (комментарий)

Можешь ещё ldd глянуть, и вообще тот тред почитать. Всё что линкуется - линкуется для интеграции с платформой. Если платформы (Читай - ОС) нету, то не линкуется ничего, используется только core вместо alloc/std, что свойственно таким случаям как ядро. Я про это уже писал несколько раз в этом треде.

Т.е. ты меня неправым уже назначил, здорово. Помнится ты с группой поддержки совсем недавно крутил пальцем у моего виска, когда я говорил о использовании вектора растаманами в модулях. Группа поддержки раста часто даже не понимает что именно вкручивают в ядро и что от этого хотят получить. Это ведь не первая тема, я помню как игнорились вопросы в духе: «что именно вы вкручиваете в ядро? Почему не можете просто линковаться с ядерными функциями без каких-то закладок в исходники?». И тебе успехов.

Потому что ты неправым и являешься. Это же ты говоришь, что «я не эксперт, но осуждаю». И на вопрос зачем что-то тащить в ядро я тебе уже ответил.

Но сделаю скидку на то, что до тебя медленно доходит и повторюсь: https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst

Executive Summary
-----------------
You think you want a stable kernel interface, but you really do not, and
you don't even know it.  What you want is a stable running driver, and
you get that only if your driver is in the main kernel tree.  You also
get lots of other good benefits if your driver is in the main kernel
tree, all of which has made Linux into such a strong, stable, and mature
operating system which is the reason you are using it in the first
place.

Ну и Линус топил за то что бы оно не было где-то там скрыто и выключено, держи: https://lkml.org/lkml/2020/7/10/1261

Ах если бы. Мне просто лень каждый раз одно и то же объяснять необучаемым. Этот коммент неплохо было бы где-нибудь закрепить: Broot v1.0.2 (консольная утилита для поиска и манипуляции с файлами) (комментарий)

Ты походу ты даже вопроса не понял и начал мне что-то про размер бинаря объяснять. Я тебе говорю про «почему минимальному расту нужен в частности libld и libpthread»? А ты мне про размер исходников толкуешь. Системному Ц это точно не надо, если я сам не начал юзать одну из этих библиотек. Видимо в каких-то кейсах раст может подгрузить целую гору динамических либ да ещё и запустить что-то в многопотоке. Да такой системный и низкоуровневый, чувствуется полный контроль прогера.

Про количество импортируемых символов - ответ засчитан, но частично, раз это у вас статическая линковка, то почему в вообще какие-то сошки тяните? Аналогичный gcc 1.cc -static даст бинарь без единного неразрешенного символа.

Потому что ты неправым и являешься. Это же ты говоришь, что «я не эксперт, но осуждаю». И на вопрос зачем что-то тащить в ядро я тебе уже ответил.

Оставь свои оценки при себе. Я не эксперт в синтаксисе раста, но общих знаний мне вполне хватает для оценки этой технологии. И на вопрос «зачем что-то тащить в ядро» я ответил сам, а не ты с другими модниками.

Но сделаю скидку на то, что до тебя медленно доходит и повторюсь:

Что за бред? У меня драва прям каждый день ломаются. Ну-ну.

Что за бред? У меня драва прям каждый день ломаются. Ну-ну.

Сделаю скидку на то, что некоторые некоторые путают «право и лево»: достаточно войти в «kbuild», без замарывания исходников ядра гадостью.

Про количество импортируемых символов - ответ засчитан, но частично, раз это у вас статическая линковка, то почему в вообще какие-то сошки тяните? Аналогичный gcc 1.cc -static даст бинарь без единного неразрешенного символа.

Потому что у C стабильный ABI, его библиотеки можно подключить динамически. У Rust, пока что, нестабильный ABI и его библиотеки связываются статически.

$ cat main.rs
fn main() {
    println!("Hello, world!");
}
$ rustc -O -C target-feature=+crt-static main.rs
$ ldd main
        not a dynamic executable
$ nm -u main
                 U __tls_get_addr

сколько занимает места в структуре двусвязный список ? пара указателей

Сколько занимает один буфер кадра хотя бы 1080p ? 8 мегабайт

Это типа уместная аналогия?

Это типа уместная аналогия?

тебя что-то не устраивает ?

struct list_head {
	struct list_head *next, *prev;
};

typedef void (*dr_release_t)(struct device *dev, void *res);

struct devres_node {
	struct list_head		entry;
	dr_release_t			release;
#ifdef CONFIG_DEBUG_DEVRES
	const char			*name;
	size_t				size;
#endif
};

офигенный оверхед, ага - в рантайме при инициализации девайса заполнить список его ресурсов а при завершении работы девайса пробежаться по списку в обратную сторону и вызвать release() для каждой ноды. Не два указателя а целых три на ноду, а в среднем на устройство 10 нод едва ли наберётся. Для примера - видеозахват с каммеры, v4l2 нужно минимум три буфера, например 1080p 16 бит

(1920 х 1080 х 2) х 3 = 12441600 байт

12 мегабайт, а в реальном конвеере при обработке видео нужно раз в 10 больше. Ты конечно можешь байты ловить и дальше, только это бестолковое занятие.

или личный опыт?

Попробуйте установить последнее ядро в Pentium 1 133 MHz 8 MB RAM. У меня примерно такое железо есть.

Попробуйте установить последнее ядро в Pentium 1 133 MHz 8 MB RAM

Нафига?

У меня примерно такое железо есть

У меня есть siemens c55 c 16bit процем и 2? Мб ram. И чё?

Какой же ты деревянный 0\

Пол треда до тебя не доходит, что libdl и libpthread - это зависимости std и поэтому они тянутся. std можно выкинуть и заменить на core. Делается это так:

% cat main.rs
#![feature(lang_items, core_intrinsics, rustc_private)]
#![feature(start)]
#![no_std]
#![no_main]
use core::intrinsics;
use core::panic::PanicInfo;

extern crate libc;

#[no_mangle]
pub extern "C" fn main(_argc: i32, _argv: *const *const u8) -> i32 {
    42
}

#[lang = "eh_personality"]
#[no_mangle]
pub extern "C" fn rust_eh_personality() {}

#[lang = "panic_impl"]
#[no_mangle]
pub extern "C" fn rust_begin_panic(_info: &PanicInfo) -> ! {
    intrinsics::abort()
}
% rustc -C opt-level=3 main.rs
% ldd main                    
        linux-vdso.so.1 (0x00007ffd3076c000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f5806880000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f5806a88000)

% ./main || echo $?           
42
% du -hs main 
5.0K    main

libc нужна потому что это способ коммуникации с ядром, когда ты пишешь под ОС. Если пишешь под bare metal, то код будет немного другим, проще. И не нужна будет libc. Можешь сам погуглить.

Что за бред? У меня драва прям каждый день ломаются. Ну-ну.

Чукча не читатель. Но я не удивлён. Поясню. user-space API ломать запрещено. Kernel-space API ломать разрешено. Если ты ломаешь Kernel-space API, то тебе после этого нужно пофиксить внутри ядра всё, что от твоих действий сломалось, и только это. А всё что за пределами ядра (Например: ZFS, Nvidia, VirtualBox, etc.) перестанут собираться, пока их не пофиксят их собственные разработчики. Если для тебя слова Грега Кроа-Хартмана не авторитет в вопросах разработки ядра, то тут уже диалог продолжать бессмысленно.

Т.е. твои драйвера не ломаются либо потому что они от ядра соответствующей версии, либо потому что их уже пофиксили разработчки и они были пересобраны тобой самим или DKMS.

Для примера - видеозахват с каммеры, v4l2 нужно минимум три буфера

Еще раз, с чего ты решил, что это уместная аналогия? Для ответа на этот вопрос не нужно никаких исходников представлять, просто подумать немного. Ты можешь представить изображение 1080p в буфере размером с «пару указателей»? Сравнивается теплое с мягким.

Нафига?

Чтобы показать деградацию новых ядер по сравнению со старыми. Вроде бы после версии 2.6 началось особая деградация.

У меня есть siemens c55 c 16bit процем и 2? Мб ram. И чё?

Ну и как там Линукс поживает? Никак? Ч.т.д.

Какую ещё деградацию? На 2.6 ядре у меня 90% фич железа не заработает, а на первый пень нормальным людям насрать.

Ну и как там Линукс поживает?

Не имею понятия - этот хлам отправился в ящик ещё в 2007г.

Достаточно старые ядра чувствуют точно не очень, вроде неспособности вообще задействовать всю озу, ядра процессора, avx, ncq, nvme и тд.

А если это ты так потребление памяти ядром экстраполируешь, и делаешь из этого какие-то выводы, то прикинь, что только page tables для 16Гиг озу весят больше всех твоих 8Мб. Активно использующиеся на конкретном компе драйвера как бы не больше весят. Буферы/кэши весят на порядки больше. Есть традиционный компромисс - занять больше памяти, но меньше считать на процессоре/читать с диска, или считать на лету, хавая проц/перечитывать с тормозного диска. Для твоего говнопня чтобы не тормозить нужно экономить память любыми способами, на современном компе лучше забить её кэшами и таблицами. Подходы к оптимизации ортогональные.

Какой же ты деревянный 0
Пол треда до тебя не доходит, что libdl и libpthread - это зависимости std и поэтому они тянутся. std можно выкинуть и заменить на core.

С чего ты взял, что я этого не знаю. Без тебя понятно, что данные либы зависимости стандартной либы, которая является частью вашего язычка. Я скомплил минимальный мейн() для юзер спейс, и функции из libdl и libpthread начали дергаться, понимаешь? Доходит до тебя это? И вместо ответа на резонный вопрос зачем, из тебя идет какой-то хамский бред. Просто раст не тянет на системный низкоуровневый язык и либа у него соответсвующая.

libc нужна потому что это способ коммуникации с ядром, когда ты пишешь под ОС. Если пишешь под bare metal, то код будет немного другим, проще. И не нужна будет libc. Можешь сам погуглить.

Я знаю что такое libc, и для чего она нужна, разве я спорю, зачем ты мне это объясняешь? Давай я тебе последний раз попробую разжевать претензию. Вот есть у вас раст, есть у него своя стандартная либа (не надо мне рассказывать про разные ее части, это вообще не важно), данная либа основана на всяких libc и смежных. И вот вы засобирались в ядро, но не просто с голым задом, а хотите чтобы некоторый функционал из стандартной либы (желательно как можно больше, естественно) работал. Для этого вы связываете внешние ссылки из своей стд либы (опять же, я не имею в виду какой-то там отдельный компонент) с символами из ядра вместо символов из libc. Вот буквально так - в образе работающего ядра будут торчать ваши костыли для раста. Вы чего, какие-то особенные?

Чукча не читатель. …

Ты второе сообщение не прочитал? Повторю - достаточно попасть в сборочную систему ядра, чтобы ваши поделки собирались как сишные модули. Делайте какой-нибудь условный заголовочный файл, который инклудится в раст модуль, и используйте символы оттуда. Но не надо пихать свои костыли в образ ядра.

Ну так выпилите из ядра всё лишнее, вот оно и будет работать на таком компьютере. Тайникору нужно, ЕМНИП, 48 мегабайт, но вы можете пойти дальше: уберите поддержку ненужного железа.

Сравнивается теплое с мягким.

это факты об одном и том же - потребление физической памяти ядром, до тебя просто не доходит

Да-да, высосанные из пальца очередные проблемы. Хорошо что мнение таких как ты никому не интересно. Досвидули)0

Ясно, слив засчитан. Про использование pthread и libdl - легко проверяется любым желающим после сборки хеллоу ворлда. А за доказательствами засерания ядра - велком в искодники, вот просто пример (я глубоко не рыл):

void rust_helper_BUG(void)

unsigned long rust_helper_copy_from_user(void *to, const void __user *from, unsigned long n)

unsigned long rust_helper_copy_to_user(void __user *to, const void *from, unsigned long n)

void rust_helper_spin_lock_init(spinlock_t *lock, const char *name, struct lock_class_key *key)
...

Про использование pthread

Мне просто интересно, что будет когда ты узнаешь про threads.h в C11?

Рад что ты признаёшь свой слив. Сборка без libpthread и libdl тоже проверяется любым желающим, даже двигать жопой не нужно, код висит несколькими комментами выше.

Не вижу ничего плохого в этом коде.