From: Michael Shigorin <mike@altlinux.org> To: make-initrd@lists.altlinux.org Subject: Re: [make-initrd] Documentation Date: Thu, 7 Nov 2019 17:25:21 +0300 Message-ID: <20191107142519.GF29388@imap.altlinux.org> (raw) In-Reply-To: <20191107135832.dvusgpfk7njvspgf@MacBook-PC.fortress> [-- Attachment #1: Type: text/plain, Size: 1213 bytes --] On Thu, Nov 07, 2019 at 02:58:32PM +0100, Alexey Gladkov wrote: > > Вот здесь что именно ты хотел сказать около второго "we"? > > Не понял, кто на ком стоял -- запускаем форков или фильтров. > > --- > > Since we cannot run long-running processes, the forked processes > > we run special `filters` (small simple scripts) to save event > > information for future use. > > --- > --- > Поскольку в udev мы не можем выполнять долго живущие процессы и форкать > процессы, то мы выполняем специальные фильтры для того чтобы сохранить > информацию об эвенте для дальнейшего использования. > --- Отлично, так-то понятно :-) > > > https://github.com/legionus/make-initrd/blob/docs/docs/UeventDetails.md > > Не обнаружил разницы между двумя > /.initrd/uevent/queues/<QUEUE>/<EVENT> > /.initrd/uevent/events/<QUEUE>/<EVENT> > Ты про эти пути ? Всё, так заметил, вопрос снят. > > Пока такой патчик получился -- там в комплексе грамматика > > и читаемость, если это лишнее, сообщи. > Спасибо! Сейчас обновлю бранч с форсом. Ой, возьми чуточку подновлённый патч только. Потрогал ровно то место, которое ты разъяснил. -- ---- WBR, Michael Shigorin / http://altlinux.org ------ http://opennet.ru / http://anna-news.info [-- Attachment #2: 0001-docs-a-quick-proofreading.patch --] [-- Type: text/x-patch, Size: 5730 bytes --] >From 28093a787fd7a11b6ab7244d90fa12b4fa93be98 Mon Sep 17 00:00:00 2001 From: Michael Shigorin <mike@altlinux.org> Date: Thu, 7 Nov 2019 16:32:24 +0300 Subject: [PATCH] docs: a quick proofreading --- docs/HowItWorks.md | 38 +++++++++++++++++++------------------- docs/UeventDetails.md | 18 +++++++++--------- 2 files changed, 28 insertions(+), 28 deletions(-) diff --git a/docs/HowItWorks.md b/docs/HowItWorks.md index b121e4f..cbb4470 100644 --- a/docs/HowItWorks.md +++ b/docs/HowItWorks.md @@ -1,10 +1,10 @@ # How it works ? -When we talking about event-driven infrastructure it means that there is no +When we talk about event-driven infrastructure it means that there is no hardcoded sequence of steps to mount system root. -The initramfs init starts few services: udevd, ueventd, polld. The interaction -between the services looks like this: +The initramfs init starts a few services: udevd, ueventd, polld. +The interaction between these services looks like this: ``` .==========. .----------------. .------------------. @@ -28,28 +28,28 @@ between the services looks like this: '---------' '-----------------' ``` -The `udevd` listen for kernel events and according to his rules performs -actions. Since we cannot run long-running processes, the forked processes we run -a special `filters` (small simple scripts) to save event information for future -use. All events are added in one queue. The queue is implemented on -the filesystem. Fortunately, our filesystem is located in memory. +The `udevd` listens to kernel events and performs actions according to its rules. +Since we cannot run long-running processes or fork processes, we run special +`filters` (small simple scripts) to save event information for future use. +All events are added in one queue. The queue is implemented on the filesystem. +Fortunately, our filesystem is located in memory. -To process saved events we use `ueventd`. The `ueventd` is a simple queue -deamon. Each event in the queue is processed one by one in the order of arrival, -but daemon can process several queues in parallel. This deamon calls `handlers` -for events in the queue. The `handler` implements one aspect of boot (lvm, raid, -luks, mount device, etc). +`ueventd` processes saved events. It's is a simple queue daemon. Each event in +the queue is processed one by one in the order of arrival, but daemon can +process several queues in parallel. It calls `handlers` for events in the +queue. A `handler` implements one aspect of boot (lvm, raid, luks, mount +device, etc). -For example, if we got events about all block devices needed for raid then +For example, if we got events about all block devices needed for MD RAID then the raid-handler will assemble it. This in turn will spawn a new kernel event -about the appearance of /dev/md0. Now, mount-handler can check it and if this is -the root of the system, then handler will mount this block device. +about the appearance of /dev/md0. Now, mount-handler can check it and if it +contains the root filesystem, then handler will mount this block device. So, we mounted some block devices somewhere. We need something that would make -a decision that we have all the conditions for real system boot. The `polld` is +a decision that we met all the conditions for real system boot. The `polld` is responsible for this. The server periodically runs `extenders` scripts that -perform checks (console is not active, the system init was found, etc.), and -if all scripts succeed, the server initiates a system boot. +perform checks (console is not active, the system init was found, etc.), +and if all scripts succeed, the server initiates a system boot. This scheme is used to mount system root device, resume system, configure network. Basically it's used for everything based on kernel events. diff --git a/docs/UeventDetails.md b/docs/UeventDetails.md index d749c73..a72fd80 100644 --- a/docs/UeventDetails.md +++ b/docs/UeventDetails.md @@ -1,10 +1,10 @@ # Ueventd details -The `ueventd` is a queue deamon. The task of this server is to process events -from the queue. Each event in the queue is processed one by one in the order -of arrival, but daemon can process several queues in parallel. +`ueventd` is a queue daemon. The task of this server is to process events +from the queue. Each event in its queue is processed one by one in the order +of arrival, but several queues can be processed in parallel. -Queues are implemented on the filesystem. All incoming events are placed: +Queues are implemented on the filesystem. All incoming events are placed as: `/.initrd/uevent/queues/<QUEUE>/<EVENT>` @@ -22,20 +22,20 @@ Handlers come in two types: This is an old version of `handlers`. Every handler is not called for every event, but sequentially. A handler can analyze all the events that have arrived -and delete them if considers it necessary. +and discard those if deemed necessary. 2. `/lib/uevent/handlers/<QUEUE>/[0-9][0-9][0-9]-<HANDLER>` -This is a new way how to handle events. Handlers as an argument gets a directory -with events. Just like in the first case, the handler is not called for each -event. +This is the new way to handle events. Handlers gets a directory with events +as an argument. Just like the first case, the handler is not called for +each event. Processed events are prefixed with `done.` or deleted. ## uevent API All `filters` and `handlers` should use `/bin/uevent-sh-functions` as -an interface to events. +the interface to events. `make_event` is used to create a new event. It will not be published yet. The `<QUEUE>` is passed as an argument. This function returns the eventfile. -- 2.10.4
next prev parent reply other threads:[~2019-11-07 14:25 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-07 11:11 Alexey Gladkov 2019-11-07 13:33 ` Michael Shigorin 2019-11-07 13:58 ` Alexey Gladkov 2019-11-07 14:25 ` Michael Shigorin [this message] 2019-11-07 14:26 ` Alexey Gladkov 2019-11-07 14:28 ` Michael Shigorin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191107142519.GF29388@imap.altlinux.org \ --to=mike@altlinux.org \ --cc=make-initrd@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Make-initrd development discussion This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/make-initrd/0 make-initrd/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 make-initrd make-initrd/ http://lore.altlinux.org/make-initrd \ make-initrd@lists.altlinux.org make-initrd@lists.altlinux.ru make-initrd@lists.altlinux.com public-inbox-index make-initrd Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.make-initrd AGPL code for this site: git clone https://public-inbox.org/public-inbox.git