linux-kernel - Re: proper struct device selection for dev

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: <CAPXgP11ktmMcLvwYy9PvyZ_J9bmmAzdmqzKCVE6Q0dbKHyG9eg@mail.gmail.com>
Date:	Thu, 3 May 2012 21:12:43 +0200
From:	Kay Sievers <kay@...y.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
	Henrik Rydberg <rydberg@...omail.se>
Subject: Re: proper struct device selection for dev_printk()

On Thu, May 3, 2012 at 8:47 PM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
> On Thu, May 03, 2012 at 07:50:52PM +0200, Kay Sievers wrote:

>> I guess it all depends who is the consumer of the messages, and I
>> would say if userspace is the intended consumer, always use the device
>> that provides the access/interface to userspace. It's easy to walk up
>> the tree and find out about the other things.
>
> This would be:
>
> 1. Impossible in most cases
> 2. If it was possible it woudl have to be layer violation.

Yeah, if it would be easy, Greg would not have written the mail. :)

> Taking psmouse as an example you have no idea which interface to use to
> report errors - mouse2, event6 or js1 - these are what visible from
> userspace and all of them could report to the same input device.

True, if the error does not propagate up to the class device, it does
not sound right to do that. But it's still the case that userspace or
any automated message consumer cannot make much sense out of the
message then. It's still targeted at a human.

> We
> however know exactly what serio port we had trouble with.

Sure, if the error occurs in that context, it should be logged with
exactly that context. If it propagates up to the higher devices they
should log themselves.

The point I tried to make was, that we should not in general walk up
to the next bus device for logging, and that the parent devices are
not more useful in general. I wanted to express that a rule like: "In
general, drivers should emit messages for the devices they bind to."
is not the right thing to do, if we *can* establish a context to the
device that is used in userspace.

But sure, if the error can not be propagated to the child devices, we
should not fake anything here either, but the stuff should stay where
it happened.

> Now consider error happending on i8042 level. Do we descend into
> serio layer and reportan error there? Why? Serio layer is perfectly
> fine, and besides why would we confuse user that psmouse driver had an
> issue whereas it was i8042 that needs to be looked at?

As said, it all depends on the intended consumer. Messages about
i8042 devices are not interesting at all for userspace or for
automatic log analysis.

> Also, I do not think that vague "userspace" is consumer for these
> messages; this is really something a human needs to look at and analyze.

Right, they are mainly useful for a human being only. So the attached
metadata does not really matter that much.

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