Может есть что-то попроще, чем прочитать /etc/mtab и проверить, какой смонтированной ФС принадлежит путевое имя файла? Программа на Си.

С помощью вызова execvp запускается процесс типа: xterm /путь/исполняемый_файл. Но в пути может быть каталог с пробелами в именах. Приходится их заменять на \пробел. В итоге получаю такой warning. Есть способ от него избавиться?

Заранее извиняюсь за сумбур. Очень странная проблема.

Есть библиотека виджетов для Motif/X11. Собирается с помощью autotools. В составе пакета сами исходники библиотеки и примеры/тесты. Все собиралось и работало. Некоторое время назад переделал в библиотеке кое-что и добавил новый виджет. Соответственно добавил 3 теста/примера. Один из тестов вываливается с ошибкой.

Ошибка представляет собой сообщение о том, что неверно указано окно, для которого запрошено изменение каких-то параметров. Аналогичные ошибки я встречал неоднократно, когда при сборке приложения для Motif/Xt/X11 библиотеки указываются в некорректном порядке. Но у меня при сборке тестов в этом смысле все правильно. Это стало склонять меня к подозрению, что что-то не так с линковкой. К тому же другие тесты работали.

Поставил обработчик ошибки. Увидел, что после 3 ошибок выскакивает сообщение, что не определен код метода realise, и идет завершение. Два теста из трех работают. Все используют один и тот же виджет. И в тестах отличий по минимуму. Достаточно в неработающий тест добавить при создании виджета определение ресурса, например, изменить размер рамки, и тест отрабатывает.

Поэкспериментировал со старыми тестами. Добился, что один тест тоже стал вываливаться с аналогичной ошибкой, если в нем сократить все действия до минимума. То есть создаем виджет в топлевеле и ничего более. Хотя все это может не означать какой-либо закономерности. Просто какое-то стечение непонятных условий. Все это приводит меня в полное замешательство.

Тогда я взял и написал для сборки всего этого простой makefile. С ним все собирается и работает. Кинул собранную библиотеку в проект с autotools. Пересобрал тесты. Все тесты работают.

Что делать непонятно. Даже не знаю, что еще проверить, или поковырять. Что посоветуете?

Что будет, если из разных потоков для одного дескриптора вызывать poll и recvfrom?

Есть различные способы, типа NX бита для сегментов данных, рандомизация адресного пространства для выделяемых блоков памяти и т.п. И вот что-то не могу вспомнить что-то еще из этой серии. Что-нибудь еще есть?

Обычная утилитка cmp не подходит. Нужно, чтобы отличия отображались, здесь такой блок данных, здесь другой блок данных.

Вот простой пример программы чтения из raw socket. Ищется в инете чуть-ли самый первый.

/*** IPPROTO_RAW receiver ***/
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/ip.h>
#include <arpa/inet.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>


