Make-initrd development discussion
 help / color / mirror / Atom feed
* [make-initrd] Documentation
@ 2019-11-07 11:11 Alexey Gladkov
  2019-11-07 13:33 ` Michael Shigorin
  0 siblings, 1 reply; 6+ messages in thread
From: Alexey Gladkov @ 2019-11-07 11:11 UTC (permalink / raw)
  To: make-initrd

Привет!

Я тут обновил документацию и дописал немного. Не мог бы кто-нибудь кто
хорошо знает язык Шекспира прочитать и написать про ошибки (а лучше PR) ?

https://github.com/legionus/make-initrd/blob/docs/docs/HowItWorks.md
https://github.com/legionus/make-initrd/blob/docs/docs/UeventDetails.md

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [make-initrd] Documentation
  2019-11-07 11:11 [make-initrd] Documentation Alexey Gladkov
@ 2019-11-07 13:33 ` Michael Shigorin
  2019-11-07 13:58   ` Alexey Gladkov
  2019-11-07 14:26   ` Alexey Gladkov
  0 siblings, 2 replies; 6+ messages in thread
From: Michael Shigorin @ 2019-11-07 13:33 UTC (permalink / raw)
  To: make-initrd

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

On Thu, Nov 07, 2019 at 12:11:09PM +0100, Alexey Gladkov wrote:
> Я тут обновил документацию и дописал немного. Не мог бы кто-нибудь кто
> хорошо знает язык Шекспира прочитать и написать про ошибки (а лучше PR) ?
> 
> https://github.com/legionus/make-initrd/blob/docs/docs/HowItWorks.md

Вот здесь что именно ты хотел сказать около второго "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.
---

> https://github.com/legionus/make-initrd/blob/docs/docs/UeventDetails.md

Не обнаружил разницы между двумя

---
`/.initrd/uevent/queues/<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: 5593 bytes --]

>From 0d5f8f75d7e14bfecee238ae340fe40b931cbd95 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    | 34 +++++++++++++++++-----------------
 docs/UeventDetails.md | 18 +++++++++---------
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/docs/HowItWorks.md b/docs/HowItWorks.md
index b121e4f..df91666 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
+The `udevd` listens to kernel events and performs actions according to its rules.
+Since we cannot run long-running processes, the forked 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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [make-initrd] Documentation
  2019-11-07 13:33 ` Michael Shigorin
@ 2019-11-07 13:58   ` Alexey Gladkov
  2019-11-07 14:25     ` Michael Shigorin
  2019-11-07 14:26   ` Alexey Gladkov
  1 sibling, 1 reply; 6+ messages in thread
From: Alexey Gladkov @ 2019-11-07 13:58 UTC (permalink / raw)
  To: Michael Shigorin; +Cc: make-initrd

On Thu, Nov 07, 2019 at 04:33:15PM +0300, Michael Shigorin wrote:
> On Thu, Nov 07, 2019 at 12:11:09PM +0100, Alexey Gladkov wrote:
> > Я тут обновил документацию и дописал немного. Не мог бы кто-нибудь кто
> > хорошо знает язык Шекспира прочитать и написать про ошибки (а лучше PR) ?
> > 
> > https://github.com/legionus/make-initrd/blob/docs/docs/HowItWorks.md
> 
> Вот здесь что именно ты хотел сказать около второго "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>

Ты про эти пути ?

> (там вроде события из одного в другое перекладывают?)

Да.

> Пока такой патчик получился -- там в комплексе грамматика
> и читаемость, если это лишнее, сообщи.

Спасибо! Сейчас обновлю бранч с форсом.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [make-initrd] Documentation
  2019-11-07 13:58   ` Alexey Gladkov
@ 2019-11-07 14:25     ` Michael Shigorin
  0 siblings, 0 replies; 6+ messages in thread
From: Michael Shigorin @ 2019-11-07 14:25 UTC (permalink / raw)
  To: make-initrd

[-- 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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [make-initrd] Documentation
  2019-11-07 13:33 ` Michael Shigorin
  2019-11-07 13:58   ` Alexey Gladkov
@ 2019-11-07 14:26   ` Alexey Gladkov
  2019-11-07 14:28     ` Michael Shigorin
  1 sibling, 1 reply; 6+ messages in thread
From: Alexey Gladkov @ 2019-11-07 14:26 UTC (permalink / raw)
  To: Michael Shigorin; +Cc: make-initrd

On Thu, Nov 07, 2019 at 04:33:15PM +0300, Michael Shigorin wrote:
> Пока такой патчик получился -- там в комплексе грамматика
> и читаемость, если это лишнее, сообщи.

Миш, спасибо тебе большое! Ты меня всегда выручаешь. Также я теперь знаю,
что это хоть кто-то прочитал :)

Ну а в остальном понятно как работает ?
Не хочу унести эту тайну в могилу :)

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [make-initrd] Documentation
  2019-11-07 14:26   ` Alexey Gladkov
@ 2019-11-07 14:28     ` Michael Shigorin
  0 siblings, 0 replies; 6+ messages in thread
From: Michael Shigorin @ 2019-11-07 14:28 UTC (permalink / raw)
  To: make-initrd

On Thu, Nov 07, 2019 at 03:26:25PM +0100, Alexey Gladkov wrote:
> On Thu, Nov 07, 2019 at 04:33:15PM +0300, Michael Shigorin wrote:
> > Пока такой патчик получился -- там в комплексе грамматика
> > и читаемость, если это лишнее, сообщи.
> Миш, спасибо тебе большое! Ты меня всегда выручаешь.

Лёш, это _ты_ меня всегда выручаешь, а вот за мной сразу
несколько обещанных тебе, но так и не сделанных вещей
(начиная с выправления того ужаса с efi в mkimage)...

> Ну а в остальном понятно как работает ?
> Не хочу унести эту тайну в могилу :)

Да, и схемка очень полезная, прям глаз радует и понималку. :)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-11-07 14:28 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-07 11:11 [make-initrd] Documentation Alexey Gladkov
2019-11-07 13:33 ` Michael Shigorin
2019-11-07 13:58   ` Alexey Gladkov
2019-11-07 14:25     ` Michael Shigorin
2019-11-07 14:26   ` Alexey Gladkov
2019-11-07 14:28     ` Michael Shigorin

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