Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

Alexander,

On Wed, Feb 4, 2015 at 1:22 PM, Alexander Holler [off-list ref] wrote:

Am 04.02.2015 um 13:07 schrieb Lukáš Czerner:

quoted

The fact is that the current patches are useless for anything other
than proof-of-concept. Now you know more that needs to be done or

That's wrong. The patches already work. If you delete a file which isn't in
use by something else, the current contents will be wiped on traditional
harddrives. I assume that already fulfills more than 50% of use cases of
ordinary people.

You are getting various feedback from people, that you seem to be ignoring.

Al Viro, in his curmedgeonly way, points out that the problems are
much deeper than you realize. He does not say so explicitly, but I
imagine his point is that he does not want to see the kernel cluttered
with "partial" solutions that will simply increase the maintenance
burden in the long term, and leave bugs to be fixed further down the
line. You seem not to be listening.

Lukáš points out to you that getting a feature like this into the
kernel is complex process. You seem unwilling to hear that, and still
just want your partial solution.

I tell you that discussions of APIs should CC linux-api, which I am
now CCing into this thread, again, because, again, you're not
listening to feedback.

Nobody is asking for "high towers"; they just have their eyes on the
big picture. And the people here are just "ordinary people" with a
*lot* of experience dealing with kernel code (I exclude myself) . They
see many complexities that you don't. Getting intersting features into
the kernel requires a lot of work, and careful listening.

Thanks,

Michael


-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Am 04.02.2015 um 14:06 schrieb Michael Kerrisk:

Alexander,

On Wed, Feb 4, 2015 at 1:22 PM, Alexander Holler [off-list ref] wrote:

quoted

Am 04.02.2015 um 13:07 schrieb Lukáš Czerner:

quoted

The fact is that the current patches are useless for anything other
than proof-of-concept. Now you know more that needs to be done or

That's wrong. The patches already work. If you delete a file which isn't in
use by something else, the current contents will be wiped on traditional
harddrives. I assume that already fulfills more than 50% of use cases of
ordinary people.

You are getting various feedback from people, that you seem to be ignoring.

I'm happy for all the feedback. But it doesn't help me. I'm not going to 
spend the necessary time unpaid.
.

Al Viro, in his curmedgeonly way, points out that the problems are
much deeper than you realize. He does not say so explicitly, but I
imagine his point is that he does not want to see the kernel cluttered
with "partial" solutions that will simply increase the maintenance
burden in the long term, and leave bugs to be fixed further down the
line. You seem not to be listening.

It doesn't help me nor anyone else. As Eric Sandeen made me aware 
through in bug, look at http://lwn.net/Articles/462437/ what already 
happened.

Lukáš points out to you that getting a feature like this into the
kernel is complex process. You seem unwilling to hear that, and still
just want your partial solution.

Wrong. I don't want my partial solution to be part of the official 
kernel. I don't care. I offered it for other users because I'm aware 
that has become almost impossible for normal people to get something 
into the kernel without spending an unbelievable amount of time most 
people can't afford to spend.

I tell you that discussions of APIs should CC linux-api, which I am
now CCing into this thread, again, because, again, you're not
listening to feedback.

Please don't confuse "not listening" with "unable to fulfill Linux 
kernel maintainer requests".

Alexander Holler