int main(void)
{
	int s;
	struct sockaddr_in saddr;
	char packet[50];

	if ((s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) {
		perror("error:");
		exit(EXIT_FAILURE);
	}

	memset(packet, 0, sizeof(packet));
	socklen_t *len = (socklen_t *)sizeof(saddr);
	int fromlen = sizeof(saddr);

	while(1) {
		if (recvfrom(s, (char *)&packet, sizeof(packet), 0,
			(struct sockaddr *)&saddr, &fromlen) < 0)
			perror("packet receive error:");

		int i = sizeof(struct iphdr);	/* print the payload */
		while (i < sizeof(packet)) {
			fprintf(stderr, "%c", packet[i]);
			i++;
		}
		printf("\n");
	}
	exit(EXIT_SUCCESS);
}

Работает, но только когда пакеты посылаются на петлевой интерфейс (127.0.0.1). А если послать их по реальной физичской сети, то программка ничего не читает из сокета. В чем может быть дело? tcpdump пакеты ловит, проверено, т.е. физически они передаются.

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

Программы, которые могут прокладывать маршрут, отслеживать движение и пр.

Имеется в виду поле GF(q) или иначе это выглядит как символ F, у которого вертикальная линия двойная.

Столкнулся со странной проблемой. Понадобилось скомпилировать программку. Она достаточно давно написана и сборочные скрипты давно не менялись. Для работы требует библиотеки, которую, соответственно, нужно тоже собрать и установить. Сборка и того и другого реализуется с помощью autoconf/automake. До сих пор все это работало без проблем. Теперь понадобилось это поставить под ARM64. Сборка библиотеки проходит успешно. А при сборке программы configure не находит библиотеку. Библиотека на месте. nm показывает, что функция, указанная в AC_CHECK_LIB присутствует. Не знаю, имеет ли значение тип архитектуры, но днем ранее нормально собирал все это на intel-е. autoconf 2.69 automake 1.16.1 gcc 8.4.1. На arm-е autoconf 2.6.9 automake 1.16.2 gcc 9.3.1.

Понятно, что ядро анализирует dtb-файл, строит структуру устройств. Что дальше? Как устанавливается связь между конкретным модулем с некоторым именем в соответствующем каталоге с конкретным устройством, описанном в dtb-файле?

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

1. Посмотрел alsasmixer. На вкаладке HDMI-устройства никакого управления нет. Через HDMI-интерфейс гонится цифра. Логично. Управление громкостью может быть только на конечном устройстве, где уже воспроизводится аналоговый сигнал (например - телевизор). Однако, в разных программах есть регулировки уровня громкости, а может быть и еще много чего. Тогда получается, это делается через puls-у? Выходит, она в реальном времени перекодирует цифровой поток? 2. Насколько я понимаю, звуковое приложение может выводить цифровой аудио-поток в различных фформатах. А если вдруг окажется, что HDMI не поддерживает этот формат, то что происходит? Та же pulsa согласовыввает необходимый формат с каждым приложением?

3. А как вообще роутятся звуковые потоки? Это настраивается в ALSA? Или можно выбрать, куда выводить для конкретного приложения в puls-е? Или и там и там по разному?

Если мне не изменяет память, то чтобы значение переменной сохранялось за пределами скрипта после его исполнения, надо использовать команду export. Беру скрипт типа такого:

#!/bin/sh

export MUMUR="/home/mumur/bin"
export PATH=$PATH:$MURMUR

Исполняю его. После исполнения переменная MUMUR не существует, PATH остается та, что была до этого по умолчанию. Вроде они должны были бы сохраниться? Или я в чем-то тут туплю?

Что-то никак не могу сообразить, как обработать событие POLLHUP, полученное от poll, когда отслеживается дескриптор FIFO на чтение. Стоит только записывающему процессу закрыть FIFO, как понятное дело возникает это событие. Последующие вызовы poll приводят сразу к немедленному возврату из него с установленным событием POLLHUP.

Получается единственный вариант: получил POLLHUP, закрыл fifo, снова открыл fifo, пошел на новую итерацию?

Как то не приходилось задумываться на эту тему, а тут при очередном ковырянии с не intel железками стало интересно.

Положим в cmdline ядру при старте передается в том числе что-то типа rootfs=/dev/mmcblk0p1. Но до того, как смонтирована rootfs никакого /dev/mmcblk0p1 быть не может. Понятно, что /dev/mmcblk0p1 это лишь некая абстракция для доступа к устройству из userspace. Если драйвер вкомпилен в ядро, то он подцепляет устройство, и из ядра с ним можно работать. Но было бы интересно понять механизм монтирования rootfs самим ядром. Может там есть какие интересные нюансы.

Посоветуйте какой-нибудь простой, но желательно не костыльный способ. Думал, что где-нибудь в /proc что-то должно быть. Нашел таблицу маршрутизации. Но это не совсем то. Может плохо искал? Ну понятно, что через netlink можно. Но исходники iproute2 что-то тяжело ковыряются. Скажем, как получать через netlink события, связанные с изменением сетевых параметров понятно (мониторинг). Но не могу пока понять, как запросить текущее состояние.

Как удобнее внутри некоего абстрактного текстового редактора хранить/обрабатывать текст - в виде мультибайтовых строк, или wchar_t? У кого какие на этот счет мысли. Может здесь кто-то «ковырял» исходники какого-нибудь существующего редактора.

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

Запускаю игрульку на движке cube3d. Она показывает текущий fps. Значение прыгает в районе 60 кадров в секунду (59-60). Начинаю играться параметрами детализации и разрешения. И, о чудо, получаю все те же 59-60 кадров в секунду. При том, что разрешение хоть 4К, хоть FullHD, или и того меньше. Ну разве при каком-то разрешении типа 1200х780 (или типа того) частота поднялась до 75 кадров в секунду. Кстати Displayport 1.2, вроде как, тоже должен уметь 75 кадров в секунду для 4К.

Единственное, что приходит в голову, что современные драйвера в купе с современными видео интерфейсами понимают, что коль Displayport/HDMI все равно не дадут передать больше 60 кадров, то и стараться рендерить больше нет смысла.

Но Displayport 1.2 в FullHD должен позволить передавать 120 кадров в секунду, я уж не говорю про более дохлые видео режимы.

Получается это недоработки в драйвере (amdgpu)? Или это баги в мониторе? Или что?

Вроде бы как в нотации ATT $ перед операндом указывает на то, что надо использовать содержимое регистра, например: add $2, $9, $8 Т.е. содержимое регистра 8 сложили с содержимым регистра 9, результат поместили в регистр 2.

Без амперсанда указывается непосредственно операнд, типа: addiu $2, $9, 8 Т.е. 8 сложили с содержимым регистра 9, результат поместили в регистр 2.

Но с некоторыми командами сразу и не поймешь, что да как. Пример из доки:

unsigned mips_cycle_counter_read()
{
unsigned cc;
asm volatile("mfc0 %0, $9" : "=r" (cc));
return (cc << 1);
}

Получается, что $9 это указание читать из регистра номер 9 CP0? Т.е. я указываю не адрес/номер/смещение регистра из CP0, а именно его имя? Аналогично применяются команды mfc1, mfc2, rdhwr?

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