On Mon, 23 Jul 2007 14:19:12 -0400
Robin Getz <[EMAIL PROTECTED]> wrote:
> On Sun 22 Jul 2007 19:50, Mike Frysinger pondered:
> >
> > i think the attached two functions account for what Robin and Andrew
> > were thinking ...
>
> A note about why/when grab_lock would be set to zero (pre-kernel init, or
> OOPs) might be nice.
Definitely.
The pre-kernel init shouldn't be an issue: logbuf_lock is initialised at
compile time.
At oops time we could possibly use oops_in_progress to work out whether to
avoid taking the lock. That's not terribly nice, but nor is it nice for
callers to know about printk internals.
> Or - remove it - and tell people they should be using do_syslog interface in
> a "normal" kernel environment (where log_end or log_start can be updated).
You can't (or al least, shouldn't) use do_syslog() from within kernel code?
> Either would be fine with me. Andrew?
The interface is pretty bad, IMO:
/*
+ * Read the log buffer into the supplied buffer. The len option
+ * tells whether to copy from the beginning (> 0), the end (< 0), or
+ * just query the number of existing chars. The number of bytes
+ * actually copied is returned.
+ */
+int log_buf_read(int len, char *buf, int grab_lock)
The magical interpretation of len isn't very nice. This code would be
simpler if it did not attempt to read more than one char at a time. It
will be plenty fast enough.
If the caller knows the length of the buffer, why is there any need for the
index-from-the-end function?
I think a sufficient implementation is
int log_buf_len(void);
and
int log_buf_read(int index);
which will return the character at `index', or -1 if `index' is out of
bounds.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
