Как в ядро Linux передаются строки?

Я думаю, что строки тут не причем. Ядро работает просто с буферами. А что именно в этих буферах – это уж твое дело.

О каких функциях идет речь хотя бы?

Null-terminated строки там обычно, для буферов бы указывалась длина.

https://github.com/torvalds/linux/blob/v6.7/arch/x86/entry/syscalls/syscall_64.tbl

ну, например sys_write.

Ядру похрен на кодировку.

И где там про кодировку?

Ну где-то же должно быть? Если не там, то где?

Ну где-то же должно быть?

Ну не в ядре же.

Если не там, то где?

В glibc.

Кстати, по твоей ссылке речь про glib и gtk. Не путай glibc и glib. Это совершенно разные вещи. Первое — реализация стандартная библиотека языка (libc), кроме glibc есть ещё musl. Второе — гномовско-гткшные накрутки. И glibc как раз работает с разными кодировками и разными локалями.

CONFIG_UNICODE=y

А, да, для файловых систем не похрен (для реализации регистронезависимых имён файлов в них имеет значение кодировка). Но это явно не то, что интересует ТС.

Что такое, например:

ISO 2022 standard for character set switching.

В гугле забанили? https://en.wikipedia.org/wiki/ISO/IEC_2022

Сишные буферы содержащие текст это мы просто называем строками, для своего удобства или на уровне API которое ожидает внутри буфера нуль терминал \0 или передачу явного размера через аргумент обрабатывающей функции. Для всех остальных случаев это просто последовательность байтов, а что в ней ASCII,RGBA,UTF-8 или в виде ссылки на порнхаб не важно.

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

Ну погляди на то как работает printk()

• https://docs.kernel.org/core-api/printk-basics.html

То через что работает printk и есть твой желаемый «рантайм» для работы с текстом в ядре. Если хочешь свою кодировку например отличную от ASCII и не совместимую с ней то от printk до бррруньк ниже по уровню должны его понимать и правильно обрабатывать, если совместимую то уже проще, тогда нужно просто правильно показывать.

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

погляди на то как работает printk

«printk() messages are printed to the kernel log buffer, which is a ring buffer exported to userspace through /dev/kmsg»

1. Чем мне это глядение поможет? Где сказано, в какой кодировке должно храниться что-либо в этом буффере?

2. Мне кажется, что sys_write и printk не связаны между собой. Одно для пользовательских программ, а другое для модулей ядра.

3. мне надо выводить в терминал, а не в буфер ядра

Ну ты же о нём тоже в первый раз в жизни читаешь?

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

Say Y here to enable UTF-8 NFD normalization and NFD+CF casefolding support. If you say M here the large table of case foldings will be a separate loadable module that gets requested only when a file system actually use it.

Ну я прочитав это не понял, что такое NFD, что такое case folding.

casefolding based on unicode’s canonical normalization (NFD) with slight modifications.

всё равно непонятно.

http://www.unicode.org/reports/tr15/

Normalization Form D (NFD) Canonical Decomposition

Case folding in Unicode is primarily based on the lowercase mapping, but includes additional changes to the source text to help make it language-insensitive and consistent. As a result, case-folded text should be used solely for internal processing and generally should not be stored or displayed to the end user.

https://www.w3.org/TR/charmod-norm/#definitionCaseFolding

Case folding is the process of making two texts which differ only in case identical for comparison purposes, that is, it is meant for the purpose of string matching. This is distinct from case mapping, which is primarily meant for display purposes. As with the default case mappings, Unicode defines default case fold mappings («case folding») for each Unicode code point.

A few characters have a case folding that map one Unicode code point to two or more code points. This set of case foldings are called the full case foldings.

Данунафиг. Зачем мне знать такие детали враждебной кодировки?

для файловых систем не похрен

Тоже интересует.

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

Я так понял, что linux тут не справится.

Может в Wine что-нибудь против таких программ есть?

Чем мне это глядение поможет? Где сказано, в какой кодировке должно храниться что-либо в этом буффере?

Любое глядение исходников поможет понять как оно там всё работает, я то фиг знаю что тебе конкретно надо.

Мне кажется, что sys_write и printk не связаны между собой. Одно для пользовательских программ, а другое для модулей ядра.

Надо смотреть на внутренюю реализацию

мне надо выводить в терминал, а не в буфер ядра

Тогда вообще причём тут ядро? У тебя есть язык C вот и храни в его байтовых буферах что угодно, обрабатывай, выводи как угодно и прочее.

В шапке ты пишешь про ядро, а в сообщениях про кодировку вывода в эмулятор терминала.

