Почитал ещё раз спеку 9P. Навскидку не увидел в описании протокола обработки ситуации, когда сервер упал и рестартовал. File id недостаточно — после рестарта идентичный id может выделиться новому файлу, и клиент, который всё ещё его помнит, может обратиться не туда. Это можно закрыть через явное использование TCP, но это уже требование более высокого уровня (TRFS базируется на UDP) и нагружает протокол дополнительным слоем преобразования данных (эффективность).
Вы знаете, мне удивительно, что это надо объяснять, но Юникс — это не шелл.
Мне совершенно непонятно, почему я не могу сделать file/open в произвольной программе и набрать в качестве имени файла ftp://… или http://, потому что задача ОС — виртуализировать реальность и представлять её программам в униформном виде. И когда мне всерьёз говорят — не надо унификации в ядре, лучше мы поддержим сто разных протоколов в тысяче разных программ ручками, я слегка офигеваю.
Зачем?? Ну вот тупо — зачем нужно иметь socket/connect, если всё то же самое можно сделать через open? Я ещё понимаю (и то умеренно) зачем listen/accept — на реально большом потоке входящих парсить строку имени файла дорого (да и так ли дорого, надо посмотреть ещё). Но есть масса тривиальных программ, которые нуждаются в элементарной работе с сетью на уровне палки и верёвки.
Мало того, реализация этого в ядре — 20 строк кода на всё. Ну тупо позвать из open socket и connect, всё. Люди получили бесплатную единообразность.
Тут хорошо бы не смешивать интерфейс ОС, которым является не шелл, а слой системных вызовов, и реализацию ОС. Которая склоняет к тому, чтобы всё пихать в ядро.
Сам по себе POSIX устарел жутко — нормальным современным интерфейсом для прикладной программы, конечно, давно служит Java class lib (ну или менее богатые, но всё равно объектные интерфейсы иных ЯП), но там, где POSIX вполне применим — для доступа к байт стримам — не применять его странно. В этом смысле для работы с БД он подходит фигово, хотя, с другой стороны, выдать таблицу как входной поток для awk — почему нет.
tcp же реально активно применяется в скриптинге. актуально.
Замнём для ясности. У меня тоже нет какой-то сногсшибательной картины, которая бы явила абсолютную ясность. Разве что данный механизм проще в применении, чем тредпул, и является его заменой.
Да. Но фантом просто привязывает фиксированный файл в этой ФС к своему дисковому интерфейсу. При этом запросы преобразуются 1:1.
Блоксайз 512, как минимальный из известных мне, при этом можно запрашивать пачку секторов одним трансфёром. Запрос имеет scatter-gather структуру, ответ имеет право быть нарезан на кусочки (в меру ограничений размера UDP пакета).
http://ya.ru?text=hello возвращает всегда одни и те же данные? побойтесь бога. :)
что насчёт stat /dev/tty?
ls вернёт пустоту. облом. Хотя, конечно, можно пойти до конца: /tcp/ru/ya
реакция существующих ФС Юникса на стандартные вызовы умеренно консистента и умеренно полна. ничего нового. да хоть бы и новое. стат вернул -1 — бог мой, все умерли.
mount -t tcpfs /tcp
Мне совершенно непонятно, почему я не могу сделать file/open в произвольной программе и набрать в качестве имени файла ftp://… или http://, потому что задача ОС — виртуализировать реальность и представлять её программам в униформном виде. И когда мне всерьёз говорят — не надо унификации в ядре, лучше мы поддержим сто разных протоколов в тысяче разных программ ручками, я слегка офигеваю.
Зачем?? Ну вот тупо — зачем нужно иметь socket/connect, если всё то же самое можно сделать через open? Я ещё понимаю (и то умеренно) зачем listen/accept — на реально большом потоке входящих парсить строку имени файла дорого (да и так ли дорого, надо посмотреть ещё). Но есть масса тривиальных программ, которые нуждаются в элементарной работе с сетью на уровне палки и верёвки.
Мало того, реализация этого в ядре — 20 строк кода на всё. Ну тупо позвать из open socket и connect, всё. Люди получили бесплатную единообразность.
Сам по себе POSIX устарел жутко — нормальным современным интерфейсом для прикладной программы, конечно, давно служит Java class lib (ну или менее богатые, но всё равно объектные интерфейсы иных ЯП), но там, где POSIX вполне применим — для доступа к байт стримам — не применять его странно. В этом смысле для работы с БД он подходит фигово, хотя, с другой стороны, выдать таблицу как входной поток для awk — почему нет.
tcp же реально активно применяется в скриптинге. актуально.
куда fd засовывать?
Блоксайз 512, как минимальный из известных мне, при этом можно запрашивать пачку секторов одним трансфёром. Запрос имеет scatter-gather структуру, ответ имеет право быть нарезан на кусочки (в меру ограничений размера UDP пакета).
что насчёт stat /dev/tty?
ls вернёт пустоту. облом. Хотя, конечно, можно пойти до конца: /tcp/ru/ya
реакция существующих ФС Юникса на стандартные вызовы умеренно консистента и умеренно полна. ничего нового. да хоть бы и новое. стат вернул -1 — бог мой, все умерли.