linux-kernel - Re: [take 3] Use pid in inotify events.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <517f3f820811210620o34307610hf926bbe3b3828e8c@mail.gmail.com>
Date:	Fri, 21 Nov 2008 09:20:39 -0500
From:	"Michael Kerrisk" <mtk.manpages@...il.com>
To:	"Evgeniy Polyakov" <zbr@...emap.net>
Cc:	"Pavel Machek" <pavel@...e.cz>, "Robert Love" <rlove@...ve.org>,
	linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Christoph Hellwig" <hch@....de>,
	"John McCutchan" <john@...nmccutchan.com>
Subject: Re: [take 3] Use pid in inotify events.

>> > And I actually answered, that this may be a good idea for the new
>> > project. Although if things work right now no one will ever try to
>> > change it. It does not work in my case, so I need to invent as simple
>> > as possible way to fix it.
>>
>> 'as simple diff as possible' is pretty bad criterium for kernel
>> merges.
>
> Critics without suggestions is useless. What did you try to say here?
> You you believe it should be done in a different way, please tell us how
> you see this should be implemented.

Hi Evgeniy,

I think the point is this.  You want to introduce a change that
address the needs of a single application.  Many others see the
change, which though it may be simple and quick to implement, as "an
ugly hack" -- it messes up an otherwise rather well designed API.
Should we make such a change?  I think not -- and others are echoing
that sentiment.  Your argument that "we should do this because no-one
else has proposed a better way" is not sufficient rationale for
uglifying this API to serve the needs of a single app -- the argument
will not fly, no matter how many times you repeat it.  (Your statement
"Critics without suggestions is useless" does not hold: one very
useful purpose of critics is to maintain the status quo of "good
taste" in API design.)

At this stage, I see three possibilities -- you maintain an
out-of-mainline patch for the kernel, and distribute that with your
app; you work out some other *userspace* solution to your problem; or
someone comes up with inotify-ng, designed to address your needs and
those of others (okay, we may not know what those other needs are yet,
but the question is if we could come up with an inotify-ng design that
can extensible in a sane way).  I know that none of these options will
be what you are happy with, but all of them have more life than your
proposal, IMO.

Cheers,

Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/