Что такое кодировка? Это набор кодов по которым можно сделать выборку из таблицы символов формат которой (таблицы) понимает выводящее устройство, это называется шрифт. Ты выводишь коды символов на stdout терминал распознаёт коды и рисует символы из таблицы шрифта. Причём весь процесс от и до может быть каким угодно, например в OpenGL приложениях где понятия «текст» просто не существует, ты можешь назначить буквам любой нормер, затем в текстуре нарисовать картинки букв, и по номеру буквы вычислять позицию картинки которая находится в текстуре, выдирать этот кусочек и выводить на экран, это примитивный но всё ещё использующийся метот отображения текста и там полная свобода в какой кодировке у тебя твои символы и в каком формате хранятся их начертания для вывода на экран.

Если ты хочешь использовать для вывода например кирилицы в терминал текста, но на придуманой тобой уникальной кодировке, ты должен последовать тому как устроен вывод текста в том что ты хочешь использовать, иначе говоря ты должен обеспечить возможность определять по твоей кодировке какой символ из файла шрифтов должен быть выведен. Это чисто прикладная область к ядру в целом отношения не имеющая. Можно также говорить в тамках вывода текста в BIOS там в ПЗУ вшита картинка с набором картинок символов, а по значениям байтов из картинки берутся регионы и выводятся на экран например.

Ты в последнее время задаёшь очень много сложных вопросов, неоднозначных и странных, вообще ничего не поясняя.

То язык для описания химии, компилировать вещества. То язык для описания проводов, для разрезания и склеивания бит. Ладно, по теме я так и не понял что конкретно хочется и нужно, не буду беспокоить.

Null-terminated строки там обычно

они зло:
https://lwn.net/Articles/948408/

Раньше в ядре можно было указывать кодировку путей файловой системы при монтировании. Затем эту фичу выпилили. Давно это было.

У тебя есть язык C

У меня нет языка Си.

я то фиг знаю что тебе конкретно надо.

Я хочу такой же, но другой.

В шапке ты пишешь про ядро, а в сообщениях про кодировку вывода в эмулятор терминала.

Код программы я пишу - в регистры грузим то и сё, выполняем инструкци syscall. Всё. Про терминал программа не знает. Значит должен знать кто-то другой, как настроить терминал под кодировку, если программу менять нельзя.

ты должен последовать тому как устроен вывод текста в том что ты хочешь использовать

Или разобраться как это всё доработать для поддержки новой кодировки (utf-8 => лёд-9).

задаёшь очень много сложных вопросов

если бы существовало больше форумов, я мог бы задавать вопросы на разных форумах понемногу. Но их мало. Поэтому вопросов получается много. Тут ничего нельзя сделать.

Значит должен знать кто-то другой, как настроить терминал под кодировку, если программу менять нельзя.

Какой терминал? И при чём тут ядро?

Смотри настройки эмулятора терминала.

при чём тут ядро?

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

Какой терминал?

В идеале - любой и каждый.

Запускаешь программы одной кодировки в одном эмуляторе терминала, а программы другой кодировки – в другом эмуляторе терминала.

Как вариант – запускаешь через обёртку, которая подсовывает при запуске другой pty и делает рекодировку.

Более лучшего решения в рамках существующей архитектуры pty предложить не могу.

Сдаётся мне, ты хочешь «умные» терминалы, где клиент и сервер могут обмениваться пакетами out of band от основного потока данных. Но практических реализаций такой архитектуры нет. Только наброски.

Мне кажется что ты просто хочешь нарисовать свой шрифт, где байт со значением 1 будет выводить кириллическую А например. Бери шрифт и рисуй в кодпоинт 1 букву А. Только ты сломаешь всякие ASCII штуки в виде управляющих последовательностей на которые полагается терминал, у терминалов своя спецификация как интерпретировать определённые коды и тебе придётся с этим мирится и это учитывать, хочешь полной свободы по выводу текста, бери OpenGL и делай там (как все инди разработчики со своими движками) свой формат текста, свой формат шрифтов и свои правила для всего, бери то где текста нет и понятия терминал тоже, пиши свой. Некоторые так и делают.

Про терминал программа не знает.

Значит тебе нужно настроить терминал чтобы он знал что в него прилетает, это тоже самое как настроить терминал для UART там может прилетать в качестве завершение строки ‘\n’ а может ‘\r’ а может \r\n, программа посылающая данные тоже понятия не имеет что такое термпинал она может работать на ATmega какой и просто слать байты в UART задача приёмного терминала быть настроенным и показывать то и в том формате что в него летит, а не белиберду.

Так что либо настраивай терминал дабы он понимал что в него летит либо прям бери и делай специализированный терминал, многие имеют настройки для переключения кодировки, если терминал не понимает твою то тебе не нужно ядро, тебе не нужен Си, тебе нужно реализовать свою кодировку в терминале, например если взять какой старый терминал для иксов то он не поймёт вывод программы в utf-8 и будет выводить мусор, что нужно сделать? Правильно не трогать свою программу, не трогать ядро, а трогать терминал, то через что будет выводится текст.

