С USBIP та проблема, что в нём не предусмотрен PnP. Т.е., можно воткнуть и "примонтировать" устройство, но если оно отсоединится (например, из-за того, что драйвер сделает reset), оно отвалится.
А хотелось бы, чтобы клиенты автоматически получали нотификации о появлении новых устройств и автоматически их "монтировали" (вероятно, не все подряд, а по каким-то критериям).
Не знаю, может если бы USBIP сервер экспортировал бы не конечные устройства, а виртуальный USB hub, как устройство, это бы и работало. Но линуксный сервер так не умеет.
Вы странно приравниваете "системное ПО" и "высоконагруженное ПО".
Системное ПО - это часть системы. Оно создаёт инфраструктуру для жизни других программ, а не решает прикладные задачи.
Совсем не обязательно, чтобы оно было высоконагруженным.
Так что докер, snapd и т.п. я бы отнёс к системному ПО.
У ядра тут особое положение. Ему принадлежит аппаратура и через него проходит вся коммуникация между процессами. Так что ему приходится быстро крутиться.
Закрытие файла, вообще-то, это операция, возвращающая результат. В котором есть смысл (например, если файл был открыт с правом на запись, то именно от ответа close() мы знаем, что всё записанное окончательно прописалось).
А если close - это неявная операция в рамках RAII, куда результат-то девается?
Иммунолог Дерья Унутмаз заявил, что методы омоложения уже существуют, и остаётся лишь дождаться технологий, которые сделают их массовыми. По его прогнозу, это займёт 5–10 лет, и в течение ближайших двадцати лет человек сможет вернуть себе молодость. Восьмидесятилетний сможет снова стать двадцатилетним.
Что-то слабо верится.
Раньше люди умирали в основном от травм и инфекционных заболеваний. Их в основном победили, горизонты раздвинулись, и люди стали доживать до рака и инсультов-инфарктов. Которые раньше не составляли особой проблемы потому, что до них мало кто доживал. Победят сегодняшние причины смертности, окажется, что впереди нас ждёт что-то еще, не сильно более приятное.
Хуже всего, если окажется, что тело может и 200 лет прожить, а мозги после 120 массово отказывают. Так и будем жить, дееспособное и небогатое меньшинство в окружении богатых маразматиков, которые могут себе это позволить.
Правда с другой стороны, Go вроде уже перестал поддерживать версии венды, которые не умеют в AF_UNIX.
Ну и в вендовых UNIX domain сокетах много чего нет. Например, SOCK_DGRAM и SCM_CREDENTIALS. Тут всё равно придется городить какую-то системно-зависимую логику, если эти штуки важны.
Тут скорее напрашивается идея не umask класть под условную компиляцию, а сформулировать интерфейс к IPC, семантика которого не будет зависеть от платформы, а вот реализация - будет.
Опять же, не вижу придмета для прям массовой копипасты.
Во-первых, это не позволяет просто написать «если есть системный вызов pledge(), то используй его», а вместо этого надо перечислить все совместимые платформы вручную. Если вдруг этот список расширится, то нужно его руками менять.
Если ваша платформа покрывается stdlib-ом, ничего не надо делать вообще. Причём код под платформу скорее всего будет разумным. Скажем, сетевой стек будет автоматически использовать epoll под Linux, completion port под Windows и я уж не знаю чего под BSD.
Если же не покрывается, скорее всего всё же портирование займет некоторое время. Хотя бы чтобы понять, чем заменить на данной платформе недостающее. На фоне этих усилий прописать несколько build tags, ну, не слишком трудозатратная задача.
К тому же, поддерживаемых платформ всё же не миллион. Указать нужную не так уж и сложно.
В целом, проблема выглядит надуманной. Описание платформ в терминах поддерживаемых фичей было бы IMHO гораздо более громоздким. В том же Linux список возможных фич, которые могут быть а могут и не быть, очень длинный. И Linux - это не единственная поддерживаемая и не единственная интересная платформа.
И отсутствие тут автоматизма имеет и плюсы и минусы. С одной стороны, придётся немного напрячь голову. С другой стороны, вы будете знать, что получаете, и не будет никаких сюрпризов. Всё же Go, как не странно это звучит в мире написанных на нём микросервисов - это язык системного программирования (и, как минимум, он создан людьми, всю жизнь занимавшимися системным программированием), а для целей системного программирования очень важен контроль над результатом и высокая степень прозрачности.
Во-вторых, в Go невозможно скомпилировать под, условно, Linux 2.6. Можно только под какой-то абстрактный Linux с непонятным набором доступных фичей
В release notes написано, какие ядра поддерживаются. В рамках этой поддержки программа сама в рантайме разберётся, что умеет конкретная версия ядра.
Собственно, glibc делает примерно так же. Поддерживается определённых диапазон ядер и glibc сама разбирается, какие функции ядра доступны для её нужд.
Если хочется получить более низкоуровневую детализацию, есть CGo.
Я, кстати, не представляю, что можно сделать полезного с umask-ом в многопоточной программе, кроме как сбросить её в 0 при инициализации. Она же, зараза, process-global, не thread-local.
Так что наверное даже хватило бы
func init() {
syscall.Umask(0)
}
Ну и вкомпилировать его на тех платформах, на которых понятие umask определено...
Это упростит простые случаи и запутает сложные. Но в простых случаях я и сам прослежу, чтобы файл закрылся. А в сложных я бы предпочёл потратить своё внимание на более осмысленные задачи.
Так что я не уверен, что цель будет тем самым достигнута...
С USBIP та проблема, что в нём не предусмотрен PnP. Т.е., можно воткнуть и "примонтировать" устройство, но если оно отсоединится (например, из-за того, что драйвер сделает reset), оно отвалится.
А хотелось бы, чтобы клиенты автоматически получали нотификации о появлении новых устройств и автоматически их "монтировали" (вероятно, не все подряд, а по каким-то критериям).
Не знаю, может если бы USBIP сервер экспортировал бы не конечные устройства, а виртуальный USB hub, как устройство, это бы и работало. Но линуксный сервер так не умеет.
Так есть же вроде подписанный клиент для венды: https://github.com/vadimgrn/usbip-win2
Вы странно приравниваете "системное ПО" и "высоконагруженное ПО".
Системное ПО - это часть системы. Оно создаёт инфраструктуру для жизни других программ, а не решает прикладные задачи.
Совсем не обязательно, чтобы оно было высоконагруженным.
Так что докер, snapd и т.п. я бы отнёс к системному ПО.
У ядра тут особое положение. Ему принадлежит аппаратура и через него проходит вся коммуникация между процессами. Так что ему приходится быстро крутиться.
Гошный File.Close вернёт то, что вернул системный вызов close() (обернув в гошный error).
Я хочу сказать, что у close всё-таки другая семантика, чем у free(). И код возврата может иметь знаение.
Если close делается имплицитно, до кода возврата не доберешся
А для сокетов fsync нет...
Еще все забываю спросить.
Закрытие файла, вообще-то, это операция, возвращающая результат. В котором есть смысл (например, если файл был открыт с правом на запись, то именно от ответа close() мы знаем, что всё записанное окончательно прописалось).
А если close - это неявная операция в рамках RAII, куда результат-то девается?
Докер - это системное программирование или аппликуха?
Может можно а может и не можно. Пока неизвестно.
Начнём доживать до болезней, с которыми раньше не сталкивались.
Что-то слабо верится.
Раньше люди умирали в основном от травм и инфекционных заболеваний. Их в основном победили, горизонты раздвинулись, и люди стали доживать до рака и инсультов-инфарктов. Которые раньше не составляли особой проблемы потому, что до них мало кто доживал. Победят сегодняшние причины смертности, окажется, что впереди нас ждёт что-то еще, не сильно более приятное.
Хуже всего, если окажется, что тело может и 200 лет прожить, а мозги после 120 массово отказывают. Так и будем жить, дееспособное и небогатое меньшинство в окружении богатых маразматиков, которые могут себе это позволить.
В венде он не так давно появился.
Правда с другой стороны, Go вроде уже перестал поддерживать версии венды, которые не умеют в AF_UNIX.
Ну и в вендовых UNIX domain сокетах много чего нет. Например, SOCK_DGRAM и SCM_CREDENTIALS. Тут всё равно придется городить какую-то системно-зависимую логику, если эти штуки важны.
То же самое и про UNIX говорили :)
Зато его не надо в контейнер класть с миллионом библиотек, необходимых ему для жизни. А можно прямо на хосте запускать.
UNIX socket тоже платформенно-зависимая штука.
Тут скорее напрашивается идея не umask класть под условную компиляцию, а сформулировать интерфейс к IPC, семантика которого не будет зависеть от платформы, а вот реализация - будет.
Опять же, не вижу придмета для прям массовой копипасты.
Если ваша платформа покрывается stdlib-ом, ничего не надо делать вообще. Причём код под платформу скорее всего будет разумным. Скажем, сетевой стек будет автоматически использовать epoll под Linux, completion port под Windows и я уж не знаю чего под BSD.
Если же не покрывается, скорее всего всё же портирование займет некоторое время. Хотя бы чтобы понять, чем заменить на данной платформе недостающее. На фоне этих усилий прописать несколько build tags, ну, не слишком трудозатратная задача.
К тому же, поддерживаемых платформ всё же не миллион. Указать нужную не так уж и сложно.
В целом, проблема выглядит надуманной. Описание платформ в терминах поддерживаемых фичей было бы IMHO гораздо более громоздким. В том же Linux список возможных фич, которые могут быть а могут и не быть, очень длинный. И Linux - это не единственная поддерживаемая и не единственная интересная платформа.
И отсутствие тут автоматизма имеет и плюсы и минусы. С одной стороны, придётся немного напрячь голову. С другой стороны, вы будете знать, что получаете, и не будет никаких сюрпризов. Всё же Go, как не странно это звучит в мире написанных на нём микросервисов - это язык системного программирования (и, как минимум, он создан людьми, всю жизнь занимавшимися системным программированием), а для целей системного программирования очень важен контроль над результатом и высокая степень прозрачности.
В release notes написано, какие ядра поддерживаются. В рамках этой поддержки программа сама в рантайме разберётся, что умеет конкретная версия ядра.
Собственно, glibc делает примерно так же. Поддерживается определённых диапазон ядер и glibc сама разбирается, какие функции ядра доступны для её нужд.
Если хочется получить более низкоуровневую детализацию, есть CGo.
Я, кстати, не представляю, что можно сделать полезного с umask-ом в многопоточной программе, кроме как сбросить её в 0 при инициализации. Она же, зараза, process-global, не thread-local.
Так что наверное даже хватило бы
Ну и вкомпилировать его на тех платформах, на которых понятие umask определено...
Не знаю, не знаю.
Это упростит простые случаи и запутает сложные. Но в простых случаях я и сам прослежу, чтобы файл закрылся. А в сложных я бы предпочёл потратить своё внимание на более осмысленные задачи.
Так что я не уверен, что цель будет тем самым достигнута...
Что в конечном итоге приведёт к тому, что явное закрытие файла будет выражаться присваиванием какого-то эквивалента
nilсоответствующей переменной.Ну, я не уверен, что замена явного нетривиального действия неявным так уж способствует уменьшению количества допущенных людьми ошибок...
Да, но как-то то надо управлять закрытоем файла, если предполагается, что он должен пережить момент выхода из зоны видимости...
И что это доказывает? Что вам достаточно хоткея в IDE? Ну, ОК.