The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Дискуссия об использовании языка C++ для разработки ядра Linux, opennews (??), 14-Янв-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


31. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (31), 14-Янв-24, 22:34 
В ядре тоже нету VLA. В стандаре C99 было, но потом, поняв ошибку, сделали это в следующем стандарте  опциональным.
Ответить | Правка | Наверх | Cообщить модератору

58. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (58), 14-Янв-24, 23:38 
А в чём проблема VLA? Лучше с alloca и указателями для того же самого геморроиться и статическому анализатору палки в колёса ставить?
Ответить | Правка | Наверх | Cообщить модератору

70. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +1 +/–
Сообщение от Аноним (-), 14-Янв-24, 23:54 
> А в чём проблема VLA? Лучше с alloca и указателями для того же самого
> геморроиться и статическому анализатору палки в колёса ставить?

В том что...
1) Никогда не знаешь когда этот код навернется.
2) Способов узнать навернется ли он - нет.
3) В стандартах "C" нет слова "стэк" от слова вообще.
4) Поэтому вы в душе не и...те сколько его доступно и плохо ли arr[n] или прокатит.

А теперь представьте что у вас по рандому будет грохаться ЯДРО по причине "переполнение стека". Как вам такая перспектива? Этот аспект конечно существует всегда но с именно VLA он вылезает наиболее зло и часто. Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000. При том вы даже узнать не можете ок ли такой n или нет. В отличие от мануальной аллокации где хотя-бы зввернут. А тут - сразу SIGSEGV какой бу, или что там. Круто, да?!

Ответить | Правка | Наверх | Cообщить модератору

99. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  –1 +/–
Сообщение от Аноним (99), 15-Янв-24, 01:30 
От переполнения стэка ни один код не защищён. И ни один код не защищён от исчерпания памяти.

> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000.

При таком n, даже если всё в куче будет, на большинстве компов грохнется. И всё тут. И там и там надо ограничивать разрешённые значения N.

Ответить | Правка | Наверх | Cообщить модератору

106. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  –1 +/–
Сообщение от Аноним (115), 15-Янв-24, 02:08 
Всего лишь 100Мб, не грохнется. Тем более запрос через аллокатор никогда не приведёт к сваливаю
Ответить | Правка | Наверх | Cообщить модератору

126. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (126), 15-Янв-24, 02:51 
Тьфу, действительно мегабайт, перепутал с гигами.

>Тем более запрос через аллокатор никогда не приведёт к сваливаю

С выделением на стеке тоже можно проверять, не случится ли переполнения. Но built-inа для этого в компиляторах нет.

Ответить | Правка | Наверх | Cообщить модератору

127. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (115), 15-Янв-24, 02:56 
Но почему-то проверок места на стеке нигде нет
Ответить | Правка | Наверх | Cообщить модератору

297. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 15-Янв-24, 14:10 
> Всего лишь 100Мб, не грохнется.

1) Ну попробуй так на AtMega какой-нибудь :). Правда, грохаться этот убогий не умеет чисто технически, ибо хардварных exceptions у авр нет как класса - но каким-нибудь интересным глюком в корчах в его фирмваре наверное воздастся.

2) Даже если это ОС - а ты уверен что сто мегов в вот именно стеке процесса таки дадут?

> Тем более запрос через аллокатор никогда не приведёт к сваливаю

Это не обязан быть запрос через аллокатор... одна из причин по которым операции на стеке быстрее операций в heap.

Фича стека в том что он аллоцируется и деаллоцируется автоматически, чаще всего с нехилым подпором железом. Антифича состоит в том что вы не можете узнать прокатило это или нет иначе как fault handler'ом "все пропало шеф!" в тыкву (или жесткими глюками если оно так не умело).

Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

326. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  –1 +/–
Сообщение от Аноним (115), 15-Янв-24, 15:34 
Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти? Речь про кучу, если вдруг проблемы с чтением

> Фича стека в том что он аллоцируется и деаллоцируется автоматически, чаще всего с нехилым подпором железом.

Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны железа самая топорная

Ответить | Правка | Наверх | Cообщить модератору

405. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 15-Янв-24, 20:23 
> Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти?

А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется? А вот и хрен, это проц аппаратное исключение кинул на самом деле.

> Речь про кучу, если вдруг проблемы с чтением

