call alloc_resource

так нечесно (воно не розгорнуте)
й це замість повністю розгорнутого вище

example::create_data::h8713f00e598a636f:

я б атакував в першу чергу сам «глобальний»

__rust_alloc

якщо такі виклики будуть по всьому ядру умовної операційки,
це печалька (що, втім, не скасовує можливості завести свої альтернативні способи алокації, й все буде тайпсейф та «чікі-пікі»)

То завжди з тих ситуацій, що... «іт депендс»...

В загальному «Ай лайк» приклад від шановного Artyom Krivokrisenko, як самий лаконічний))

Втім давайте розкрутимо цю гру:

malloc(sizeof(struct data));

Ем... malloc для структури з двома полями?
З локами мютекса хіпа та пошуком доступного блока в (гіпотетично) пофрагментованому хіпові?

То може «зайве» копіювання мув вже не так й «страшно» й +можемо покладатися на обов’язкове RVO (й нічого не алокувати взагалі)?

А якщо структурки (чи поля) більш великі, то може C++не unique_ptr (умовно відповідник Box з Расту)?

А якщо в нас таких структурок «дофігіще», й їх треба «алокувати швидко», то може це має бути «блокпул»?
й тоді (умовно, NDA не порушено):

BlockPool<Data, КонстантаСкількиЇхТреба> моїБлоки;
... 
auto тойБлок = моїБлоки.Emplace(параметри, конструктора)

Причому той Emplace може повертати чи то «мув онлі» подобу C++ного «юнік поінтер» для щойно алокованого, або навіть й з референс каунтами (що сторяться поруч своїх даних в тому ж блокпулі))

Звісно то все (такі обгортки) для блокпулів, то «нестандартні велосипеди», але якщо є один раз готове, то їх можна реюзати багатократно!

Й звісно цей підхід можна також розгромити, бо ж локфрі операції, всякі інтерлокед інкременти для умовного shared_ptr, то все теж «не безкоштовно»...
Але чи справді саме в тому фрагменті «затуп»? А ми його вже оптимізуємо...

А ще, якщо ми маємо «часто бігати» по отих «дофігіще» всіх таких структурок, то може їх треба покласти в одному масиві послідовно, а не виривати з пейджів порозкидуваних по всьому хіпові?...

А може їх взагалі «алокувати» в стекові сріда (чи й корутини))

І це ми ще не дійшли до Rust з його «борров чекером» та «лайфтаймами»...

Але навіть для «няшної Сшки» то може бути не

struct data* create_data(void)

data_status_t data_init(struct data* initHere);

Проте люди спецом чогось «обрубують» всі решта множинних варіантів, й лишають тільки оте «істинно канонічне» з goto ручками...,
Втім й воно по деяких кодстанах теж не катить, також як і багато ретурнів на функцію — не катять... і тих «підходів» — безчисленний «зоопарк», особливо коли в одному проекті юзається код потягнутий з багатьох кодбаз, в кожній з яких в авторів були свої «мухи», щодо того де алокувати та як звільняти)

Ну і саме головне, щоб любителі кожного з тих підходів не допікали, то все що тільки можливо треба написати на... Пайтоні треба написати на Пайтоні, й взагалі триматися подалі від того світу «прелімінарі оптимізації»))

В тому контексті завжди відмічаю: в нормальній сучасній мові «хоч якесь» RAII — musthave, або хоча б якийсь defer, як в go, хоча б using як в C#, хоча б with як в Пайтоні (а оті всі goto Cleanup; то особливий клінічний затятий мазохізм, втім, як й набивання табличок VMT ручками, коли люди роблять «ООП на Сшці» й всі танці з бубном довкола ініціалізації (та клінапу в правильний момент) таких «класів»...)

Ну і так, референс каунтінг або передача овнершипа — мастхев, об’єкт не повинен зникати «сам собою» через то, що його прикантошили в іншому місці бо хтось висмикнув дріт...

Все оте «перевір чи ще підключено а тоді звертайся» — не катить, бо це завжди рейс кондішен!

Проблема то не в самому Rust, а там комітять наскоро зроблене лайно

це ж яке ж лайно вони б тоді накомітили на Сшці? ))

іншими словами чому з «кусків закоментованого коду» висновок що в них на «няшні Сшці» вийшло б «щось краще»?
Та не вийшло б! ))

Та ну... єдині граблі, які я бaчу 0 це то, що «скоро» dkms потребуватиме не лише «няшної Сшки», а й Rust :)

Тому що «банда чотирьох» придумувала деякі свої паттерни саме як воркераунди до обмежень С++ (й ті воркераунди також розповзлися в тодішню Джаву і так далі... стали «біблією» в девелопменті)

Воркераунди бо тоді ще не було повноцінної "ламбди"/"делегату«/std::function<>/Function<>/Action<>, які можуть «захопити» стейт й «подорожувати» разом з «тим всім, що треба» десь «туди, куди треба», щоб виконати «щось, що треба»...

