Есть различные способы, типа 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, то складывается впечатление, что надо указывать номер загружаемого регистра. Я то и пробовал этот номер указывать либо непосредственно, либо через какой-нибудь регистр в ЦПУ. Таким макаром что-то не очень получалось.

Всегда отдавал предпочтение видюхам от Ati/AMD, так как они худо бедно, но открывают спеки и сами пишут OS-дрова. Так что целился на что-нибудь типа RX560. Но тут цены на них пеперли. Да и глянул я на старичков (уже не прошлые, а позопрошлые поколения) от Nvidia и обнаружил, что на свободных драйверах в 3д вполне себя хорошо чувствуют, а то и обгоняют AMD. При этом картинку показывают не хуже, никаких артефактов, как при начале пиления OS-дров не заметил. Так и задумался может лучше взять какой-нибудь GTX1050. Чуть дешевле, да может еще и чуть шустрее будет. Собственно вопрос то в чем: как живут нынче AMD RX560 и Nvidia GTX1050 с OS-дровами? На каких ядрах заводятся? Что могу, что не могут пока?

Лет 10 уже не писал Makefile-ы, не могу понять, в чем собака порылась.

#!/usr/bin/make -f
CC := gcc

ifeq ($(CC),icc)
  CFLAGS += -qopenmp
endif

ifeq ($(CC),gcc)
  CFLAGS += -fopenmp
endif

CFLAGS += -I../include -lsrvc_cmd

TARGETS = $(patsubst %.c,%,$(wildcard *.c))

BINARY= $(patsubst %.c,%,$<)

install:
	@for bin in $(TARGETS); do (rm -if $$bin); done
	@for bin in $(TARGETS); do (make $$bin); done
	rm -rf *.o *~ core .depend .*.cmd *.mod.c .tmp_versions

$(BINARY): $(BINARY)
	$(CC) $(CFLAGS) -o $@ $@.o

clean:
	@for bin in $(TARGETS); do (rm -if $$bin); done
	rm -rf *.o *~ core .depend .*.cmd *.mod.c .tmp_versions

cleanall:
	@for bin in $(TARGETS); do (rm -if $$bin); done
	rm -rf *.o *~ core .depend .*.cmd *.mod.c .tmp_versions

.PHONY: build clean clean all

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

gcc -fopenmp -I../include -lsrvc_cmd prog.c -o prog

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

В общем создал модуль ядра, в котором запускается поток. Поток в цикле нечто считает. Меньше, чем через минуту, такой модуль крэшится с сообщением типа: rcu_sched self-detected stall on cpu #. Т.е. я таки правильно понимаю, что ядерный поток сам время от времени должен вызывать schedule?

В исследовательских целях пишу модуль, реализующий сетевой обмен в контексте ядра. На одном хосте модуль формирует IP/UDP пакет и отправляет его чрез стевой интерфейс. На другом хосте такой же модуль ставит ловушку в цепочку PREROUTING и перехватывает пришедшие пакеты. Вроде отладил, как-то это худо бедно заработало. Но заработало при обмене пакетами малых размеров. Специально начал отладку с маленьких пакетов, так как порции данных, которые надо пересылать могут быть разных размеров. Стоило увеличить размер пакетов сетевого обмена, как начались чудеса. Если payload по udp до 208 включительно, то все ок. Ставлю 216 и более - не работает. Т.е. смотрю отправляемый sk_buf перед самой передачей. Ничего подозрительного не видно в обоих случаях. Смотрю wireshark-ом на принимающей стороне. Что маленький, что большой пакеты заполнены так, как и должны (т.е. между ними не наблюдаю принципиальной разницы, кроме соответствующих размеров). Однако ловушка на приемном конце не может нормально принять большой пакет. Причем видно, что ip_total_len у пойманного пакета такая же, как у отправленного (и захваченного wireshark-ом). А вот tail почему-то указывает, что прочитан только IP-заголовок + UDP-заголовок. Ну т.е., если отправлен пакет с payload 216, то получаю разницу между data и head в 76 байт и tail 106, в итоге между data и tail 28 байт, т.е. всего на IP+UDP заголовки. А дальше мусор. Понимаю, что где-то какой-то обидный ляп, а как его теперь ловить - уже ума не приложу.