В ней в конечном итоге тоже - память либо выделят, либо при левых поползновениях SIGSEGV будет. На самом деле в линухе при оверкоммите (т.е. по дефолту) это не сильно лучше стека ибо де факто аллокация "виртуальная" и ничем не обеспечена. Реальное выделение только при обращении. Связано с тем что многие программы заказывают намного больше памяти чем реально юзают, и это позволяет на доступном RAM нафоркать сильно больше процессов, соответственно.

Ценой некоей утратой предсказуемости - ибо ежели страница понадобилась - но ее нет - у вас *alloc вроде прокатил но это как бы и не обеспечено и нате-ка вам SIGSEGV. Но на внутренности кернела это не распостраняется.

> Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны
> железа самая топорная

У heap и такой нет - поэтому аллокации и деаллокации многократно тормознее.

Ответить | Правка | Наверх | Cообщить модератору

426. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 15-Янв-24, 22:45 
> Какое отношение аппаратные исключения имеют к условному libc, или аллокатору памяти?

А ты думал, штуки типа SIGSEGV из воздуха чтоли материализуется? А вот и хрен, это проц аппаратное исключение кинул на самом деле.

> Речь про кучу, если вдруг проблемы с чтением

В ней в конечном итоге тоже - память либо выделят, либо при левых поползновениях SIGSEGV будет. На самом деле в линухе при оверкоммите (т.е. по дефолту) это не сильно лучше стека ибо де факто аллокация "виртуальная" и ничем не обеспечена. Реальное выделение только при обращении. Связано с тем что многие программы заказывают намного больше памяти чем реально юзают, и это позволяет на доступном RAM нафоркать сильно больше процессов, соответственно.

Ценой некоей утратой предсказуемости - ибо ежели страница понадобилась - но ее нет - у вас *alloc вроде прокатил но это как бы и не обеспечено и нате-ка вам SIGSEGV. Но на внутренности кернела это не распостраняется.

> Нет у стека деаллокаций и какого-то 'нехилого подпора железом', поддержка со стороны
> железа самая топорная

У heap и такой нет - поэтому аллокации и деаллокации многократно тормознее.

Ответить | Правка | К родителю #326 | Наверх | Cообщить модератору

533. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от n00by (ok), 16-Янв-24, 15:00 
>> Всего лишь 100Мб, не грохнется.
> 1) Ну попробуй так на AtMega какой-нибудь :).

Это и на AMD64 не работает.

Ответить | Правка | К родителю #297 | Наверх | Cообщить модератору

124. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +2 +/–
Сообщение от Аноним (-), 15-Янв-24, 02:49 
> От переполнения стэка ни один код не защищён. И ни один код
> не защищён от исчерпания памяти.

Если я статически пишу uint8_t arr[10]; я имею основания полагать что это будет работать даже на микроконтроллере с склерозом вместо памяти, и если этот код вообще запустился то скорее всего работает до упора.

Есди я динамически аллоцирую память и ее ен было - то там по крайней мере вернут ошибку и я могу ее прочекать. И что-то сделать по этому поводу.

Но если это будет


void func1 (uint32_t n) {
  uint8_t arr[n]; // VLA!
  // do something with arr[] here
}

...и вызывать func1(10); func1(100); func1(100500); ...  то я вообще не знаю на каком n оно грохнется. И нет никаких способов это узнать, кроме как грохнувшись. Если *alloc еще фэйлить хотя-бы могут, то тут о фэйле узнаем только путем краха/системного факапа. Круто, да? Особенно в кернеле. Вы же будете очень рады что кернел в панику $%^нется без предупрежления, да?! Вместо фэйла внутренних операций, retry выделения памяти и прочих глупостей.

>> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000.
> При таком n, даже если всё в куче будет, на большинстве компов грохнется.

В случае динамической аллокации я как бы могу проверить успех операции. А тут сразу крах в репу, обработать нехватку памяти вообще совсем никак нельзя. И поскольку это рантайм параметр - получается код который очень ненадежный, скажем так, и может просто грубо навернуться если параметр неудачный. Без какой либо адекватной обработки этого вообще.

> И всё тут. И там и там надо ограничивать разрешённые значения N.

Просто крах без предупреждения, в рантайме, без возможности это обработать - может и ок для питоняш, но в системном яп - такое себе.

Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

138. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +1 +/–
Сообщение от jjklh (?), 15-Янв-24, 03:25 
>Просто крах без предупреждения, в рантайме,

кто сказал раст?

Ответить | Правка | Наверх | Cообщить модератору

139. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  –2 +/–
Сообщение от Аноним (149), 15-Янв-24, 03:28 
>Просто крах без предупреждения, в рантайме, без возможности это обработать - может и ок для питоняш, но в системном яп - такое себе.

Сишечка не системная - также можно исчерпать стек, вызывая функции. Особенно если где-то там, в глубине вызовов, будет на стеке буфер, не VLA, но и не очень маленький - есть вероятность, что почти всегда из него будет использоваться пару байт, а иногда столько, что хватит для переполнения стека.

VLA, конечно, усугубляет, но сишечка сама по себе неадекватна задачам сиспрога например.

Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

283. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +1 +/–
Сообщение от Аноним (-), 15-Янв-24, 13:29 
> Сишечка не системная -

Да? А кто у нас тогда системный то? На сях что-то большая часть системщины, бутлоадеры, кернелы, фирмвари, либы, вот это все :). И у других - failure mode еще больше так то. В сях они простые и понятные как правило и их немного.

> также можно исчерпать стек, вызывая функции. Особенно если
> где-то там, в глубине вызовов, будет на стеке буфер, не VLA,
> но и не очень маленький -

Одна из причин по которым жирное использование стека в функциях считается чем-то нехорошим, и кернел собирается с варнингом на размер стекфрейма, если что. По моему если у функции стек более кило - нате вам варнинг, во!

Кстати с современным компилером допустим сожрать стек рекурсией не так то просто, gcc допирает убрать сохранение-восстановление, копирование объекта и проч - и лианеризует рекурсивный вызов до чего-то типа цикла, с потреблением стека O(1) и временем выполнения O(n). И вот я вкатил рекурсию чтобы проверить работает ли мой детект stack overflow на мк и.. это не падает?! Ах ты ж блин, какой умный компилер! А чо, ассемблерщики, сможете оптимизнуть так же? :)

> есть вероятность, что почти всегда из него будет использоваться пару байт, а иногда
> столько, что хватит для переполнения стека.

Поэтому...
1) Там где это важно чекают stack usage функций.
2) MISRA запрещает рекурсивные вызовы например, и системный софт должен намотать на ус эту идею и так не делать.

> VLA, конечно, усугубляет, но сишечка сама по себе неадекватна задачам сиспрога например.

Ну вы то нам покажете что-то лучше? А то уж рекурсию можно на чем угодно, даже на асме, и тот кстати без оптимизаций - не будет линеаризовывать рекурсивный вызов до более плоского цикла и там все грохнется куда охотнее :)

Ответить | Правка | Наверх | Cообщить модератору

140. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +1 +/–
Сообщение от Аноним (140), 15-Янв-24, 03:29 
В некоторых компиляторах есть builtin, позволяющий проверить наличие места на стеке. Где нет - его можно сделать. По-хорошему должен быть вариант alloca с проверкой. Но нет. По-хорошему должен быть VLA с проверкой на успех. Но Си - это не раст.
Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

292. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +1 +/–
Сообщение от Аноним (-), 15-Янв-24, 13:50 
> В некоторых компиляторах есть builtin, позволяющий проверить наличие места на стеке. Где
> нет - его можно сделать. По-хорошему должен быть вариант alloca с
> проверкой. Но нет. По-хорошему должен быть VLA с проверкой на успех.

Просто вопрос был почему VLA не рекомендуют в системщине. Ну вот потому. В сях вообще нет ни слова про "stack" в спеках. И, в принципе, VLA не обязан жить именно в стеке. Однако проблема того что память не бесконечная а какая-то реакция на ее нехватку невозможна - остается в любом случае.

> Но Си - это не раст.

Что-то мне подсказывает что у хруста других failure modes - на десяток си хватит. Они вон там свой panic любимый едва законопатили, меняя чуть не сорц компилера аж когда оказалось что в ядре panic это не оч хороший способ реакции на нехватку памяти. Там же и сказочные костыли с try-вариантами конструкций. Господи, какой бастардизированый гибрид сей с которыми боролись и чего-от из плюсоты, все хучшее от обоих миров - в один яп?!

Ответить | Правка | Наверх | Cообщить модератору

375. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (375), 15-Янв-24, 18:48 
>VLA не обязан жить именно в стеке

Локальные переменные живут в стеке. VLA в принципе может жить где угодно, но нужен он именно на стеке.

>Они вон там свой panic любимый едва законопатили

