проект книги: "Модули ядра Linux"

[Olej]

Вся рекурсивная сбока там набралась довольно продолжительная:

Код: Выделить всё

[olej@notebook Kexamples.BOOK]$ time make
real	0m54.982s
user	0m27.539s
sys	0m18.967s

и это не на самом медленном процессоре:

Код: Выделить всё

[olej@notebook include]$ cat /proc/cpuinfo | grep name
model name	: Genuine Intel(R) CPU           T2300  @ 1.66GHz
model name	: Genuine Intel(R) CPU           T2300  @ 1.66GHz

[Olej]

Спасибо за подсказки.
Появился повод проделать тщательную ревизию всего дерева ;) - вылезают всякие попутные мелкие огрехи.

Да на самом то деле спасибо Вам за то что дали повод покапаться в таких интересностях. Было б больше свободного времени, прочитал бы за раз не отрываясь )))
Я по мере возможности буду разбирать Ваши примеры и если что-то ещё будет "вылазить" обязательно буду сообщать.

Ну, вот архив проектов-примеров, правленный и с вашей, в том числе, помощью:
http://file.qip.ru/file/bX7etDns/Kexamples144.html
(размер оказался великоват - 791Kb, чтоб присоединить его прямо сюда ... а жаль - не знаю как долго файл будет там сохраняться, не помню для этого файлохранилища).

Там, кроме улучшения рекурсивной сборки, сделано много подчисток + всё проверено, теперь можете из корня дерева разархивированного сделать:

Код: Выделить всё

$ make
$ make clean

чтоб собрались все примеры за раз.
make clean - не должен вас смущать: он потрёт только промежуточные и временные файлы.
для полной очистки дерева в исходное состояние (только исходные коды):

Код: Выделить всё

$ make disclean

В архиве заметно больше примеров, чем в последних выложенных редакциях текста, это примеры отработанные за прошедшее время. Можете и их рассмотреть... Но всё предыдущее - исправно и работоспособно, хотя кое-где и улучшено.

[bose]

Вот, ещё "накопал"...

В главе 4 есть пункт "Как собрать модуль из нескольких объектных файлов?" http://rus-linux.net/MyLDP/BOOKS/Moduli ... -05.html#5, в нём есть отрывок из Makefile, который демонстрирует собственно всю "кухню" (как вы сами написали - "Самое интересное в этом проекте, это:" ) . В дереве сэмплов этот файл находится здесь - Kexamples.BOOK/tools/mobj/Makefile. Так вот цель

Код: Выделить всё

$(TARGET).o: $(OBJS)
<----->$(LD) -r -o $@ $(OBJS)

в нём является избыточной, так как вся "магия" происходит здесь:

Код: Выделить всё

$(TARGET)-objs := $(OBJS)

Documentation/kbuild/makefiles.txt - 3.2 Built-in object goals - obj-y

Kbuild compiles all the $(obj-y) files. It then calls
<------>"$(LD) -r" to merge these files into one built-in.o file.
<------>built-in.o is later linked into vmlinux by the parent Makefile.

Есть ещё один момент, который указан в Linux Documentation, касательно сборки модуля из нескольких объектных файлов (Documentation/kbuild/modules.txt - 3. Creating a Kbuild File for an External Module):

When the module is built from multiple sources, an additional line is
needed listing the files:

<------><module_name>-y := <src1>.o <src2>.o ...

Ну по скольку работает вариант и с -objs и с -y (тем более что в большинстве документации (в т.ч. LKMPG) по модулям ядра указан вариант -objs), какой из них правильный я не знаю.

Ну и ещё по поводу цели clean. В kbuild эта цель уже есть (т.е. не нужно её описывать вручную):
Documentation/kbuild/modules.txt - 2.3 Targets
выглядит так:

Код: Выделить всё

clean:
<------>$(MAKE) -C $(KDIR) M=$(PWD) clean

Единственное но - вместе с водой она (цель) выплёскивает и дитя (удаляет модули - *.ko), что не происходит в вашем варианте (может такая задумка у вас и была).

[Olej]

Ну и ещё по поводу цели clean. В kbuild эта цель уже есть (т.е. не нужно её описывать вручную):
Documentation/kbuild/modules.txt - 2.3 Targets
выглядит так:

