On Tue, May 22, 2012 at 06:20:10PM -0700, H Hartley Sweeten wrote:
> The 'thisboard' macro depends on having a local variable with
> a magic name. The CodingStyle document suggests not doing this
> to avoid confusion. Remove the macro and use the comedi_board()
> inline helper to get the dev->board
On Tue, May 22, 2012 at 10:55:12PM -0400, David Miller wrote:
> From: Anton Vorontsov
> Date: Tue, 22 May 2012 19:35:16 -0700
>
> > For scripting it is important to have a consistent header that tells
> > where the kernel log starts. At least to me it always seemed that
> > linux_banner served th
From: Anton Vorontsov
Date: Tue, 22 May 2012 19:35:16 -0700
> For scripting it is important to have a consistent header that tells
> where the kernel log starts. At least to me it always seemed that
> linux_banner served this purpose.
Your change will not achieve this goal, many architectures
pr
On Tue, May 22, 2012 at 7:35 PM, Anton Vorontsov
wrote:
> @@ -749,6 +749,9 @@ asmlinkage int printk(const char *fmt, ...)
> va_list args;
> int r;
>
> + /* Make sure linux_banner is kernel's first message. */
> + printk_once(KERN_NOTICE "%s", linux_banner);
> +
Ugh. No.
For scripting it is important to have a consistent header that tells
where the kernel log starts. At least to me it always seemed that
linux_banner served this purpose.
Though, an early kernel code may print things before the Linux banner.
When we parse logs from multiple boots grabbed from serial
The 'thisboard' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Mo
The 'thisboard' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Mo
The 'thisboard' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Mo
The 'this_board' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: M
The 'this_board' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: M
The 'thisboard' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Mo
The 'thisboard' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Mo
The 'thisboard' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Mo
The 'this_board' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: M
The 'this_board' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: M
The 'this_board' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: M
The 'this_board' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: M
The 'this_board' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: M
The 'this_board' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: M
The 'this_board' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: M
The 'this_board' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: M
The 'this_board' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: M
The 'boardtype' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Mo
The 'thisboard' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Mo
The 'this_board' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: M
The 'this_board' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: M
The 'thisboard' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Mo
The 'thisboard' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Mo
The 'thisboard' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Mo
The 'thisboard' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Mo
The 'thisboard' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Mo
The 'thisboard' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Mo
The 'thisboard' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Mo
The 'this_board' macro depends on having a local variable with
a magic name. The CodingStyle document suggests not doing this
to avoid confusion. Remove the macro and use the comedi_board()
inline helper to get the dev->board_ptr information.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: M
On Tue, May 22, 2012 at 12:04 PM, Greg Kroah-Hartman
wrote:
> On Tue, May 22, 2012 at 11:33:33AM -0700, Kees Cook wrote:
>> On Tue, May 22, 2012 at 11:19 AM, Greg Kroah-Hartman
>> wrote:
>> > On Tue, May 22, 2012 at 07:17:17AM -0700, Anton Vorontsov wrote:
>> >> Hi all,
>> >>
>> >> A brand new v4
On Tue, May 22, 2012 at 11:33:33AM -0700, Kees Cook wrote:
> On Tue, May 22, 2012 at 11:19 AM, Greg Kroah-Hartman
> wrote:
> > On Tue, May 22, 2012 at 07:17:17AM -0700, Anton Vorontsov wrote:
> >> Hi all,
> >>
> >> A brand new v4:
> >>
> >> - Per Kees Cook's comments, the patches no longer remove
On Tue, May 22, 2012 at 11:19 AM, Greg Kroah-Hartman
wrote:
> On Tue, May 22, 2012 at 07:17:17AM -0700, Anton Vorontsov wrote:
>> Hi all,
>>
>> A brand new v4:
>>
>> - Per Kees Cook's comments, the patches no longer remove an automatic
>> updates feature, but instead make the it configurable; pl
On Tue, May 22, 2012 at 8:30 AM, Dan Carpenter wrote:
> On Tue, May 22, 2012 at 08:02:43AM -0400, Kevin McKinney wrote:
>> On Tue, May 22, 2012 at 5:03 AM, Dan Carpenter
>> wrote:
>> > On Tue, May 22, 2012 at 12:06:20AM -0400, Kevin McKinney wrote:
>> >> This patch removes typedef for _TARGET_PA
On Tue, May 22, 2012 at 07:17:17AM -0700, Anton Vorontsov wrote:
> Hi all,
>
> A brand new v4:
>
> - Per Kees Cook's comments, the patches no longer remove an automatic
> updates feature, but instead make the it configurable; plus disable
> it by default (in a separate patch);
> - Fixed some
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> Otherwise, the files will survive just one reboot, and on a subsequent
> boot they will disappear.
>
> Also, as noticed by Colin Cross, this also causes an interesting behavior
> change in the console logging. Before this change, the consol
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> Having automatic updates seems pointless for production system, and
> even dangerous and thus counter-productive:
>
> 1. If we can mount pstore, or read files, we can as well read
> /proc/kmsg. So, there's little point in duplicating the
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> There is no behavioural change, the default value is still 60 seconds.
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
___
devel mailing list
devel@linu
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> The console log size is configurable via ramoops.console_size
> module option, and the log itself is available via
> /console-ramoops file.
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> This will help make code clearer when we'll add support for other
> message types.
>
> The patch also changes return value from -EINVAL to 0 in case of
> end-of-records. The exact value doesn't matter for pstore (it should
> be just <= 0),
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> This will help make code clearer when we'll add support for other
> message types.
>
> This also makes probe() much shorter and understandable, plus
> makes mem/record size checking a bit easier.
>
> Implementation detail: we now use a padd
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> So far it is the same as max_count, but this will change when
> we'll add support for other message types (e.g. console, mce,
> tracing).
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
__
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> Otherwise, unlinked file will reappear on the next boot.
>
> Reported-by: Kees Cook
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
___
devel mailing lis
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> A handy function that we will use outside of ram_core soon. But
> so far just factor it out and start using it in post_init().
>
> Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
--
Kees Cook
Chrome OS Security
_
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> Without the update, we'll only see the new dmesg buffer after the
> reboot, but previously we could see it right away. Making an oops
> visible in pstore filesystem before reboot is a somewhat dubious
> feature, but removing it wasn't an in
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> There's no reason to extern it. The patch fixes the annoying sparse
> warning:
>
> CHECK fs/pstore/inode.c
> fs/pstore/inode.c:264:5: warning: symbol 'pstore_fill_super' was not
> declared. Should it be static?
>
> Signed-off-by: Anton Vo
Having automatic updates seems pointless for production system, and
even dangerous and thus counter-productive:
1. If we can mount pstore, or read files, we can as well read
/proc/kmsg. So, there's little point in duplicating the
functionality and present the same information but via another
There is no behavioural change, the default value is still 60 seconds.
Signed-off-by: Anton Vorontsov
---
fs/pstore/platform.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index a3f6d96..4f49bb4 100644
--- a/fs
The code tried to maintain the global list of persistent ram zones,
which isn't a great idea overall, plus since Android's ram_console
is no longer there, we can remove some unused functions.
Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
Acked-by: Colin Cross
---
fs/pstore/ram_core.c
Suggested-by: Shuah Khan
Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
Acked-by: Colin Cross
---
Documentation/ramoops.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
index 4ba7db2..59a74a8 100644
--- a/Docume
All the functionality is now supported by pstore and pstore_ram drivers.
Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
Acked-by: Colin Cross
---
drivers/staging/android/Kconfig |5 -
drivers/staging/android/Makefile |1 -
drivers/staging/android/ram_console.c | 179 ---
Since we use multiple regions, the messages are somewhat annoying.
We do print total mapped memory already, so no need to print the
information for each region in the library routines.
Signed-off-by: Anton Vorontsov
Acked-by: Kees Cook
Acked-by: Colin Cross
---
fs/pstore/ram_core.c |4 ++--
This will help make code clearer when we'll add support for other
message types.
The patch also changes return value from -EINVAL to 0 in case of
end-of-records. The exact value doesn't matter for pstore (it should
be just <= 0), but 0 feels more correct.
Signed-off-by: Anton Vorontsov
---
fs/p
This will help make code clearer when we'll add support for other
message types.
This also makes probe() much shorter and understandable, plus
makes mem/record size checking a bit easier.
Implementation detail: we now use a paddr pointer, this will
be used for allocating persistent ram zones for
The console log size is configurable via ramoops.console_size
module option, and the log itself is available via
/console-ramoops file.
Signed-off-by: Anton Vorontsov
---
fs/pstore/ram.c| 107 ++--
include/linux/pstore_ram.h |1 +
2 files
So far it is the same as max_count, but this will change when
we'll add support for other message types (e.g. console, mce,
tracing).
Signed-off-by: Anton Vorontsov
---
fs/pstore/ram.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/fs/pstore/ram.c b/fs/psto
Pstore doesn't support logging kernel messages in run-time, it only
dumps dmesg when kernel oopses/panics. This makes pstore useless for
debugging hangs caused by HW issues or improper use of HW (e.g.
weird device inserted -> driver tried to write a reserved bits ->
SoC hanged. In that case we don'
Otherwise, unlinked file will reappear on the next boot.
Reported-by: Kees Cook
Signed-off-by: Anton Vorontsov
---
fs/pstore/ram.c |1 +
1 file changed, 1 insertion(+)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 16ff733..453030f 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@
A handy function that we will use outside of ram_core soon. But
so far just factor it out and start using it in post_init().
Signed-off-by: Anton Vorontsov
---
fs/pstore/ram_core.c | 11 ---
include/linux/pstore_ram.h |1 +
2 files changed, 9 insertions(+), 3 deletions(-)
di
Otherwise, the files will survive just one reboot, and on a subsequent
boot they will disappear.
Also, as noticed by Colin Cross, this also causes an interesting behavior
change in the console logging. Before this change, the console log would
show only the messages from the last reboot. After th
Without the update, we'll only see the new dmesg buffer after the
reboot, but previously we could see it right away. Making an oops
visible in pstore filesystem before reboot is a somewhat dubious
feature, but removing it wasn't an intentional change, so let's
restore it.
For this we have to make
There's no reason to extern it. The patch fixes the annoying sparse
warning:
CHECK fs/pstore/inode.c
fs/pstore/inode.c:264:5: warning: symbol 'pstore_fill_super' was not
declared. Should it be static?
Signed-off-by: Anton Vorontsov
---
fs/pstore/inode.c |2 +-
1 file changed, 1 insertion(
Hi all,
A brand new v4:
- Per Kees Cook's comments, the patches no longer remove an automatic
updates feature, but instead make the it configurable; plus disable
it by default (in a separate patch);
- Fixed some bugs noticed by Colin Cross;
- Documented new continuous ramoops-console log beha
On Fri, May 18, 2012 at 04:42:03PM -0700, Colin Cross wrote:
[...]
> This causes an interesting behavior change in the console logging.
> Before this change, the console log would show only the messages from
> the last reboot. After this change, the console log will have logs
> from multiple boots
On Tue, May 22, 2012 at 08:08:46AM -0400, Kevin McKinney wrote:
> On Tue, May 22, 2012 at 5:17 AM, Dan Carpenter
> wrote:
> > On Tue, May 22, 2012 at 12:06:26AM -0400, Kevin McKinney wrote:
> >> This patch removes typedef for _U_IP_ADDRESS,
> >> changes the name of the union from _U_IP_ADDRESS
>
On Tue, May 22, 2012 at 08:02:43AM -0400, Kevin McKinney wrote:
> On Tue, May 22, 2012 at 5:03 AM, Dan Carpenter
> wrote:
> > On Tue, May 22, 2012 at 12:06:20AM -0400, Kevin McKinney wrote:
> >> This patch removes typedef for _TARGET_PARAMS,
> >> changes the name of the struct from
> >> _TARGET_P
On Tue, May 22, 2012 at 5:17 AM, Dan Carpenter wrote:
> On Tue, May 22, 2012 at 12:06:26AM -0400, Kevin McKinney wrote:
>> This patch removes typedef for _U_IP_ADDRESS,
>> changes the name of the union from _U_IP_ADDRESS
>> to bcm_ip_address, and converts the union to a
>> struct. In addition, any
On Tue, May 22, 2012 at 5:03 AM, Dan Carpenter wrote:
> On Tue, May 22, 2012 at 12:06:20AM -0400, Kevin McKinney wrote:
>> This patch removes typedef for _TARGET_PARAMS,
>> changes the name of the struct from
>> _TARGET_PARAMS to bcm_target_params. In addition,
>> remove typedefs: STARGETPARAMS, *
On 2012-05-22 09:11, Dan Carpenter wrote:
On Mon, May 21, 2012 at 06:10:07PM -0700, H Hartley Sweeten wrote:
@@ -210,7 +210,7 @@ static int pci20xxx_attach(struct comedi_device *dev,
if (ret< 0)
return ret;
- devpriv->ioaddr = (void *)(unsigned long)it->options[0]
On 2012-05-22 01:12, H Hartley Sweeten wrote:
Remove the private header, comedi_pci.h, by moving the two
helper functions into divers.c and providing the prototypes
in comedidev.h.
This allows the comedi_pci_enable/disable helper functions
to be shared instead of having an inline version in ever
On Tue, May 22, 2012 at 12:06:26AM -0400, Kevin McKinney wrote:
> This patch removes typedef for _U_IP_ADDRESS,
> changes the name of the union from _U_IP_ADDRESS
> to bcm_ip_address, and converts the union to a
> struct. In addition, any calls to the following
> typedef "U_IP_ADDRESS" are changed
On Tue, May 22, 2012 at 12:06:20AM -0400, Kevin McKinney wrote:
> This patch removes typedef for _TARGET_PARAMS,
> changes the name of the struct from
> _TARGET_PARAMS to bcm_target_params. In addition,
> remove typedefs: STARGETPARAMS, *PSTARGETPARAMS.
>
> Signed-off-by: Kevin McKinney
> ---
>
On Mon, May 21, 2012 at 06:10:07PM -0700, H Hartley Sweeten wrote:
> @@ -210,7 +210,7 @@ static int pci20xxx_attach(struct comedi_device *dev,
> if (ret < 0)
> return ret;
>
> - devpriv->ioaddr = (void *)(unsigned long)it->options[0];
> + devpriv->ioaddr = (void __iome
77 matches
Mail list logo