panic!ует код тогда, когда не обработана ошибка, в частности наиболее распространённый случай - когда на std::result вызывают unwrap. В системном кодe необработанных ошибок быть не должно - это путь либо к уязвимости, либо к kernel panic. rust это просто подсвечивает.

Ответить | Правка | Наверх | Cообщить модератору

429. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 15-Янв-24, 23:02 
> Локальные переменные живут в стеке. VLA в принципе может жить где угодно,
> но нужен он именно на стеке.

Читайте стандарты си. Там вообще нет упоминания стека, никак и нигде. То что конкретные реализации решили делать так - ну, окей, однако если кто-то сделает это иначе, он - в своем праве. Это implementation defined хрень. Вы не можете уповать на это при написании программы. Поэтому если кто-то вывесит VLA через heap или что там у него - а они в своем праве были.

У си довольно интересные стандарты - и далеко не всегда это именно похвала комитету. Спихнувшему более 9000 своих проблем на других.

>>Они вон там свой panic любимый едва законопатили
> panic!ует код тогда, когда не обработана ошибка,

Я так понимаю что паника была дефолтовой реакцией на неуспешные потуги аллокации крупных массивообразных штук, box чтоли, они там называются.

И дошли они в результате до костылирования с тем же названием с довеском try отличающим по поведению эту сущность. Я честно говоря не понял почему все так костыльно и почему они так героически заборов дракона вдруг заметили что без него что-то стало хреново - и немедленно превратились в еще более стремного на вид дракона. Пппростите, а чем ЭТО отличалось от *alloc и сотоварищи? Можне мне этот высококонцептуальный пируэт объяснить? В результате маркетинг оказался, как бы это, не совсем правдой. Ибо в итоге пришли к тому с чем боролись. Фэспалм.

> в частности наиболее распространённый случай - когда на std::result вызывают unwrap.

А в кернеле и вообще embedded, etc вот именно тот std вообще будет? Ибо врядли дефолтовый, из супер-дупер-либы на все оказии делает именно то что уместно делать в недрах кернела. И скорее всего подразумевает работу в нормальной ос. А что если этой нормальной ос еще нет?!

> В системном кодe необработанных ошибок быть не должно - это путь либо к уязвимости,
> либо к kernel panic. rust это просто подсвечивает.

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

Представьте себе что для написания кернела требовалось бы постоянно патчить GCC. Вы бы вообще смогли кернел написать в результате? Да и Торвальдс, пожалуй, тоже.

Ответить | Правка | Наверх | Cообщить модератору

146. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (149), 15-Янв-24, 03:41 
>Если я статически пишу uint8_t arr[10]; я имею основания полагать что это будет работать даже на микроконтроллере с склерозом вместо памяти, и если этот код вообще запустился то скорее всего работает до упора.

Конечно, не будет. Во всех тестах в массив будут записаны 1-3 байта и они ничего не поймают, в продакшоне наконец-то в этот массив запишут из сети 10 байт, запись затрет канарейки и структуры планировщика FreeRTOS, лежащие прямо за концом стека, задача вместо паники зависнет и девайс ребутнется по ватчдогу.

Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

290. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 15-Янв-24, 13:45 
> Конечно, не будет. Во всех тестах в массив будут записаны 1-3 байта
> и они ничего не поймают, в продакшоне наконец-то в этот массив
> запишут из сети 10 байт, запись затрет канарейки и структуры планировщика
> FreeRTOS, лежащие прямо за концом стека, задача вместо паники зависнет и
> девайс ребутнется по ватчдогу.

Это всякие системные ламеры, обложивщиеся RTOS не поймают, у них "тойота" и получается. А я посмотрел на тойоту. Подумал. И теперь - даже на Cortex-M без MPU научился делать лэйаут RAM где переполнение стека хоть на байт немедленно эскалирует в HARD FAULT (нет, не MPU, его нет), который не заметить очень сложно. Ибо самый суровый эксепшн на все ядро, выбивающий все кроме NMI нафиг. И теперь мы займемся реакцией на вот это, зная что в системе Ж, ждать вачдог не обязательно.

...а еще я таки сделал обработчикам приватный стек, так что они еще и что-то сделать могут. Даже если основной стек кончился. У ARM для этого довольно клевая фича есть, отдельный стек для handlers.

