jcmvbkbc

.file "main.c"
Зачем в коде название файла с исходным кодом

Для генерации отладочной информации в формате DWARF.

.ident "GCC: (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0"
...и версия моей убунты?

Это не версия твоей убунты, это строка идентификации компилятора, в которой оказалось имя твоей ОС.

Попадают ли они в исполняемый файл при окончательно компиляции и зачем используются?

Имена файлов попадают в таблицу символов как символы типа FILE и в секцию отладочной информации:

$ readelf -a hello | grep FILE
    28: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
    37: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS hello.c
    38: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
    41: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS

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

Идентификационная строка компилятора попадает в секцию .comment объектного файла, а оттуда -- в исполняемый файл:

$ objdump -s -j .comment hello

hello:     file format elf64-x86-64

Contents of section .comment:
 0000 4743433a 20284465 6269616e 20362e33  GCC: (Debian 6.3
 0010 2e302d31 382b6465 62397531 2920362e  .0-18+deb9u1) 6.
 0020 332e3020 32303137 30353136 00        3.0 20170516.

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

e.data.fd = cfd;
e.data.ptr = (void*)cfd;

epoll_data -- это union, не нужно его инициализировать сначала одним, а потом другим:

typedef union epoll_data {
               void    *ptr;
               int      fd;
               uint32_t u32;
               uint64_t u64;
           } epoll_data_t;

           struct epoll_event {
               uint32_t     events;    /* Epoll events */
               epoll_data_t data;      /* User data variable */
           };

в документации сказано, что там должен быть дескриптор серверного сокета

в документации сказано, что там должно быть значение, которое было в поле data во время вызова epoll_ctl.

Кроме того, 0 -- вполне нормальный файловый дескриптор.
Короче, я попробовал, у меня работает. Если у тебя не работает -- приведи весь код.

Есть ли подобные статьи для 64-бит архитектуры?

Зачем? В этой статье почти нет процессорной специфики -- там описаны потроха С-рантайма, библиотеки С и динамического линковщика. Любая программа на С для любой архитектуры при запуске проходит через те же стадии.

cmd1 | cmd2 | cmd3
В данном примере все три команды делят между собой ресурсы одного ядра процессора.

Вовсе нет. Они получают все доступные ресурсы в своё распоряжение. Проблема может быть в том, что cmd1 не производит достаточно данных, чтобы cmd2 загрузил ядро на 100%, либо cmd2 не читает данные достаточно быстро и тормозит cmd1, и то же самое в паре cmd2 | cmd3.

она требует sudo пароль

Это не "она требует", это у тебя sudo так настроен. Настрой его по-человечески, чтобы пароль не требовался (совсем, или только для запуска tcpdump) -- и у тебя будет на одну проблему меньше.

Как на Си вывести флаги в том же формате, что делает команда objdump?

А в код-то не посмотреть никак?

static void
dump_bfd_header (bfd *abfd)
{
  char *comma = "";

  printf (_("architecture: %s, "),
          bfd_printable_arch_mach (bfd_get_arch (abfd),
                                   bfd_get_mach (abfd)));
  printf (_("flags 0x%08x:\n"), abfd->flags & ~BFD_FLAGS_FOR_BFD_USE_MASK);

#define PF(x, y)    if (abfd->flags & x) {printf("%s%s", comma, y); comma=", ";}
  PF (HAS_RELOC, "HAS_RELOC");
  PF (EXEC_P, "EXEC_P");
  PF (HAS_LINENO, "HAS_LINENO");
  PF (HAS_DEBUG, "HAS_DEBUG");
  PF (HAS_SYMS, "HAS_SYMS");
  PF (HAS_LOCALS, "HAS_LOCALS");
  PF (DYNAMIC, "DYNAMIC");
  PF (WP_TEXT, "WP_TEXT");
  PF (D_PAGED, "D_PAGED");
  PF (BFD_IS_RELAXABLE, "BFD_IS_RELAXABLE");
  printf (_("\nstart address 0x"));
  bfd_printf_vma (abfd, abfd->start_address);
  printf ("\n");
}

В чем может быть дело?

Похоже на не-английскую раскладку клавиатуры.

Но при проверки им
gpg --verify ncopa.asc alpine-standard-3.9.0-x86_64.iso.sha256
пишет что gpg: verify signatures failed: Неожиданная ошибка.

alpine-standard-3.9.0-x86_64.iso.sha256 -- это просто sha256 от iso, там нет подписи. Подпись должна быть в файле с расширением .asc за кнопкой "GPG", но там 404.
Судя по содержимому dl-cdn.alpinelinux.org/alpine/v3.9/releases/x86_64 подписи всё-таки есть для некоторых .iso

В общем вопрос простой, как установить этот модуль в ядро без затрат здоровья!? Может кто то ставил? Может я что то явно делаю не так?

Ты определённо что-то делаешь не так. Начиная с того, что autosleep -- это не модуль:

$ grep -A1 PM_AUTOSLEEP kernel/power/Kconfig
config PM_AUTOSLEEP
        bool "Opportunistic sleep"

У модуля тип был бы не bool а tristate.
Всё что ты можешь сделать -- это собрать новое ядро с этой опцией.

А RTFM -- не модно уже?:

What:		/sys/power/autosleep
Date:		April 2012
Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
		The /sys/power/autosleep file can be written one of the strings
		returned by reads from /sys/power/state.  If that happens, a
		work item attempting to trigger a transition of the system to
		the sleep state represented by that string is queued up.  This
		attempt will only succeed if there are no active wakeup sources
		in the system at that time.  After every execution, regardless
		of whether or not the attempt to put the system to sleep has
		succeeded, the work item requeues itself until user space
		writes "off" to /sys/power/autosleep.

Что у тебя в /sys/power/state?

в файле /sys/power/autosleep -стоит "off", файл не редактируется

Как редактируешь?

Как вывести mac адрес сетевого интерфейса, зная что его ip начинается с 128.15. ?

ip addr | sed -n '/link/h;/inet 128\.15\./{g;p}'