[evlog-dev] Re: New problem logging macros, Alan and Linus responses

[Larry K. <ke...@us...>]

Both Alan and Linus have responded to a direct inquiry I sent to Alan.
I stopped copying the evlog mailing list, etc. to avoid subjecting them
to annoying bounces of their "reply all" responses.

I've drawn some conclusions from this, but I'll let you draw your own.

Thanks,
Larry

-------------------------

Alan Cox wrote:
>
> A lot of it can be tidied up by very very few changes that can be done
> over time and make the job easier. Why not just start with
>
>         dev_printk(dev, KERN_ERR "Exploded mysteriously");
>
> and a few notification type things people can add eg
>
>         dev_failed(dev);
>         dev_offline(dev);
>
> much like we keep network status. That lets driverfs tell the decision
> making code in hotplug scripts the state of play and lets it figure out
> how to reassign resources, paper over cracks, phone the engineer.

Alan-
At the risk of reading more into your suggestion than you intended...
Are you supportive of adding infrastructure into the kernel that
provides, conceptually at least, the sort of things that Rusty and
I (and others) are after ?

Specifically...

Provide a reasonable and printk-like interface (like you've
shown above), that writes to printk if advanced logging is not
configured; but, if advanced logging is configured...

1)During the build process, static event details (strings,
  format specifiers, file and function name, line no)
  are stored in a .log section in .o files, so that a user-mode
  utility can extract-it into user-space templates.
2)During runtime, the printk-like interface writes the dynamic data
  into an in-kernel buffer (NOT the printk ring buffer), and a
  user-space daemon reads the event and writes to a logfile.
3)Advanced logging utilities apply the templates from step (1)
  when events are read from the logfile for querying and displaying
  events, event notification, and log management. Templates can be
  modified to control how data is displayed (in what language, for
  example).

Mindful  that....

1) It will take time for device drivers to migrate to a new interface
2) It will take time for exploitation of the template approach
3) we should avoid modifying current printk behavior
4) advanced logging must be an optional feature to avoid the overhead
   where its not wanted or needed
5) User-space utilities already exist (evlog.sourceforge.net)

and of course, mindful that the 2.5 window is closing in 1 month.

Thanks,
Larry Kessler

-----------------

Larry Kessler wrote:
> and of course, mindful that the 2.5 window is closing in 1 month.


no need to be mindful of that.

Let's get it right, rather than rush it...

     Jeff

-----------------

On Thu, 26 Sep 2002, Jeff Garzik wrote:
>
> no need to be mindful of that.
>
> Let's get it right, rather than rush it...

Which imples that it's 2.7 material.

For 2.6.x I care about getting the drivers _working_.

The whole logging discussion with hardened drivers etc is _not_ adding
value to normal people until much much later, and it sound very much to me
like one of those patch sets that some vendors will care about deeply
because they have some big company that cares and pays them.

Those kinds of patch-sets sometimes never make it into the standard
kernel. They have to prove their worth to real people first, and I could
care less (but not much) about paperwork reasons.

                Linus

------------------

On Thu, 2002-09-26 at 23:55, Larry Kessler wrote:
> At the risk of reading more into your suggestion than you intended...
> Are you supportive of adding infrastructure into the kernel that
> provides, conceptually at least, the sort of things that Rusty and
> I (and others) are after ?

Sort of. We have a problem about consistently reporting which device. So
dev_printk(dev, ...) is printk that formats up the device info for you.
Its also easy to use and happens to pass a device pointer into the
places you want it for more detailed logging

> Provide a reasonable and printk-like interface (like you've
> shown above), that writes to printk if advanced logging is not
> configured; but, if advanced logging is configured...

I'm trying to make sure the right data is available. I don't *care* what
you do with it after it gets thrown at you. If I have to care what you
are doing with the data the interface is wrong.


> 1) It will take time for device drivers to migrate to a new interface

Who cares. Migrate the devices you care about one at a time, test them
and worry about just those. Do you need 120 highly available network
card drivers. Do you need telco grade soundblaster 16 ?

> 3) we should avoid modifying current printk behavior

We don't. We add an extra helper that builds on it in a totally logical
fashion. The existing one doesnt break, its merely something to be
polished when needed by the folks who care

> 4) advanced logging must be an optional feature to avoid the overhead
>    where its not wanted or needed

And dev_printk is going to be under 1K. What you do with the data isnt
my problem.


> 5) User-space utilities already exist (evlog.sourceforge.net)

Again, this is about what you do with the data for your cases.
dev_printk is about making the info available cleanly

> and of course, mindful that the 2.5 window is closing in 1 month.

For core code changes for 2.6 base Linus tree. So you end up with a set
of patches you add over time. I would note however that the default
dev_printk() routine that just reformats up as

<level>%s: message

is not exactly taxing to get into 2.5 before October 31st, being about
10 lines long. That gives you the infrastructure to know what is going
on. Similarly I don't think its infeasible to get the state interface
into the base kernel just flipping flags in the device structure.

That makes it easy to add the needed pieces to base kernel code during
the driver work after Oct 31st, but without having to import all the
event logging stuff which wants hammering out over a longer period of
time

     Alan