...кроме того я заинструментил немного наколенный, но весьма забавный анализ worst-case рантайм потребления стека. Идея проста: заполняем раму паттерном в startup, пускаем фирмвару работать, если знаем самые ресурсоемкие ветки, прозваниваем их. Через некоторое время просим дамп оперативы, смотрим на регион стека, делаем выводы о runtime margins.

Ответить | Правка | Наверх | Cообщить модератору

345. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Tron is Whistling (?), 15-Янв-24, 16:42 
Главное, чтобы у тебя этот суровый(r) эксепшн(tm) не произошёл во время полёта на обоих модулях - основном и запасном...
Ответить | Правка | Наверх | Cообщить модератору

413. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от nothingaboutdog (?), 15-Янв-24, 20:45 
А как он может не произойти, если искандер-5 заходит на цель с перегрузкой в 30 раз больше, чем искандер-4 (и памяти для искандер-4 строго говоря не хватало, но с учетом ограничений ТТХ кулибины как-то зарелизились)???
Ответить | Правка | Наверх | Cообщить модератору

431. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 15-Янв-24, 23:08 
> Главное, чтобы у тебя этот суровый(r) эксепшн(tm) не произошёл во время полёта
> на обоих модулях - основном и запасном...

Если это важно - это решается другими методами. См. как это кажется, боинг сделал. Две тимы писали 2 разные программы, запущенные на 2 разных процах, ... вот как раз чтобы вероятность этого была ниже плинтуса.

...у меня, к счастью, не настолько крутые требования, и все же мне охота залезть в довольно требовательные применения, где факап управления может чего-нибудь пожечь и проч, что как бы не прикольно. В этом смысле fail fast с приведением системы в безоапсное состояние лучше чем ждать вачдога в абы каком состоянии, делая хзчто.

Ответить | Правка | К родителю #345 | Наверх | Cообщить модератору

503. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Tron is Whistling (?), 16-Янв-24, 11:27 
Не гидравлический пресс надеюсь?
А то fail fast может в fall fast перейти :D
Ответить | Правка | Наверх | Cообщить модератору

504. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Tron is Whistling (?), 16-Янв-24, 11:28 
Мне у некоторых софтсвитчей вот этот fail fast нравится.
Да пусть оно лучше сессию дропнет, наплюёт херни в логи, или выдаст в сессию шум океанов марса.
Нежели все 100500 звонков разом лягут.
Ответить | Правка | К родителю #431 | Наверх | Cообщить модератору

677. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 21-Янв-24, 20:56 
> Мне у некоторых софтсвитчей вот этот fail fast нравится.
> Да пусть оно лучше сессию дропнет, наплюёт херни в логи, или выдаст
> в сессию шум океанов марса.
> Нежели все 100500 звонков разом лягут.

Софт свич несколько отличается от печатки с силовухой, допустим. Одно дело по превышению тока сразу в safe state свалить, и совсем другое - подождать вачдога, который там дескать может ребутнет, но до того момента - силовые ключи - и половина платы - правратятся в чуть ли не кусок плазмы уже, и тогда х... толку с вачдога?! Даже если проц и перезагрузится - то чего? В этот момнет уже поздняк на превышение тока реагировать и что-то выключать.

Ответить | Правка | Наверх | Cообщить модератору

680. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Tron is Whistling (?), 21-Янв-24, 22:17 
Если у вас на плате нет защиты от превышения тока кроме софта - я вам очень сочувствую, и да, можно название, чтобы это не брать никогда?
Ответить | Правка | К родителю #677 | Наверх | Cообщить модератору

687. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 23-Янв-24, 22:14 
> Если у вас на плате нет защиты от превышения тока кроме софта

По законам Мерфи - устройство порой сгорает первым, защитив предохранитель ;)

И FYI, предохранитель нельзя брать впритык - иначе периодически его будет выбивать "без причины". А еще пусковые кратковременные режимы бывают куда тяжелее крейсерских. Это не значит что они вдолгую безопасны. Работает этот мир так. Но чтобы об этом знать надо немного поинженерить. Так что лишняя линия защиты никому не мешала еще.

Алсо вылетевший предохранитель это прерывание сервиса, доволно надолго. Self restart после устранения проблемного условия - лучше чем трах с сменой предохранителя.

По причинам выше - быстродействующий предохранитель, "на грани" - не захочется. Ибо придется постоянно заниматься его заменой. А то что медленный обгонит дестрой ключа крутым перегрузом... ну вот не факт. И вот там МК, которому микросекунды дом родной, имеет шансы зарубить проблемное условие ДО того как это станет проблемой. При том он в отличие от глупого предохранителя в курсе, startup это или авария, допустимо ли столько времени, или уже перебор, и так далее. И можно вон те неудачные соотношения несколько обойти.

