On Tue, 27 Jan 2015 19:13:29 +0100
Alexander Holler <holler@xxxxxxxxxxxxx> 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-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
