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: <54C7D08E.8030309@broadcom.com>
Date:	Tue, 27 Jan 2015 18:53:18 +0100
From:	Arend van Spriel <arend@...adcom.com>
To:	Alexander Holler <holler@...oftware.de>
CC:	Steven Rostedt <rostedt@...dmis.org>,
	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 01/27/15 18:38, Alexander Holler wrote:
> Am 27.01.2015 um 18:24 schrieb Steven Rostedt:
>
>> 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.
>
> Oh, systemd.
>
> Anyway, I like(d) Linux because it didn't had a splash screen and used
> to spit out all types of information on the screen where it could be
> easily seen or found (in contrast other OS which try to hide all
> technical details from users).

What ends up in kernel log is still a fraction of what is going on in 
the kernel.

> Of course, times are changing, including the amount of stuff printed on
> screen. But I still find it much much easier to grep on the output of
> dmesg than to search through thousands files in sysfs. Even if that can
> be done with grep too (kind of). But it's much more complicated because
> grep doesn't connect the file name with the content, so you need more
> complicated stuff to combine both in order to search for and find
> something in sysfs.

Ever used rgrep or grep -R. Anyway, if this is you use-case what about 
the gazillion other pieces of info in the kernel. When moving in that 
direction you can be sure dmesg will flush out.

Regards,
Arend

> Regards,
>
> Alexander Holler
> --
> 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/

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