> - я вам очень сочувствую, и да, можно название, чтобы это
> не брать никогда?

...сказал тип, стесняющийся уточнить название своего прова за отношение в ipv6 :). Впрочем можете не париться - я масспродом не занимаюсь и ваши шансы купить сие весьма низкие.

Ответить | Правка | К родителю #680 | Наверх | Cообщить модератору

688. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Tron is Whistling (?), 23-Янв-24, 22:16 
А ваш софт умеет думать, пока МК дымится вместе с платой? :)
Ответить | Правка | К родителю #687 | Наверх | Cообщить модератору

689. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Tron is Whistling (?), 23-Янв-24, 22:32 
Почему? Потому что по законам Мерфи первым сдохнут датчики для вашего софта.
Ответить | Правка | К родителю #687 | Наверх | Cообщить модератору

358. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (341), 15-Янв-24, 17:59 
Как я понял твои ответы.
- Если мы используем массив со статическим временем жизни, то мы надеемся, что стек не переполнится.
- Если мы используем обычный массив на стеке, то мы надеемся, что стек не переполнится.
- Если мы используем VLA-массив, то много энергично говорим и надеемся, что стек не переполнится.
Ответить | Правка | К родителю #290 | Наверх | Cообщить модератору

434. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 15-Янв-24, 23:21 
> Как я понял твои ответы.
> - Если мы используем массив со статическим временем жизни, то мы надеемся,
> что стек не переполнится.

И мы можем более адекватно эту идею проверить. Частично даже в компилтайме, смотрением на размер стекфрейма.

> - Если мы используем обычный массив на стеке, то мы надеемся, что
> стек не переполнится.

Это допущение опять же более просто проверить, если нет рекурсии.

> - Если мы используем VLA-массив, то много энергично говорим и надеемся, что
> стек не переполнится.

VLA - это еще хуже чем динамическая аллокация памяти. Потому что это та же динамическая аллокация памяти - но еще и без возможности сделать что-либо осмысленное, и без известного на момент компила upper bound что вообще совсем рубит любой компилтайм анализ этого. Вы вообще не знаете worst case размер стекфрейма этой функции теперь.

И таки си - мультипарадигменный. Если ну вот капец как надо - можно сделать "fully static allocation", распределив вообще все статически. Ну то-есть все переменные сделать либо static в функциях, либо глобальными. И тогда - если все выделено сразу на старте, оно не может закончиться вот хоть как. Единственное что остается это глубина вложенных вызовов функций. Это неоптимально по ресурсам - потому что все и вся выделено всегда. Зато гарантии лучше. Вот и выбирайте.

Примерно такой же tradeoff существует и в оверкоммите памяти в случае линуха. Можете не оверкомитить и обеспечивать все выделеные адреса физической оперативой. Но тогда сможете намного меньше программ на том же RAM запускать.

Ответить | Правка | Наверх | Cообщить модератору

462. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (341), 16-Янв-24, 01:39 
Я почему шучу про "много энергично говорим" - потому что идеи assert'ов для размера VLA,  тестирования худшего случая отметаются как немыслимые и тебя куда-то совсем понесло. "Еще хуже чем динамическая аллокация памяти" - вот, фрагментация кучи уже лучше, чем VLA. Даже не "так же плоха", как написала бы MISRA, а хуже.

> Это неоптимально по ресурсам - потому что все и вся выделено всегда

В принципе на этот случай есть union'ы, но с ними придётся следить не за стеком, а за тем, чтобы не было обращений к неактивным полям и чтобы инициализация активного поля нигде не пропускалась.

Ответить | Правка | Наверх | Cообщить модератору

651. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (-), 19-Янв-24, 19:38 
> Я почему шучу про "много энергично говорим" - потому что идеи assert'ов
> для размера VLA,  тестирования худшего случая отметаются как немыслимые

Не то что немыслимые - а "еще хуже чем динамическая аллокация". Ибо еще менее defined и еще меньше возможностей для корректной реакции.

А что должен кернел сделать по assertion failed? В панику брякнуться? Ну, зашибись реакция, конечно. Юзерям понравится. Retry выделения в этой парадигме вообще не получится (смысл повторять тот же assertion?!), вернуть caller'у ошибку - наверное не assert тоже было. И получается как вон то - только еще хуже, ибо грабель больше и контроля над ручкой нет, грабля автоматически подпрыгивает и лупит в лоб всех кто проходит мимо.

