From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <legion@altlinux.ru>
Date: Sat, 20 May 2023 20:51:49 +0200
From: Alexey Gladkov <legion@altlinux.ru>
To: make-initrd@lists.altlinux.org
Message-ID: <ZGkWxSAucGt+vxij@example.org>
References: <cover.1683200226.git.gladkov.alexey@gmail.com>
 <6b444ed922286eb3df8f5322b1bddf9c55753eb8.1683200226.git.gladkov.alexey@gmail.com>
 <d26b7e31-fd63-8c30-8b7f-a471f5cce793@gmail.com>
 <ZGjIq0Z2RQsFFzxR@example.org>
 <5522f0c1-adac-3db7-e569-05cda6d05d58@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5522f0c1-adac-3db7-e569-05cda6d05d58@gmail.com>
Subject: Re: [make-initrd] [PATCH 1/3] Reimplement ueventd
X-BeenThere: make-initrd@lists.altlinux.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: make-initrd@lists.altlinux.org
List-Id: <make-initrd.lists.altlinux.org>
List-Unsubscribe: <https://lists.altlinux.org/mailman/options/make-initrd>,
 <mailto:make-initrd-request@lists.altlinux.org?subject=unsubscribe>
List-Archive: <http://lists.altlinux.org/pipermail/make-initrd>
List-Post: <mailto:make-initrd@lists.altlinux.org>
List-Help: <mailto:make-initrd-request@lists.altlinux.org?subject=help>
List-Subscribe: <https://lists.altlinux.org/mailman/listinfo/make-initrd>,
 <mailto:make-initrd-request@lists.altlinux.org?subject=subscribe>
X-List-Received-Date: Sat, 20 May 2023 18:51:51 -0000
Archived-At: <http://lore.altlinux.org/make-initrd/ZGkWxSAucGt+vxij@example.org/>
List-Archive: <http://lore.altlinux.org/make-initrd/>

On Sat, May 20, 2023 at 08:23:26PM +0300, Leonid Krivoshein wrote:
> >> Константа FD_MAX, хоть и не определена в использованных
> >> заголовочных файлах, это имя иногда встречается рядом с FD_SET(),
> >> FD_CLR() и им подобным макросам в других исходниках как функция
> >> FD_MAX(x). На всякий случай...
> > Это имя ни с чем не конфликтует.
> >
> > $ grep -re '\<FD_MAX\>' /usr/include | wc -l
> > 0
> 
> Да, но используется зарезервированный префикс FD_, что с каким-то 
> очередным изменением хедеров потенциально может дать конфликт.

Это же можно сказать абсолютно про любые префиксы. Например, PIPE_ тоже
зарезервирован поскольку есть PIPE_BUF и может появиться ещё что-то. Если
идти по этому пути, то для всех символов нужно давать
супер_мега_офигительный_префикс_ для уменьшения вероятности конфликта.

Поэтому я предлагаю не пытаться угадывать будущее и не исправлять
несуществующие баги. Если в будущем случится конфликт, то он легко
исправляется переименованием.

> >>> +
> >>> +enum {
> >>> +	PIPE_READ,
> >>> +	PIPE_WRITE,
> >>> +	PIPE_MAX,
> >>> +};
> >>> +
> >>> +int pipefd[PIPE_MAX];
> >> Данным фрагментом ты как бы говоришь: "я точно знаю, во что это
> >> превратит компилятор", слишком безапелляционно.
> > Стандарт си говорит:
> 
> Пока у компилятора не появится глобальная опция, меняющая стартовое 
> значение для enum, и её не поменяет кто-нибудь в сборочной среде 
> глобально, беспокоиться и правда не стоит.

Ты опять предлагаешь исправлять несуществующие ошибки.

> > [...]
> >>> +		fdcount = epoll_wait(epollfd, ev, EV_MAX, 250);
> >> Почему 250, а не -1? Напоминает не нужный в этом месте "sleep .25". Если
> >> бы демон перезапускался для дефрагментации через какое-то число событий
> >> или спустя сколько-то минут, а тут совсем холостой ход получается.
> > Это сделано намеренно. Раньше ты спрашивал зачем отправлять wfd родителю
> > через пайп. Родитель помечает очередь как F_DIRTY и на следующей итерации
> > эта очередь попробует обработаться даже если новых эвентов нет.
> 
> Тогда стоит ввести флаг и заменить 250 на что-то вроде:
> 
> have_dirty ? 250: -1

Хорошая мысль.

-- 
Rgrds, legion