lkml.org 
[lkml]   [2004]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: [patch] kernel events layer
Date
From
> From: Robert Love [mailto:rml@ximian.com]
>
> > methinks: if the message is related to some object that has a kobject
> > representation, use it. If not, come up with one on a case by case
> > basis [now this is the difficult one--is where it'd be difficult to
> > keep things on leash].
>
> That introduces two orthogonal name spaces, and that really doesn't cut
> it.
>
> If Greg can come up with a solution for using kobjects, I am all for
> that - that would be great - but I really do not see kobject paths
> working out. I think the best we have is the file path in the tree.

Agreed -- I guess what I am looking for is a regular way to link the
instance of the object (if any) that caused the message, so it is easier
to take action.

For a silly example, IDE, I want to know which hard drive had a read
error; knowing that it came from drivers/ide/ide-disk.c is useful, but
quite limited; it doesn't tell me which drive I need to babysit and
maybe swap. Certainly the message can print that information as part of
the text, but chances up we'll end up with something like printk again
if following that path.

Ok, I did my share of non-very-constructive criticism already--shutting up :)

Thx,

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.099 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site