Если ты хочешь прям разом чтобы все gnome-terminal, xfce4-terminal и прочеи вдруг начали выводить текст в твоей кодировке то либо ты используешь то через что общее (если это так) они обрабатывают ввод/вывод или берёшь например st и патчишь его под себя добавляя туда свою реализацию своей кодировки. Просто вжух и везде всё заработало, так не выйдет, разве что это везде работает на чём то одном и вот туда ты тоже должен впихнуть свою кодировку, вернее механизм говорящий что вот этот код соответствует вон тому глифу в шрифте.

лёд-9

А где спецификацию на кодировку поглядеть, может оно с ASCII совместимо, а может нет, это сильно большая разница

берёшь например st и патчишь его

https://st.suckless.org/

А ядро? Оно не только в терминал выводит, оно ещё в файловую систему строки передаёт, например при создании файла с заданным именем.

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

Для ядра имя файла это просто набор байт. Исключение - имена на case insensitive фс и неродных фс.

Запись в файл это просто запись в файл байт, что там внутри всем включая ядро пофигу, запись имени файла тоже самое, но есть коды символов которые запрещает файловая система для имён.

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

Я сомневаюсь что есть где то одно место которое можно поправить и получить желаемое. Моих знаний и компетенции тут уже ни на что не хватит.

А ядро?

А ядру на всё это пофигу. Оно текст не рисует, для него всё это просто байты, а что в этих байтах ему плевать, за исключением API работы с нультерминированными строками, но им тоже плевать что внутри, главное при встрече \0 обработка байтов прекращается. Всё. Ну и да есть ещё вещи ожидающие что у символа / код такой же как в ASCII и так далее. Если ты хочешь кодировку которая вообще не совместима с ASCII то ты поломаешь все управляющие последовательности, пути файлов и прочего, как сказал wandrien возможность указать для путей что-то отличное от ASCII выкинули, ну и…

Есть обходной вариант, твоя программа может работать внутри себя с любой кодировкой, но у неё будут два транслятора, первый при вводе текста будет преобразовывать его в лёд-9, а если твоя программа делает вывод то он будет проходить через транслятор и преобразовываться в utf-8 например. Так на уровне твоей программы у тебя будет всё своё, но ввод/вывод будет работать через преобразование кодировок, так у тебя всё заработает из коробки, наверняка накладные расходы будут копеешные, но так ты сможешь заниматься разработкой своей программы котрорая работает с кодировкой лёд-9 прозрачно от системных особенностей. И отложить вопрос по прямой интеграции кодировки с разными частями ОС в целом на потом.

есть ещё вещи ожидающие что у символа / код такой же как в ASCII

В ядре. Или в FUSE (а ядро не при чём)?

и так далее.

Нееет, нужно больше конкретики. Кроме ядра в разборе всяких путей ещё замешан bash.

я откланяюсь, ибо задача комплексная

Спасибо Вам, добрый человек, за всё.

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

Давай мы тут определимся, что это «всё» она передаёт. В целом ядру пофиг, для него все эти строки — просто последовательности байт, завершающиеся нулём.

Для файловых систем с регистронезависимыми именами файлов да, ядру нужно понимать кодировку, чтобы понимать, один и тот же файл «б.zip» и «Б.zip», или два разных. В обычном для линуксовых ФС случае это не требуется. Только ни ко всем остальным строкам, ни к терминалу, ни тем более к wine это отношения не имеет — это касается только ФС.

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

Никак. Если речь о локалях, то есть, ты задаёшь, например LC_ALL=de_DE.UTF-8 или LC_ALL=ru_RU.KOI8-R, то за это отвечает glibc, а не ядро.

за это отвечает glibc

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

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

Ну так запускайте свою, исконно русскую ОС с исконно русским ядром на исконно русском железе. Чего вы на вражеском сидите-то?

Вклинюсь напоследок

Вычислительная техника работает по спецификациям, спецификации нужны для того чтобы программы могли полагаться на какие-то договорённости. Иначе бы было у одного /home/user/Докуменнты, а у другого ★хомяк★★ИмЯ★★★/Документы, а у иного лица 😊дом😊имя😊файлы и как программам работать? Так исторически сложилось.

Хочешь всё своё, пиши всё с нуля, но сначала свои спецификации на кодировки, спец символы, имена путей, регистрозависимость и так далее и так далее, сотни и тысячи разных мелочей. На RFC погляди сколько там всего, тонны всякой всячины описаны именно для того чтобы если делать то совместимо.