> и тебя куда-то совсем понесло. "Еще хуже чем динамическая аллокация памяти" -
> вот, фрагментация кучи уже лучше, чем VLA.

Внезапные крахи и почти полная невозможность их адекватного парирования спускают си до уровня питоняш и нафиг нам такой си вперся вообще?

> В принципе на этот случай есть union'ы, но с ними придётся следить
> не за стеком, а за тем, чтобы не было обращений к
> неактивным полям и чтобы инициализация активного поля нигде не пропускалась.

Я даже примерно так (изредка и немного) делаю - но при этом желательно сделать некий interlock ресурса, для проверки использования, иначе так окажется что мы тут храбро юзали массив - а вон там сетапнули DMA, забыли про это, все счастливо пахало... пока DMA не добрался до нас и не протер все к хренам другими данными... а мы не понимаем - откуда, блин, это вообще вот так?!

Ответить | Правка | Наверх | Cообщить модератору

166. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  –1 +/–
Сообщение от n00by (ok), 15-Янв-24, 06:49 
> От переполнения стэка ни один код не защищён.

Дожили. А вот ядро Windows NT - защищено. Потому что там стек не используют и таких как ты не подпускают.

Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

227. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от n00by (ok), 15-Янв-24, 10:54 
Для особо одарённых, кто судит по себе и считает это троллингом: https://learn.microsoft.com/en-us/windows-hardware/drivers/k...
Ответить | Правка | Наверх | Cообщить модератору

509. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от freehckemail (ok), 16-Янв-24, 12:30 
> А вот ядро Windows NT - защищено. Потому что там стек не используют и таких как ты не подпускают.
> Для особо одарённых, кто судит по себе и считает это троллингом: https://learn.microsoft.com/en-us/windows-hardware/drivers/k...

И по ссылке написано, дословно, "под стэк выделено суммарно три страницы, так старайтесь делать дерево вызовов плоским, а рекурсивным вызовам поставьте ограничитель, потому что переполнение приведёт к фатальной ошибке системы".

Ответить | Правка | Наверх | Cообщить модератору

534. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от n00by (ok), 16-Янв-24, 15:13 
>> А вот ядро Windows NT - защищено. Потому что там стек не используют и таких как ты не подпускают.
>> Для особо одарённых, кто судит по себе и считает это троллингом: https://learn.microsoft.com/en-us/windows-hardware/drivers/k...
> И по ссылке написано, дословно, "под стэк выделено суммарно три страницы, так
> старайтесь делать дерево вызовов плоским, а рекурсивным вызовам поставьте ограничитель,
> потому что переполнение приведёт к фатальной ошибке системы".

Надо перевести на понятный? Стек крайне осторожно используется для хранения адресов возврата, ни слова про размещение там array, а тем более variable length.

Ответить | Правка | Наверх | Cообщить модератору

536. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от freehckemail (ok), 16-Янв-24, 15:27 
Боюсь, что это ты не понял. Данная статья просто предостерегает разработчиков о том, что стек имеет весьма ограниченный размер, и даёт указания, как с ним следует работать. Ни о какой защите речи не ведётся. Это самый обычный стек.
Ответить | Правка | Наверх | Cообщить модератору

550. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от n00by (ok), 16-Янв-24, 16:10 
Очевидно, это ты не понял смысл "таких ... не подпускают". Защита стека в Windows выполняется административными методами. И вот таких, кто ничего не написал под ядро, но чему-то учит относительно стека, там не подпускают тоже.
Ответить | Правка | Наверх | Cообщить модератору

553. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от freehckemail (ok), 16-Янв-24, 16:27 
> Защита стека в Windows выполняется административными методами.

Ух едрить как же всё запущено. Ну, с тем же успехом можно сказать, что код защищён от багов, потому что все MR-ы проходят обязательный code review. =)
Зачёт, нуби. Завести что ли где-нибудь на опеннете мемориз с глупостями... =)

Ответить | Правка | Наверх | Cообщить модератору

564. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от n00by (ok), 16-Янв-24, 17:45 
>> Защита стека в Windows выполняется административными методами.
> Ух едрить как же всё запущено. Ну, с тем же успехом можно
> сказать, что код защищён от багов, потому что все MR-ы проходят
> обязательный code review. =)
> Зачёт, нуби. Завести что ли где-нибудь на опеннете мемориз с глупостями... =)

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

