Re: [PATCH] mmc: print message if a card supports secure erase/trim

[Steven Rostedt]

On Tue, Jan 27, 2015 at 05:55:08PM +0100, Alexander Holler wrote:
> >
> >So, even if you don't always agree with them, you need to realize that
> >those are the people responsible for that code and if they request a
> >reasonable change in your submission, you have to do it. It is that
> >simple.
> 
> Totally wrong. I'm free to just stop discussion. That's the difference
> between the old type of os communites and corporates where people do what
> they've got instructed from above without discussion. I offered something
> and wasn't paid to do something.

Yes, you are free to stop this discussion and not do the changes that were
asked. That is your prerogative. If you don't want to do what the maintainer
asked you to do, you have every right to ignore it. The change will just
not go in.

The question is, does someone else want this change too? If not, then this
change will go away and be a footnote of lkml archives. If people would
like this change. The maintainer could easily add it the way he wants it
added. The reason maintainers usually do not do such things is because
it is more polite to have the original submitter do the change and get credit
in the change logs. If the maintainer does the work, the best the original
submitter could get is some mention in the change log. Some people care
about getting the commit credit, so maintainers try to respect that.

> 
> It was worth a try but I don't have to build a framework to achieve
> something simple just because a maintainer requests it.

You are again correct. But as Boris stated, it is the maintainer that must
maintain and defend the code. If someone asks why the code is done some way,
it is the maintainer that must respond. Saying, I just took someone's patch
is not acceptable. The maintainer is responsible for all code that they
maintain regardless if they wrote it or not.

> 
> >  [ Unless you have a good argument against it but that's a different
> >    story and this is what is called the "review" process. ]
> 
> I want to see the mentionend information and want that it is seen and do not
> want to hide it away deep in the sysfs where it actually must be searched.

For most people a message in dmesg is not very useful. What you are asking for
is to print a characteristic of a device. Something that someone might want to
check much later in boot, where, as Boris stated, the dmesg could have been
flushed (by systemd, which loves to write stuff to the kernel buffers), and
there's no way to find out this information. The print message is long gone.
Having a static location like sysfs is the proper place, because user space
tools can always access it.

Is this something a tool would like to find out? If so, parsing dmesg is not
the way to go. Looking it up in sysfs is.

You are free to end this discussion. We are not forcing you to. But it is
obvious that the maintainer does not agree with your approach, so you can
either write a patch that he agrees with or not. If you do not, then you
will not get the feature you want in the kernel. No big deal either way.

-- Steve

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