Відповідно всі «Обзервери», «Стратегії», «Команди», «Декоратори» насправді за допомогою отих базових класів і «перевизначення» в похідному «апдейта», «алгоритму», «екзекута», «операції» просто імітують «функції першого класу» (ті, що ламбди/кложури, що їх можна передавати «як є» замість «поінтера на базовий клас з перевизначаємою операцією»)...

Сам Пайтон, до речі, бай дізайн, вдало позбувся класичного «декоратора з класами» саме завдяки «@декораторам», що, по факту, оперують над «функціями» й повертають "ламбди"/"кложури«...

То не як «в претензію», а лише нотіс, що часом «ООП магія» виходить занадто переускладнена...

А в загальному дякую за україномовний контент... треба його множити, щоб гугль не вів на «хабрахабр»))

Все класно і пізнавально/мотивуюче (для таргет аудиторії), паттерни знати треба, не сперечатимусь, але...

...але паттерн Command в мові що підтримує "ламбди"/"кложури"/"передачу функцій як аргументів", то це якась печалька))

так як воно є на зараз

dkms юзається!

ядро не треба білдити на локальній машині, але бінарна сумісність для модулів ядра не гарантується, єдина раціональна стратегія — взяти хедери до готовенького ядра, й зібрати модуль разом з ними, то власне і є вся ідея dkms!

Ще може буде проблемою нп знайти з якою версією rust компайлера можна то взагалі зібрати

нє нє, то має бути «з коробки», так як працює dkms вже сьогодні, «простий смертний» не ставить dkms він навіть не знає про нього (втім як і девелопери-експерти, переважно не читають що там пише білими буковками на чорному фоні, коли звичайний апдейт з сінаптіка)...

Лінукс нарешті (непомітно) став юзер фреднлі для «простих смертних»... а якщо заставити людину бавитися з пошуками версій, то відкидає назад до «красноглазія» та хріностраждання з налаштуваннями...

та нє, мова не про кастомне ядро... dkms раниться сам з коробки в умовному десктопному MX Linuх при апдейтах, ніякого «шаманізму» не потрібно, збирати самому ядро не потібно...

це «штатний воркфлов» в тому числі й для машин «простих смертних», ніхто навіть не звертає увагу, що воно там є, бо ніхто тих рядочків в процесі апдейтів не читає...

Насправді бракує українського Stackoverflow, бо «ukrainian.stackexchange.com» це нето... й ті, хто не дружить з «енглісх лангуаге», вони технічні топіки йдуть шукати на «опщєпанятнам» в «рускому мірі»...

А ще цей сайт міг би стати «українським Хабрахабром», втім, наразі, шукати статті не надто зручно:
заголовки «Перша робота Кар’єра в ІТ Ринок праці Топ-50 Рейтинг книжок, компаній, вишів, мов, банків Портрет айтівця Реєстр Дія City» — то якийсь організаторсько-HRний спам про «роботу в ІТ» але ніразу не про технічні топіки...

є ще «Спільноти», але теж ніразу не кидаються в очі, й взагалі виглядає що то наперед визначений список... а де Embedded, Linux, DIY кнопочка «створити спільноту»?

Тобто в запиті на технічну тему кирилицею (навіть українською мовою) то Гугль не приходить на цей сайт, а веде «де інде в рускій мір»

наразі саме так пише (як я розумію офіційна) дока
rust-for-linux.com/...​a-build-with-rust-enabled

тобто можна «тимчасово» ламати Rust і за те «нічого не буде», що, власне і є сумулькою для всіх Rust розробників (й чим можуть зловживати Сшні «динозаври»).

щодо бінарної сумісності, то тут гарантії є тільки для юзерспейсу...
а в межах самого «монолітного» ядра ніяких гарантій на сьогодні нема,
саме через те й з’явився dkms, коли «дрова» перекомпільовуються на прямо машині в юзера під нове ядро...

що також, очевидно, ще один «баттхерт», адже щоб дрова на Rust також змогли поюзати бенефіти dkms, то треба на юзерську машину притарабанити й Rust з його примочками, що мав би ще й працювати через якийсь умовно bindgen (який зовсім «нето», ніж якби сама gcc-шка мала б «умовно» -fdump-rust-spec)

Ні, то не відповідь!
Відповідь, то коли сам Лінус прийме рішення за фразою з мого оригінального допису «Тут [тобто в пості на який я там відмовідаю!] головне питання так і не має відповіді: якщо на боці „няшного C“ (якраз в тому коді/структурах даних, що юзаються з Rust) хтось вносить таку зміну, яка ламає Rust частину, то хто тоді буде правити Rust частину?»...

