Thread (20 messages) flat view 20 messages, 4 authors, 2012-05-25

Re: [git pull] Input updates for 3.5-rc0

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2012-05-24 21:57:04
Also in: lkml

On Thu, May 24, 2012 at 02:44:31PM -0700, Linus Torvalds wrote:
On Thu, May 24, 2012 at 2:07 PM, Linus Torvalds
[off-list ref] wrote:
quoted
On Thu, May 24, 2012 at 1:59 PM, Dmitry Torokhov
[off-list ref] wrote:
quoted
I was concerned about the _next_ device (the one that will be created
the moment I plug in the tablet back into the same port) having exact
same name as the one that is half dead and clashing in sysfs and
elsewhere. We used to have issues with this.
Ok, that's certainly a valid concern.

It's still - I think - really sad/wrong that the device name is then
so useless than the drivers end up basically not using it.
Ok, so I wonder if we could solve the issue at least partly by
separating the "print name for kernel messages" from the "name used
for /sysfs etc".

Because you're right: the sysfs uniqueness rules does make it very
hard to do a good job on descriptive names.

Also, in sysfs, you by definition see the parent (hey, it's part of
the path), so in sysfs, duplicating parent data would be useless and
just ugly.

But for dev_dbg(), those sysfs rules actually act against us: the name
of a device is often tied to the parent bus location.

So I wonder if we could teach  dev_printk() to use something more
interesting than "dev_name()" when appropriate? Greg?
Maybe we could traverse up the tree till we find first non-class device
(i.e. device with real driver bound to it)? Then we'd have:

	wacom 2-1.2:1.0/inputX/eventY: some error happened

type of messages...

-- 
Dmitry
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help