Вот только я не спорю, а сообщаю факт: вопросом про стек отсеивают всех умельцев работать лишь языком, в самом начале собеседования.

Ответить | Правка | К родителю #553 | Наверх | Cообщить модератору

637. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от Аноним (637), 19-Янв-24, 00:04 
Размер стека можно задать каким нужно, вызвав соответствующую функцию. Это он по-умолчанию такой, потому что "12 килобайт хватит каждому". А кому не хватит - тот может затребовать больший.
Ответить | Правка | Наверх | Cообщить модератору

641. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от n00by (ok), 19-Янв-24, 14:58 
> Размер стека можно задать каким нужно, вызвав соответствующую функцию.

Формулировка некорректна. Можно _попробовать_ задать размер.

KeExpandKernelStackAndCallout
...
Returns success if the stack allocation is successful and the callout has been called. Otherwise, returns a failure status.

> Это он по-умолчанию
> такой, потому что "12 килобайт хватит каждому". А кому не хватит
> - тот может затребовать больший.

А кому в итоге не хватит?

Running out of kernel stack space causes a fatal system error. Therefore, it is better for a driver to allocate system-space memory than to run out of kernel stack space.

Если даже до этого не дочитали, то до описания KeExpandKernelStackAndCallout и понимания, зачем она вообще нужна, тем более не дошло.

Ответить | Правка | К родителю #637 | Наверх | Cообщить модератору

251. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +/–
Сообщение от _kp (ok), 15-Янв-24, 12:17 
> не защищён от исчерпания памяти.
>> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000.

Хорошо, n=55666, но память процесса переполнена.
Или переполнена иным, более естественным способом.

Что сделает ПО безопасном языке? Да точно так же грохнется,толко некролог подробнее выдаст, но это не точно.

Во встраиваемом ПО можно генерировать прерывания, при попытке выхода за границы области стека или его части, но не везде это делается очевидным и удобным способом.
Но и тут, по исчерпании памяти можно только перезапустить ПО, максимум с частичным сохранением состояния.

Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

295. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  +1 +/–
Сообщение от Аноним (-), 15-Янв-24, 14:00 
>> не защищён от исчерпания памяти.
>>> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000.
> Хорошо, n=55666, но память процесса переполнена.
> Или переполнена иным, более естественным способом.

Я знаю что сделает нормальный системщик.
1) Запретит такую конструкцию если без нее можно обойтись.
2) Если нельзя, аллоцирует динамически - и проверит успех. А если неуспех, что-то сделает по этому поводу, от вываливания из программы до retry через некоторое время в надежде что память освободилась (так например некоторые БД делают, вместо того чтобы сразу завернуть, предпринимают несколько попыток, и сдаются только если за энное время не полегчало).

> Во встраиваемом ПО можно генерировать прерывания, при попытке выхода за границы области
> стека или его части,

В обычных программах примерно то же самое известно как какой-нибудь SIGSEGV и в POSIX эта модель по сути и остается. Проц получает исключение от MMU, и кернел в общем то гейтует его программе как сигнал SIGSEGV. Дефолтный хэндлер просто вырубает прогу, но можно и свой прицепить и сделать что-то более продвинутое.

Однако если вам приехал fault handler по причине "стек кончился" - ну, э, удачи в корректном возобновлени работы программы. Ведь стека уже не хватило, состояние в "основном потоке" в общем то уже урыто. Корректного гарантированого способа вернуться их хэндлера в основную тушку на этот момент уже не существует в общем случае.

> Но и тут, по исчерпании памяти можно только перезапустить ПО, максимум с
> частичным сохранением состояния.

Окончание стека это весьма грубый системный факап. Ведуший к очень голимым последствиям. Тойота проверяла. Получив class action lawsuit от злющих родственников усопших водил и тех кому острые ощущения от вождения не понравились.

Ответить | Правка | Наверх | Cообщить модератору

165. "Дискуссия об использовании языка C++ для разработки ядра Lin..."  –1 +/–
Сообщение от n00by (ok), 15-Янв-24, 06:48 
> А в чём проблема VLA? Лучше с alloca и указателями для того
> же самого геморроиться и статическому анализатору палки в колёса ставить?

Проблема в том, что это ядро. Вот скажи, какой там размер стека?


Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру