Messages in this thread | | | Date | Fri, 21 Nov 2008 09:20:39 -0500 | From | "Michael Kerrisk" <> | 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
| |