Код: Выделить всё

clean:
<------>$(MAKE) -C $(KDIR) M=$(PWD) clean

Единственное но - вместе с водой она (цель) выплёскивает и дитя (удаляет модули - *.ko), что не происходит в вашем варианте (может такая задумка у вас и была).

я именно для этого и переопределил цель clean: вытереть все промежуточные файлы кроме построенных модулей и исполнимых файлов процессов.
а для полной чистки (до уровня: оставить только исходные коды) там есть другая цель: disclean

P.S. мне как-то думать не хотелось ;), а такую структуру и такое название целей я видел где-то в проектах PBX-коммутаторов VoIP - Asterisk или FreeSWITCH - вот так как у них и позаимствовал.

[Olej]

В главе 4 есть пункт "Как собрать модуль из нескольких объектных файлов?" http://rus-linux.net/MyLDP/BOOKS/Moduli ... -05.html#5, в нём есть отрывок из Makefile, который демонстрирует собственно всю "кухню" (как вы сами написали - "Самое интересное в этом проекте, это:" ) . В дереве сэмплов этот файл находится здесь - Kexamples.BOOK/tools/mobj/Makefile. Так вот цель

Код: Выделить всё

$(TARGET).o: $(OBJS)
<----->$(LD) -r -o $@ $(OBJS)

в нём является избыточной, так как вся "магия" происходит здесь:

Код: Выделить всё

$(TARGET)-objs := $(OBJS)

Documentation/kbuild/makefiles.txt - 3.2 Built-in object goals - obj-y

Kbuild compiles all the $(obj-y) files. It then calls
<------>"$(LD) -r" to merge these files into one built-in.o file.
<------>built-in.o is later linked into vmlinux by the parent Makefile.

Проверил на живом проекте. Да, это так. Поправлю.
<----->$(LD) -r -o $@ $(OBJS) - это, наверное, от каких-то моих прежних экспериментов "застряло" ;)

Есть ещё один момент, который указан в Linux Documentation, касательно сборки модуля из нескольких объектных файлов (Documentation/kbuild/modules.txt - 3. Creating a Kbuild File for an External Module):

When the module is built from multiple sources, an additional line is
needed listing the files:

<------><module_name>-y := <src1>.o <src2>.o ...

Ну по скольку работает вариант и с -objs и с -y (тем более что в большинстве документации (в т.ч. LKMPG) по модулям ядра указан вариант -objs), какой из них правильный я не знаю.

Нужно ли об этом упоминать в тексте?
И как в таком случае будет выглядеть Makefile?

[Olej]

Проверил на живом проекте. Да, это так. Поправлю.
<----->$(LD) -r -o $@ $(OBJS) - это, наверное, от каких-то моих прежних экспериментов "застряло" ;)

Переделал.
Теперь содержательная часть Makefile (после определения переменных и до всяких второстепенных целей) выглядит так:

Код: Выделить всё

TARGET = mobj
TARGET2 = mcall

OBJS = mod.o mfA.o mfB.o mfC.o
$(TARGET)-objs := $(OBJS)
obj-m      := $(TARGET).o $(TARGET2).o

all:    modules clean

modules:
        $(MAKE) -C $(KDIR) M=$(PWD) modules

Есть ещё один момент, который указан в Linux Documentation, касательно сборки модуля из нескольких объектных файлов (Documentation/kbuild/modules.txt - 3. Creating a Kbuild File for an External Module):

When the module is built from multiple sources, an additional line is
needed listing the files:

<------><module_name>-y := <src1>.o <src2>.o ...

Ну по скольку работает вариант и с -objs и с -y (тем более что в большинстве документации (в т.ч. LKMPG) по модулям ядра указан вариант -objs), какой из них правильный я не знаю.

Нужно ли об этом упоминать в тексте?
И как в таком случае будет выглядеть Makefile?

