[PATCH] nvram buffering/error logging port to 2.6

[Jake Moilanen]

Here is an updated version of the patch changes from Paul's comments.

> Mostly looks fine. A few comments:
>
> * Please add a comment somewhere explaining why it is necessary
>   to have the kernel write the error log to nvram, i.e. what the
>   circumstances are under which Bad Things would happen if we relied
>   on userspace to do it (and what those Bad Things are).

Done in nvram_write_error_log()'s comments.

> * We are going to have to separate the general /dev/nvram support
>   from the methods for reading/writing nvram via RTAS, because the
>   G5 powermacs have nvram but don't use RTAS. This is not directly a
>   criticism of the patch, but if you felt like reworking it to make
>   this separation (and maybe put function pointers for nvram_read /
>   nvram_write into ppc_md) that would be great.

I did this abstraction.

> * With the kernel parsing the partitions in the nvram, I wonder if we
>   should be exporting that information to userspace somehow?

The nvram partition table is printed during boot right now.  There is
also the ppc64-util command 'nvram' that can be used to read the
partition table.

> * In future, as a way of reducing the bulk of the code, could we
>   consider having userspace do the repartitioning to create the
>   ppc64,linux partition instead of the kernel? That is, could we have
>   rtasd (or something similar) create the partition ahead of time so
>   that the kernel would only have to read the partitioning? Or is
>   there some scenario where this would be impossible?

I think this is a good idea.  This is something that I've considered
doing.  There are a number of components coming down the line that will
be using NVRAM and some of them may have restrictions.

> * The nvram_read and nvram_write routines could be rewritten to be a
>   bit shorter and neater. In particular we should be able to do it
>   with just one loop containing the rtas_call call, rather than an if
>   and a loop each with a call to rtas_call. And we shouldn't need to
>   do a mod operation. Like this:
<snip>

I like your method much more, I've made this change.

Thanks,
Jake
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux-2.6-nvram-errlog-3.patch.bz2
Type: application/x-bzip
Size: 12352 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031118/56ceaab6/attachment.bin