Searched hist:"3 d541c4b7f6efd55a98189afd1b2f1c9d048c1b3" (Results 1 – 5 of 5) sorted by relevance
| /linux/arch/powerpc/platforms/chrp/ |
| H A D | Kconfig | diff 3d541c4b7f6efd55a98189afd1b2f1c9d048c1b3 Thu Sep 24 21:30:05 CEST 2009 Benjamin Herrenschmidt <benh@kernel.crashing.org> powerpc/chrp: Use the same RTAS daemon as pSeries
The CHRP code has some fishy timer based code to scan the RTAS event
log, which uses a 1KB stack buffer and doesn't even use the results.
The pSeries code as a nicer daemon that allows userspace to read the
event log and basically uses the same RTAS interface
This patch moves rtasd.c out of platform/pseries and makes it usable
by CHRP, after removing the old crufty event log mechanism in there.
The nvram logging part of the daemon is still only available on 64-bit
since the underlying nvram management routines aren't currently shared.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
| H A D | setup.c | diff 3d541c4b7f6efd55a98189afd1b2f1c9d048c1b3 Thu Sep 24 21:30:05 CEST 2009 Benjamin Herrenschmidt <benh@kernel.crashing.org> powerpc/chrp: Use the same RTAS daemon as pSeries
The CHRP code has some fishy timer based code to scan the RTAS event
log, which uses a 1KB stack buffer and doesn't even use the results.
The pSeries code as a nicer daemon that allows userspace to read the
event log and basically uses the same RTAS interface
This patch moves rtasd.c out of platform/pseries and makes it usable
by CHRP, after removing the old crufty event log mechanism in there.
The nvram logging part of the daemon is still only available on 64-bit
since the underlying nvram management routines aren't currently shared.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
| /linux/arch/powerpc/kernel/ |
| H A D | rtasd.c | 3d541c4b7f6efd55a98189afd1b2f1c9d048c1b3 Thu Sep 24 21:30:05 CEST 2009 Benjamin Herrenschmidt <benh@kernel.crashing.org> powerpc/chrp: Use the same RTAS daemon as pSeries
The CHRP code has some fishy timer based code to scan the RTAS event
log, which uses a 1KB stack buffer and doesn't even use the results.
The pSeries code as a nicer daemon that allows userspace to read the
event log and basically uses the same RTAS interface
This patch moves rtasd.c out of platform/pseries and makes it usable
by CHRP, after removing the old crufty event log mechanism in there.
The nvram logging part of the daemon is still only available on 64-bit
since the underlying nvram management routines aren't currently shared.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
| H A D | Makefile | diff 3d541c4b7f6efd55a98189afd1b2f1c9d048c1b3 Thu Sep 24 21:30:05 CEST 2009 Benjamin Herrenschmidt <benh@kernel.crashing.org> powerpc/chrp: Use the same RTAS daemon as pSeries
The CHRP code has some fishy timer based code to scan the RTAS event
log, which uses a 1KB stack buffer and doesn't even use the results.
The pSeries code as a nicer daemon that allows userspace to read the
event log and basically uses the same RTAS interface
This patch moves rtasd.c out of platform/pseries and makes it usable
by CHRP, after removing the old crufty event log mechanism in there.
The nvram logging part of the daemon is still only available on 64-bit
since the underlying nvram management routines aren't currently shared.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
| /linux/arch/powerpc/platforms/pseries/ |
| H A D | Makefile | diff 3d541c4b7f6efd55a98189afd1b2f1c9d048c1b3 Thu Sep 24 21:30:05 CEST 2009 Benjamin Herrenschmidt <benh@kernel.crashing.org> powerpc/chrp: Use the same RTAS daemon as pSeries
The CHRP code has some fishy timer based code to scan the RTAS event
log, which uses a 1KB stack buffer and doesn't even use the results.
The pSeries code as a nicer daemon that allows userspace to read the
event log and basically uses the same RTAS interface
This patch moves rtasd.c out of platform/pseries and makes it usable
by CHRP, after removing the old crufty event log mechanism in there.
The nvram logging part of the daemon is still only available on 64-bit
since the underlying nvram management routines aren't currently shared.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|