Make-initrd development discussion
 help / color / mirror / Atom feed
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


  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