А какие существуют способы обработки ошибок выделения памяти в ядре?

Т.е., допустим, есть функция, которая возвращает адрес свободной страницы в физической памяти и диапазон виртуальных адресов, который должен быть замаплен на свежевыделенную память. Так вот если пойти прямолинейно и в "тупую" и просто пройтись по всем записям таблицы страниц, которые надо замапить и присвоить им результат функции (получается по вызову на каждую запись таблицы). Так вот, что делать если во время этого процесса выяснится, что память закончилась и удовлетворить запрос выделения памяти невозможно? Дело в том, что в результате у нас остаётся частично удовлетворённый запрос, который надо откатить. Напрашивается только 2 основных решения, либо придумать способ, чтобы такой запрос можно было действительно откатить, либо как-то заранее прикинуть сколько запрос потребует памяти, чтобы "тупой" алгоритм никогда не мог сломаться. Первый вариант, кажется не очень хорошим. Второй вариант сложноват для реализации. Есть ли варианты проще?

Стикер

потому что алгоритм надо посреди работы развернуть в обратном направлении

Знаешь историю про qnx?

откат должен работать если правильно коды возврата использовать и дерево вызовов красиво построить тогда что-то типа intermediate_page = allocated.x; if allocate_subpages.failure { deallocate(intermediate_page); return failure; } commit_pages();

не знаю ни одной

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

и почему оно висло?

Потому что ядро не должно так делать

а как оно должно делать?

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

Оно должно быть просто интерефейсом

Нее, просто надо делать ролбэк

у меня Result<T,E> зачем мне коды еще я про общую структуру как это должно работать, реализуйте как удобнее

а что делает commit_pages&

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

на стек закинуть не вариант?

стек не резиновый

ну ты же в одном вызове это делаешь

или страничку под номера строниц выделить

А зачем нужно искать страницу для ядра? Смаппить в уже известное место нельзя?

вопроса в том куда мапить нет

А, извиняюсь, я чет не сразу понял, при чем здесь странички. В таком случае, у тебя память может только у физического аллокатора закончится, но тогда уже делать нечего, мне кажется:)

про этот случай речь и идёт, возможно я не совсем правильно пояснил, прошу прощения если где-то ввёл в заблуждение

Ну если маппинг страниц норм сделан то можно утилизировать, по сжимать или же посвоппить на диск

вот только диска нет, чтобы свопить

А почему нет диска?

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

А ты планируешь oom словить на инициализации?

если у тебя пиздец на инициализации происходит то иди читай посты Brendan-а на осдев форуме

если катастрофически мало памяти

А для чего ты ос делаешь что у тебя просрана память еще до работы с фс?

Стикер

Ты под avr с 512 байт рамы пишешь штоль?

ну нет

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

тогда тебе точно за брендановскими постами

а что в них такого?

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

Ты ракеты делаешь?

Тогда тебе надо писать на расте или аде

нет, конечно

не думаю, что это чем-то сильно поможет

ну на аде секьюрненько

Поможет, вдруг ты будешь писать мимо массива

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

сишников ожидает неприятный сюрприз - ВЕЗДЕ

Даже при похоже в уборную

Ну можно еще предложить frama-c и канистру вазелина.

Не помогает

Если не знать что проверять то ничего наверное и не поможет уже.

после асма сишные компили тоже говорят что перед монитором дурак сидит