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

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: <20150127132148.365ef397@gandalf.local.home>
Date:	Tue, 27 Jan 2015 13:21:48 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Alexander Holler <holler@...oftware.de>
Cc:	Borislav Petkov <bp@...en8.de>,
	Richard Weinberger <richard@....at>, linux-mmc@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	Chris Ball <chris@...ntf.net>,
	Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [PATCH] mmc: print message if a card supports secure erase/trim

On Tue, 27 Jan 2015 19:13:29 +0100
Alexander Holler <holler@...oftware.de> wrote:

> > Basically, what you are saying is "printk is more convenient for me and
> > I do not care about the other cases that make much more sense with
> > sysfs". The kernel does not work that way.
> 
> No. First I don't know the name of one of the thousands file in sysfs, 
> just like I don't know all the possible kernel messages.

But as Richard mentioned, it should be documented in Documentation/ABI,
and the information you want should be right there. Once you know it,
you will know it for good.

> 
> And second I still believe that KISS is the right way and frameworks 
> aren't the right choice for everything.

But having tools parse dmesg is not KISS. It's backwards. /sys
filesystem is really simple to use. It's not that difficult. And it was
created for just this purpose!

> 
> But because I still don't refuse to learn, I will attach the output of
> 
> find /sys -type f -print -exec cat {} \;
> 
> to future bug reports instead of the output of dmesg.
> 

That is completely different. dmesg will contain back traces which are
not in /sys filesystem, nor do they belong there. dmesg also shows
order of events, which may be needed in debugging, again, sysfs is
about properties and states of devices. How would sysfs be used for
debugging?

You want to add a way to tell a property of a device. That is *exactly*
what sysfs was made for. Not dmesg.

-- Steve

--
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/