Re: [RFC] persistent store (version 2) (part 1 of 2)

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Andrew Morton
Date: Wednesday, December 1, 2010 - 5:51 pm

On Tue, 30 Nov 2010 16:20:50 -0800
"Luck, Tony" <tony.luck@intel.com> wrote:


I haven't really thought about the overall concept, but I saw stuff to
nitpick at.



It'd be nice to know what pstore_lock actually locks.


It locks psinfo (at least), so I'd suggest that all things which
pstore_lock locks be collected immediately after its definition.


bah, ia64 coding style leaking into core kernel.


It doesn't seem appropriate to check this here.  It's a programming
error!  Just install the thing and let the kernel oops - the programmer
will notice.


Here the state of the driver gets screwed up.  We've installed the
psinfo and we're unable to install a new one, but the one which we
installed is only partially constructed.  And it will cause oopses if
we actually try to use it.


So I'd suggest that this function *fully* back out if anything fails. 
That means restoring psinfo.  And fixing the error-path memory leaks
which might be there (I didn't check too hard).

Bonus points for implementing it with only one `return' statement ;)


Since when are "records" identified by "filenames"?

filenames refer to files!  And lo, that's what we have here.  A
filesystem!  The files are created by the kernel and are read and
unlinked by userspace.

So why not implement this whole thing as a proper filesystem?


hm, what's going on here.

Can that line really have a trailing \n?

Part of this code assumes that we're using null-terminated strings but
other parts don't do it that way.

All seems a bit confusing and messed up.  Might be improved via
appropriate use of strim() and sysfs_streq().  Would definitely be
improved via a comment explaining what's going on here!


I just discovered something else which pstore_lock locks.


A single return site per function is better.  Multiple-returns often
lead to locking errors and memory leaks as the code evolves.


Wait.  It *is* a filesystem.

<looks back at the changelog>

Nope, that was secret info.

So why can't I remove these "records" with rm?


write() takes a size_t.

--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC] persistent store (version 2) (part 1 of 2), Luck, Tony, (Tue Nov 30, 5:20 pm)
Re: [RFC] persistent store (version 2) (part 1 of 2), Andrew Morton, (Wed Dec 1, 5:51 pm)
RE: [RFC] persistent store (version 2) (part 1 of 2), Luck, Tony, (Wed Dec 1, 11:00 pm)
Re: [RFC] persistent store (version 2) (part 1 of 2), Andrew Morton, (Thu Dec 2, 3:12 am)