Даже с теми же путями сейчас не всё так хорошо, файлы с винды показываются кракозябрами, текст неправильно отображается в терминале при выводе ибо там \r\n а тут просто \n и глазами это в редакторе не видно,а в старых макосях вообще тупо возврат каретки. Пути файлов в виндах такие \ а в юниксах / такие. Можно пропатчить и вместо слеша пихать звёздочку ★, но это значит что нужно многие вещи на что полагается ПО пересмотреть, а потом переписать всё это ПО. Я вот полагаюсь что если пользователь в пути указал в начале точку перед слешем то это относительный путь текущего pwd, а не имя файла. И у тебя тоже самое, ты ожидаешь что все вещи будут вести себя и означать собой что-то определённое.

Либо ты пишешь свои спецификации и всё с нуля по ним (или переписываешь имеющееся ПО), либо ты интегрируешься с тем что уже написано. Иного пути нет. От слова совсем.

на исконно русском железе

Денег его купить нехватает, а вражеское было любезно предоставлено.

переписать всё это ПО

Если оно не следует принципу DRY (код должен существовать в единственном экземпляре и не дублироваться), то это всё равно плохое, негодное ПО. Грех не переписать.

Я вот полагаюсь что если пользователь в пути указал в начале точку перед слешем то это относительный путь

../ну_да.конечно

две точки перед слешом - это уже в таком определении не относительный путь.

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

Я использую константы:

String fileSeparator = FileSystems.getDefault().getSeparator();

две точки перед слешом - это уже в таком определении не относительный путь.

Относительный, но уже не до текущего каталога, а выше него. Но да, это другое :)

Относительный. Абсолютные пути начинаются со слеша. Остальные — относительные.

Ну так каталог выше тоже относительно текущего каталога ;)

Здесь одно на другое не влияет. Две точки — это просто «на уровень выше» — их можно использовать как в относительных путях, так и в абсолютных. В абсолютных практического смысла в принципе маловато, но вообще путь /usr/share/../bin/sh, например, валидный.

Путь ../что_то точно такой же относительный относительно именно текущего каталога. Просто в нём используются две точки, так же как и где угодно ещё.

переписать всё это ПО

причём ради несоответствия стандартам — это вредительство в духе M$. Именно они таким промышляли в стародавние времена. И в путях сделали обратный слеш вместо прямого, и в веб-стандарты специально палки в колёса вставляли, и для офиса свои собственные пропихивали, и т.д. и т.п. Так что за лучшими практиками подобного — это к ним.

До сих пор вот расхлёбываем.

«Macintosh OS used : as its path separator until MacOS X introduced POSIX APIs»
https://retrocomputing.stackexchange.com/questions/4695/slash-versus-backslash-as-directory-separator-what-who-caused-this-rift

«: and . as path separators predating UNIX’s use of /»

«designs were using : and . in the mid-60s, half a decade before UNIX decided on /, and UNIX broke from Multics’s > because they wanted to use it for shell piping.»

Я в курсе. Но эти потом исправились.

Эппл не сильно лучше МС, они тоже пропихивают собственные ни с чем не совместимые стандарты, до сих пор. Но у эппла есть большой плюс — они их не навязывают окружающему миру и варятся в своём болоте. Напротив, они стараются, чтобы остальные в них особо и не лезли. То есть, если ты не пользователь эппловских продуктов, ты можешь достаточно спокойно закрывать глаза на их существование вообще и жить так, будто никакого эппла нет. M$ же пытается пропихнуть свои «стандарты» всеми миру, а потом внезапно поменять. Ну и классическое EEE.

В RISC OS (не путать с risc/os) разделителем каталогов является точка, а отделителем расширения файла – слэш.

В общем, какого только маразма за историю айти не случалось.

Но о чём ваши разговоры, всё равно непонятно)

Это был не микрософт:
«the decision to use backslash was requested by IBM: Microsoft had been originally intending to use forward slash, and the change happened late in the development process»

The reason / was not used is that MS-DOS 1.0 (which did not support directories at all)

о чём ваши разговоры, всё равно непонятно

Можно ли в ядро linux впилить работу с путями по другому символу? насколько это сложно?

Нельзя. Всё паламаеца, насяльника!

MS вообще любило Unix платонической любовью и несколько раз пыталось сделать DOS более Unix-like.

Но межделмаш имел свои планы на это.

Всё паламаеца

Главное, что моя прога будет работать.

А для своих путь добавляют функции, которые будут выяснять, какой fileSeparatorChar надо использовать, а не зашивают константы.

Насколько я понимаю, DOS мог бы быть чем-то вроде Unix для бедных, если бы MS имела возможность сломать совместимость с первоначальной наколенной версией-поделкой.