Тобто «срач» не закінчиться тою дипломатичною відповіддю Лінуса про «does not
imply» процитованою в дописі вище від мого комента, до якого власне я і написав свій комент! І тим більше оригінальний «срач» не закінчиться намаганнями інших дописувачів «образумити» мене, коли я стверджую, що оригінальну проблему так і не вирішено (тому риторично-філософські роздуми про "

а у вас як на проекті

" — це сміття в контексті вирішення оригінальної проблеми)

Й стейтмент з прийнятої доки «Rust for Linux», що визначає правила, теж насправді не катить і не вирішує проблему:
«However, exceptionally, for Rust, a subsystem may allow to temporarily break Rust code. The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the C side. The breakage should nevertheless be fixed as soon as possible, ideally before the breakage reaches Linus.»

бо це тільки накручує одну сторону відтягувати фікс (нема нічого більш вічного за тимчасове), а іншу примушує і далі ходити по граблях чераз зміни в Сшці, які ламають Rust!

Як справжній солюшен для тих, хто не хоче юзати/правити Rust було б правило для цього ніколи більше не змінювати те, що попадає в EXPORT_SYMBOL, а якщо щось таки треба змінити, то це має бути новий EXPORT_SYMBOL для нового імені, і продовжувати сапортити старий символ... що насправді підхід вінди з її «ЯкатоАпішка» та «ЯкатоАпішкаEx», замість правити оригінальну АПІшку, а також і правило включати sizeof структурки першим полем (щоб всередині рорізнити версію)... тобто фіксація «опаблікованого» АПІ «навіки» навіть всередині ядра! А якщо таки «брейкінг чейндж» тому має бути залізно subsystem may NOT allow to break Rust code а не то ото, що є зараз (проблему не вирішено!)

А для Rust розробників було б набагато простіше, якби існувало не тільки -fdump-ada-spec а й -fdump-rust-spec і не треба було б набивати рули для мапінга між «няшною Cшкою» та Rust вручну, і рів’ювити їх щоразу, коли в Сшній частині щось змінилося...

Rust — із файберами async/await і т.п. це безкінечно далеко усе від системного програмування

та ні, ідея файберів, корутин, вона офігенна, але найкраще реалізували цю ідею в... Сшці
така корутина нічого не коштує, і ось така теж порівнянно з «ручним» закодовуванням FSM там, де повинна бути послідовна «асинхронна логіка»
(й то якраз той кейс, коли Сшний підхід краще поюзати в С++ ніж юзати «нові та модні» переускладнені С++ні корутити, хоча вони й не мають тих обмежень/граблів, які має Сшний аб’юз Duff’s device))

PS. «порівнянно з „ручним“ закодовуванням FSM», є ще хвалений маркетологами і облизаний продажниками qp фреймворк, але мало хто його юзає правильно (просто як спосіб створити скелет для станів та переходів), натомість там тайпкаст на тайпкасті і тайпкастом поганяє...

Зато менеджери/сейлзи вміють його грамотно втюхати команді/клієнту як немавідь який прорив в підходах

на місце соляріса приперли лінукс, який був у всьому гірший

агласітє весь спісак, в чому саме «в усьому»? ))

а у вас як на проекті

Це — не відповідь. Власне ж тут весь корінь «срача»: якраз, щоб не співпрацювати додатково (до асемблера)) ще й з тими, хто знає Rust (щоб не включати додаткових персонажів для вмовлянь й биття поклонів бюрократії узгодень та рів’ю)

Тут головне питання так і не має відповіді: якщо на боці «няшного C» (якраз в тому коді/структурах даних, що юзаються з Rust) хтось вносить таку зміну, яка ламає Rust частину, то хто тоді буде правити Rust частину?

Бо, як я зрозумів, в тому й полягають головні граблі й головне неприйняття: відтепер або всі Сшні штучки поюзані з Rust стають незмінними (не додаш поле в структурку, не додаш параметр в функцію), або ж той, хто їх таки хоче/мусить змінити Сшні штучки, йому також прийдеться й поправити Rust код вручну...

Тема крадійства та тендерів не розкрито...

Ану погугліть, скільки там в прифронтовому Покровську на «благоустрій» запроектували?
Цитата: «Нагадаємо, що у Покровську Донецької області у бюджет громади на 2025 заклали майже 15 млн гривень на підтримку ЗМІ. Ще 73 млн планують спрямувати на водоканал, 34 млн — на благоустрій, а майже 30 млн — на функціонування теплової енергії. Про це свідчать дані з відкритих джерел.»

Звичайно що Трамп і компашка «в курсі» як в нас тринькають гроші, тому й будуть прикручувати краник допомоги доти, допоки не побачать, що ті українці нарешті взялися за голову...

Ну і так, цілком логічно, що Трамп і компашка хочуть самі розкрадати укранські надра саме для того, щоб їх не розкладали «українські» проросійські олігархи :)

темплейт «під капотом»,
а сам «синтаксис» через макро:

#define defer auto TOKENPASTE2(__deferred_lambda_call, __COUNTER__) = deferrer << [&]

тому після того умовне struct Sample{ int defer; }; вже не заканає...

У мене більше проблем з логікою, але то таке.

То отже, більш цікава й творча робота, ніж шукати чужі меморі ліки в чужому коді))

А якщо їх треба білдити, то можна й згенерувати паралельно біндінги для твоєї мови.

Тому, насправді, канонічний, класичний dkms плаче...
Треба визнати, це «камінь в город» будь-якої «додаткової» мови, що на ній дрова треба білдити разом з ядром...
Це ж потім на кожній машині окрім звичайного Сшного барахла й Сшних хедерів ядра прийдеться притарабанити ще й кожну мову, на який писаний драйвер разом з усім її барахлом та інфраструктурою типу менеджерів пакетів...