Зачем нужны `копия _от _пользователя ()`и `копия _пользователю _()`, когда ядро ​​отображается в то же виртуальное адресное пространство, что и сам процесс?

Одна из возможностей состоит в том, чтобы закодировать двоичный файл как текст ASCII, используя либо традиционный uuencode , либо несколько более современный base64. Программы uuencodeи uudecodeвходят в состав пакета sharutils , а base64— в coreutils . Похоже, что base64уже присутствует в современном дистрибутиве GNU/Linux.

Результатом кодирования двоичного файла является большой объем текста, который в принципе можно скопировать/вставить по терминальному соединению в декодер на target. При большом количестве данных использование буфера обмена может быть нецелесообразным, но мы можем использовать средства screenдля вставки содержимого файла в терминал.

1. На sourceзапустите base64 FILE > FILE.b64.
2. В сеансе screen, подключенном к target, введите Ctrl -A :readreg p /path/to/FILE.b64. (Если ваша управляющая клавиша screenотличается от Ctrl -A, введите ее. )Кажется, вы должны указать полный путь к FILE.b64; ~не работает. Экран должен сообщить что-то вроде «В буфер введено 26665052 символа».
3. В консоли на targetзапустите base64 -d > FILE.
4. Введите Ctrl -A :paste p.
5. Введите Ctrl -D.

Другим давно -проверенным способом решения этой проблемы является ZModem , почтенный метод передачи файлов через терминальные соединения. Поддержка ZModem встроена во многие эмуляторы терминала, такие как Konsole, если установлен пакет lrzsz. Однако есть вероятность, что lrzsz не установлен, поэтому лучше использовать base64.

Все эти методы решают проблему передачи файла по последовательному каналу, который вы используете в данный момент для консоли. Если вам не нужна консоль, будет проще сделать так, чтобы targetвыгружала что-либо из ссылки в файл; но это будет проблематично, если последовательная консоль — ваш единственный способ взаимодействия с устройством!