История изменений

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

Для программиста ОС это прежде всего набор каких-то API по работе с разными подсистемами и управлением ресурсами вычислительной системы. В конечном счёте всё сводится именно к управлению ресурсами. Какие именно там сисколлы, как оно внутри реализовано, это уже как правило, дело третье. Тут… народ раздражается от идеи «цонпелять ведро», а уж как оно там унутре устроено, им это вообще лет 300 подряд ненужно даже и знать. А по временам даже вредно это знать. =)))

Я не эксперт, но разве для переключения потоков нужна прямо ОС?

Программирование для bare metal отличается тем, что круг решаемых задач сравнительно узок. По сути если, программирование bare metal это программирование конечных автоматов. Т.е., есть состояния типа «включить светодиод»/«выключить светодиод», «открыть шторы/закрыть шторы» и есть таблица переходов между этими состояниями. Чем сложнее комплекс, тем больше состояний и тем шире таблица, тем выше вычислительные расходы на каждую операцию, дороже процессор и прочий обвес. Тут лишние сложности не нужны. Они, как правило, резко снижают надёжность системы, т.к. всегда есть шанс на то, что что-то пойдёт не так и надо будет как-то отрабатывать возникшее состояние ошибки. Некоторые люди даже не научились проверять возвращаемые функцией значения и им понадобился ещё и механизм exceptions, ага. =)

Переключение потоков привнесёт (ну, по крайней мере может привнести) ряд усложнений. Т.е., состояние регистров как минимум надо сохранить для одного процесса, передать управление второму процессу, сохранить состояние регистров для него, вернуть управление первому, и так для всех процессов, которые могут быть в данный момент в системе, а их может быть более чем два. Ещё бы не забыть о возможно нужных механизмах синхронизации… Короче, это довольно дорогая по накладным расходам операция, которая привносит дополнительные сложности. Для bare metal это плохо, т.к. приходится решать нерелевантные основной задаче дополнительные задачи.

Не хватит просто упрощенной стандартной библиотеки для голого металла?

Считайте, получив такую библиотеку, Вы уже получили часть операционной системы. У Вас в таком случае уже появляется API для работы с процессами и потоками. Единственный вопрос только остаётся – что у Вас там за ОС получается. Есть в ней real time, т.е., есть фиксированные временные промежутки, в течении которых либо произойдёт переключение потока/процесса, либо таковых промежутков нет.

Кстати! Например, в Linux таких временных промежутков нет, поэтому на Linux real time в полной мере недостижим (патчи на ядро относятся только к механизмам приоретизации процессов, а в нормальных RTOS даже файловая система имеет такие временные промежутки, про потоки и не говорим, и так понятно что всё есть). Те же QNX/VxWorks и прочие узко специализированные решения таковые промежутки имеют. Поэтому они и RTOS и стоят как крыло от самолёта. Недавно смотрел вебинар, где чуваки из мира авионики рассказывали про свои проблемы – там даже многопроцессорные системы они путём не могут осилить повсеместно и за дёшево, т.к. возникают вопросы типа когерентности кешей и всё становится грустно и печально. Не всегда такой подход, связанный с реализацией такого рода библиотеки сработает «в лоб». Но если сработает, то озолотитесь. Я серьёзно. =)

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

Для программиста ОС это прежде всего набор каких-то API по работе с разными подсистемами и управлением ресурсами вычислительной системы. В конечном счёте всё сводится именно к управлению ресурсами.

Я не эксперт, но разве для переключения потоков нужна прямо ОС?

Программирование для bare metal отличается тем, что круг решаемых задач сравнительно узок. По сути если, программирование bare metal это программирование конечных автоматов. Т.е., есть состояния типа «включить светодиод»/«выключить светодиод», «открыть шторы/закрыть шторы» и есть таблица переходов между этими состояниями. Чем сложнее комплекс, тем больше состояний и тем шире таблица, тем выше вычислительные расходы на каждую операцию, дороже процессор и прочий обвес. Тут лишние сложности не нужны. Они, как правило, резко снижают надёжность системы, т.к. всегда есть шанс на то, что что-то пойдёт не так и надо будет как-то отрабатывать возникшее состояние ошибки. Некоторые люди даже не научились проверять возвращаемые функцией значения и им понадобился ещё и механизм exceptions, ага. =)

Переключение потоков привнесёт (ну, по крайней мере может привнести) ряд усложнений. Т.е., состояние регистров как минимум надо сохранить для одного процесса, передать управление второму процессу, сохранить состояние регистров для него, вернуть управление первому, и так для всех процессов, которые могут быть в данный момент в системе, а их может быть более чем два. Ещё бы не забыть о возможно нужных механизмах синхронизации… Короче, это довольно дорогая по накладным расходам операция, которая привносит дополнительные сложности. Для bare metal это плохо, т.к. приходится решать нерелевантные основной задаче дополнительные задачи.

Не хватит просто упрощенной стандартной библиотеки для голого металла?

Считайте, получив такую библиотеку, Вы уже получили часть операционной системы. У Вас в таком случае уже появляется API для работы с процессами и потоками. Единственный вопрос только остаётся – что у Вас там за ОС получается. Есть в ней real time, т.е., есть фиксированные временные промежутки, в течении которых либо произойдёт переключение потока/процесса, либо таковых промежутков нет.

Кстати! Например, в Linux таких временных промежутков нет, поэтому на Linux real time в полной мере недостижим (патчи на ядро относятся только к механизмам приоретизации процессов, а в нормальных RTOS даже файловая система имеет такие временные промежутки, про потоки и не говорим, и так понятно что всё есть). Те же QNX/VxWorks и прочие узко специализированные решения таковые промежутки имеют. Поэтому они и RTOS и стоят как крыло от самолёта. Недавно смотрел вебинар, где чуваки из мира авионики рассказывали про свои проблемы – там даже многопроцессорные системы они путём не могут осилить повсеместно и за дёшево, т.к. возникают вопросы типа когерентности кешей и всё становится грустно и печально. Не всегда такой подход, связанный с реализацией такого рода библиотеки сработает «в лоб». Но если сработает, то озолотитесь. Я серьёзно. =)