From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 7 Nov 2019 17:25:21 +0300 From: Michael Shigorin To: make-initrd@lists.altlinux.org Message-ID: <20191107142519.GF29388@imap.altlinux.org> References: <20191107111109.dt6eltsgtq4mmbtj@MacBook-PC.fortress> <20191107133315.GE29263@imap.altlinux.org> <20191107135832.dvusgpfk7njvspgf@MacBook-PC.fortress> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Bu8it7iiRSEf40bY" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20191107135832.dvusgpfk7njvspgf@MacBook-PC.fortress> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [make-initrd] Documentation X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: make-initrd@lists.altlinux.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 14:25:22 -0000 Archived-At: List-Archive: --Bu8it7iiRSEf40bY Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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// > /.initrd/uevent/events// > Ты про эти пути ? Всё, так заметил, вопрос снят. > > Пока такой патчик получился -- там в комплексе грамматика > > и читаемость, если это лишнее, сообщи. > Спасибо! Сейчас обновлю бранч с форсом. Ой, возьми чуточку подновлённый патч только. Потрогал ровно то место, которое ты разъяснил. --  ---- WBR, Michael Shigorin / http://altlinux.org   ------ http://opennet.ru / http://anna-news.info --Bu8it7iiRSEf40bY Content-Type: text/x-patch; charset=us-ascii Content-Disposition: attachment; filename="0001-docs-a-quick-proofreading.patch" >>From 28093a787fd7a11b6ab7244d90fa12b4fa93be98 Mon Sep 17 00:00:00 2001 From: Michael Shigorin 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//` @@ -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//[0-9][0-9][0-9]-` -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 `` is passed as an argument. This function returns the eventfile. -- 2.10.4 --Bu8it7iiRSEf40bY--