А этим правилом я попробовал воспользоваться (написать альтернативный Makefile) ... но что-то он у меня нещадно ругается! ;) :(

[bose]

На одной из веток сделал комментарий, который касается данной темы обсуждения, по-этому продублирую ссылкой:
viewtopic.php?f=9&p=2980#p2980

[Olej]

На одной из веток сделал комментарий, который касается данной темы обсуждения, по-этому продублирую ссылкой:
viewtopic.php?f=9&p=2980#p2980

я уже это видел, и даже ответил ;)
но я не понимаю как (и не понимаю нужно ли) это как-то отмечать в тексте:

- ведь на любой другой платформе: ARM, MIPS, PPC, ... это будет ещё по-другому и по-своему, и они имею равные права, вроде бы как ;), с Intel IA-64 ? ;)

- более того! такие ассемблерные решения будут отличаться на AMD_64 и IA-64 ... у них даже наборы регистров отличаются - это только пользователю высокоуровневого языка кажется, что он имеет перед собой "64-бит платформу" - нет такой платформы! ;) это ему компилятор GCC создаёт иллюзию такой платформы ;)

[bose]

но я не понимаю как (и не понимаю нужно ли) это как-то отмечать в тексте:

Нет, думаю в этом нет практического смысла (описывать все возможные варианты/платформы.).
Просто эта проблема натолкнула на мысль, что, полезно было бы посвятить отдельный пункт, такой не мало важной теме как.... даже не знаю как это обозвать.... что то вроде "конфигурация ядра и условная компиляция". Вот, например, The Kernel Configuration and Build Process - http://www.linuxjournal.com/article/6568?page=0,0 (хотя ресурс старый). Или здесь упомянуто - 7.1 Testing for CONFIG_FOO_BAR Documentation/kbuild/modules.txt .

Modules often need to check for certain CONFIG_ options to
decide if a specific feature is included in the module. In
kbuild this is done by referencing the CONFIG_ variable
directly.

Ну, смысл такой что б во время компиляции уже было понятно, что пытаешься пользоваться возможностями, которые target platform not supported
mm/percpu-km.c:30

Код: Выделить всё

#if defined(CONFIG_SMP) && defined(CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK)
#error "contiguous percpu allocation is incompatible with paged first chunk"
#endif

[Olej]

но я не понимаю как (и не понимаю нужно ли) это как-то отмечать в тексте:

Нет, думаю в этом нет практического смысла (описывать все возможные варианты/платформы.).
Просто эта проблема натолкнула на мысль, что, полезно было бы посвятить отдельный пункт, такой не мало важной теме как.... даже не знаю как это обозвать.... что то вроде "конфигурация ядра и условная компиляция". Вот, например, The Kernel Configuration and Build Process - http://www.linuxjournal.com/article/6568?page=0,0 (хотя ресурс старый). Или здесь упомянуто - 7.1 Testing for CONFIG_FOO_BAR Documentation/kbuild/modules.txt .

Modules often need to check for certain CONFIG_ options to
decide if a specific feature is included in the module. In
kbuild this is done by referencing the CONFIG_ variable
directly.

Ну, смысл такой что б во время компиляции уже было понятно, что пытаешься пользоваться возможностями, которые target platform not supported
mm/percpu-km.c:30

Код: Выделить всё

#if defined(CONFIG_SMP) && defined(CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK)
#error "contiguous percpu allocation is incompatible with paged first chunk"
#endif

не исключено ... надо подумать.
но только в том смысле, что:

- я специально насколько мог в тексте (и в лекциях для разработчиков, для которых этот текст готовился) уходил от вопросов компиляции ядра и вообще ядра...
- начиная с того, что возможности и умение пересборки и компиляции ядра, которой так кичится каждый пыанэр на просторах интернета - не нужными, и возникающими как необходимость очень нечасто...
- поэтому даже не хотел затрагивать вопросы сборки ядра ... и добавил в виде приложения только "по многочисленным просьбам трудящихся" ;)
- так же точно, как и детали механизмов в ядре, то как оно сделано и какие там у них проблемы - пусть об этом голова болит у Линуса Торвальдса со товарищи ... если он считает себя таким умным ;)
- весь текст акцентируется только на модулях ядра, на потребностях прикладного программиста, прикладных проектов...
- поэтому то, о чём речь выше, можно включить как очень краткое дополнение именно как средство контроля, и недопущения компиляции модуля при определённых условиях.