Re: Early printk behaviour
Robin Getz wrote:
>> Hmm, yes, should be doable in generic code. Check whenever the current
>> console has CON_BOOT set and if so unregister it.
>
> Something like:
>
> +++ kernel/printk.c (working copy)
> +int __init disable_boot_consoles(void)
> +{
> + struct console *con;
> +
> + for (con = console_drivers; con; con = con->next) {
> + if (con->flags & CON_BOOT) {
> + printk(KERN_INFO "Unregister BootConsole %s%d\n",
> + con->name, con->index);
> + unregister_console(con);
> + }
> + }
> + return 0;
> +}
> +late_initcall(disable_boot_consoles);
Yep, that should work. You can drop the loop though. You can't
register a boot console if another console exists, and the first
non-boot console replaces the boot console, thus you never ever have
more than one console in case the boot console is still active.
The printk should be all lowercase like the other printk's in the file.
Other than that it loosk fine.
cheers,
Gerd
-
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/
Re: Early printk behaviour
Robin Getz wrote:
Hmm, yes, should be doable in generic code. Check whenever the current
console has CON_BOOT set and if so unregister it.
Something like:
+++ kernel/printk.c (working copy)
+int __init disable_boot_consoles(void)
+{
+ struct console *con;
+
+ for (con = console_drivers; con; con = con-next) {
+ if (con-flags CON_BOOT) {
+ printk(KERN_INFO Unregister BootConsole %s%d\n,
+ con-name, con-index);
+ unregister_console(con);
+ }
+ }
+ return 0;
+}
+late_initcall(disable_boot_consoles);
Yep, that should work. You can drop the loop though. You can't
register a boot console if another console exists, and the first
non-boot console replaces the boot console, thus you never ever have
more than one console in case the boot console is still active.
The printk should be all lowercase like the other printk's in the file.
Other than that it loosk fine.
cheers,
Gerd
-
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/
Re: Early printk behaviour
On Fri 17 Aug 2007 17:09, Mike Frysinger pondered:
> On 8/17/07, Robin Getz <[EMAIL PROTECTED]> wrote:
> >
> > Something like:
> >
> > Index: kernel/printk.c
> > ===
> > --- kernel/printk.c (revision 3568)
> > +++ kernel/printk.c (working copy)
> > @@ -1104,6 +1104,22 @@
> > }
> > EXPORT_SYMBOL(unregister_console);
> >
> > +int __init disable_boot_consoles(void)
> > +{
> > + struct console *con;
> > +
> > + for (con = console_drivers; con; con = con->next) {
> > + if (con->flags & CON_BOOT) {
> > + printk(KERN_INFO "Unregister BootConsole %s%d\n",
> > + con->name, con->index);
> > + unregister_console(con);
> > + }
> > + }
> > + return 0;
> > +}
> > +late_initcall(disable_boot_consoles);
>
> is there any need for a return value then ?
> void __init disable_boot_consoles(void);
So, we don't get compiler warnings?
Otherwise:
kernel/printk.c:1119: warning: initialization from incompatible pointer type
> and if we dont think anyone else wants to call it ...
> static void __init disable_boot_consoles(void);
So I think static is Ok, but it needs to be int - that is the proper prototype
-Robin
-
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/
Re: Early printk behaviour
On 8/17/07, Robin Getz <[EMAIL PROTECTED]> wrote:
> On Fri 17 Aug 2007 03:49, Gerd Hoffmann pondered:
> > Mike Frysinger wrote:
> > >> Hmm, sort of, although I didn't think about the case of no real console
> > >> replacing the early console. The intention of the patch is to have a
> > >> smooth handover from the boot console to the real console. And, yes, if
> > >> no real console is ever registered the boot console keeps running ...
> > >
> > > i think it also occurs in the case where real console != early console
> >
> > No. At least not of the boot console has the CON_BOOT flag set as it
> > should. Last message you'll see on the boot console is the handover
> > printk, telling you which real console device prints the following
> > messages. Whenever early and real console go to the physical device or
> > not doesn't matter.
> >
> > >> So you can either let it running and *not* mark it __init, so it can
> > >> keep on going without breaking. Or you can explicitly unregister your
> > >> boot console at some point, maybe using a late_initcall.
> > >
> > > wouldnt a common kernel late_initcall() be more appropriate ? if
> > > early console hasnt switched over (for whatever reason), then kill it
> >
> > Hmm, yes, should be doable in generic code. Check whenever the current
> > console has CON_BOOT set and if so unregister it.
>
> Something like:
>
> Index: kernel/printk.c
> ===
> --- kernel/printk.c (revision 3568)
> +++ kernel/printk.c (working copy)
> @@ -1104,6 +1104,22 @@
> }
> EXPORT_SYMBOL(unregister_console);
>
> +int __init disable_boot_consoles(void)
> +{
> + struct console *con;
> +
> + for (con = console_drivers; con; con = con->next) {
> + if (con->flags & CON_BOOT) {
> + printk(KERN_INFO "Unregister BootConsole %s%d\n",
> + con->name, con->index);
> + unregister_console(con);
> + }
> + }
> + return 0;
> +}
> +late_initcall(disable_boot_consoles);
is there any need for a return value then ?
void __init disable_boot_consoles(void);
and if we dont think anyone else wants to call it ...
static void __init disable_boot_consoles(void);
-mike
-
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/
Re: Early printk behaviour
On Fri 17 Aug 2007 03:49, Gerd Hoffmann pondered:
> Mike Frysinger wrote:
> >> Hmm, sort of, although I didn't think about the case of no real console
> >> replacing the early console. The intention of the patch is to have a
> >> smooth handover from the boot console to the real console. And, yes, if
> >> no real console is ever registered the boot console keeps running ...
> >
> > i think it also occurs in the case where real console != early console
>
> No. At least not of the boot console has the CON_BOOT flag set as it
> should. Last message you'll see on the boot console is the handover
> printk, telling you which real console device prints the following
> messages. Whenever early and real console go to the physical device or
> not doesn't matter.
>
> >> So you can either let it running and *not* mark it __init, so it can
> >> keep on going without breaking. Or you can explicitly unregister your
> >> boot console at some point, maybe using a late_initcall.
> >
> > wouldnt a common kernel late_initcall() be more appropriate ? if
> > early console hasnt switched over (for whatever reason), then kill it
>
> Hmm, yes, should be doable in generic code. Check whenever the current
> console has CON_BOOT set and if so unregister it.
Something like:
Index: kernel/printk.c
===
--- kernel/printk.c (revision 3568)
+++ kernel/printk.c (working copy)
@@ -1104,6 +1104,22 @@
}
EXPORT_SYMBOL(unregister_console);
+int __init disable_boot_consoles(void)
+{
+ struct console *con;
+
+ for (con = console_drivers; con; con = con->next) {
+ if (con->flags & CON_BOOT) {
+ printk(KERN_INFO "Unregister BootConsole %s%d\n",
+ con->name, con->index);
+ unregister_console(con);
+ }
+ }
+ return 0;
+}
+late_initcall(disable_boot_consoles);
+
+
/**
* tty_write_message - write a message to a certain tty, not just the console.
* @tty: the destination tty_struct
-
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/
Re: Early printk behaviour
Mike Frysinger wrote: >> Hmm, sort of, although I didn't think about the case of no real console >> replacing the early console. The intention of the patch is to have a >> smooth handover from the boot console to the real console. And, yes, if >> no real console is ever registered the boot console keeps running ... > > i think it also occurs in the case where real console != early console No. At least not of the boot console has the CON_BOOT flag set as it should. Last message you'll see on the boot console is the handover printk, telling you which real console device prints the following messages. Whenever early and real console go to the physical device or not doesn't matter. >> So you can either let it running and *not* mark it __init, so it can >> keep on going without breaking. Or you can explicitly unregister your >> boot console at some point, maybe using a late_initcall. > > wouldnt a common kernel late_initcall() be more appropriate ? if > early console hasnt switched over (for whatever reason), then kill it Hmm, yes, should be doable in generic code. Check whenever the current console has CON_BOOT set and if so unregister it. cheers, Gerd - 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/
Re: Early printk behaviour
Mike Frysinger wrote: Hmm, sort of, although I didn't think about the case of no real console replacing the early console. The intention of the patch is to have a smooth handover from the boot console to the real console. And, yes, if no real console is ever registered the boot console keeps running ... i think it also occurs in the case where real console != early console No. At least not of the boot console has the CON_BOOT flag set as it should. Last message you'll see on the boot console is the handover printk, telling you which real console device prints the following messages. Whenever early and real console go to the physical device or not doesn't matter. So you can either let it running and *not* mark it __init, so it can keep on going without breaking. Or you can explicitly unregister your boot console at some point, maybe using a late_initcall. wouldnt a common kernel late_initcall() be more appropriate ? if early console hasnt switched over (for whatever reason), then kill it Hmm, yes, should be doable in generic code. Check whenever the current console has CON_BOOT set and if so unregister it. cheers, Gerd - 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/
Re: Early printk behaviour
On Fri 17 Aug 2007 03:49, Gerd Hoffmann pondered:
Mike Frysinger wrote:
Hmm, sort of, although I didn't think about the case of no real console
replacing the early console. The intention of the patch is to have a
smooth handover from the boot console to the real console. And, yes, if
no real console is ever registered the boot console keeps running ...
i think it also occurs in the case where real console != early console
No. At least not of the boot console has the CON_BOOT flag set as it
should. Last message you'll see on the boot console is the handover
printk, telling you which real console device prints the following
messages. Whenever early and real console go to the physical device or
not doesn't matter.
So you can either let it running and *not* mark it __init, so it can
keep on going without breaking. Or you can explicitly unregister your
boot console at some point, maybe using a late_initcall.
wouldnt a common kernel late_initcall() be more appropriate ? if
early console hasnt switched over (for whatever reason), then kill it
Hmm, yes, should be doable in generic code. Check whenever the current
console has CON_BOOT set and if so unregister it.
Something like:
Index: kernel/printk.c
===
--- kernel/printk.c (revision 3568)
+++ kernel/printk.c (working copy)
@@ -1104,6 +1104,22 @@
}
EXPORT_SYMBOL(unregister_console);
+int __init disable_boot_consoles(void)
+{
+ struct console *con;
+
+ for (con = console_drivers; con; con = con-next) {
+ if (con-flags CON_BOOT) {
+ printk(KERN_INFO Unregister BootConsole %s%d\n,
+ con-name, con-index);
+ unregister_console(con);
+ }
+ }
+ return 0;
+}
+late_initcall(disable_boot_consoles);
+
+
/**
* tty_write_message - write a message to a certain tty, not just the console.
* @tty: the destination tty_struct
-
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/
Re: Early printk behaviour
On 8/17/07, Robin Getz [EMAIL PROTECTED] wrote:
On Fri 17 Aug 2007 03:49, Gerd Hoffmann pondered:
Mike Frysinger wrote:
Hmm, sort of, although I didn't think about the case of no real console
replacing the early console. The intention of the patch is to have a
smooth handover from the boot console to the real console. And, yes, if
no real console is ever registered the boot console keeps running ...
i think it also occurs in the case where real console != early console
No. At least not of the boot console has the CON_BOOT flag set as it
should. Last message you'll see on the boot console is the handover
printk, telling you which real console device prints the following
messages. Whenever early and real console go to the physical device or
not doesn't matter.
So you can either let it running and *not* mark it __init, so it can
keep on going without breaking. Or you can explicitly unregister your
boot console at some point, maybe using a late_initcall.
wouldnt a common kernel late_initcall() be more appropriate ? if
early console hasnt switched over (for whatever reason), then kill it
Hmm, yes, should be doable in generic code. Check whenever the current
console has CON_BOOT set and if so unregister it.
Something like:
Index: kernel/printk.c
===
--- kernel/printk.c (revision 3568)
+++ kernel/printk.c (working copy)
@@ -1104,6 +1104,22 @@
}
EXPORT_SYMBOL(unregister_console);
+int __init disable_boot_consoles(void)
+{
+ struct console *con;
+
+ for (con = console_drivers; con; con = con-next) {
+ if (con-flags CON_BOOT) {
+ printk(KERN_INFO Unregister BootConsole %s%d\n,
+ con-name, con-index);
+ unregister_console(con);
+ }
+ }
+ return 0;
+}
+late_initcall(disable_boot_consoles);
is there any need for a return value then ?
void __init disable_boot_consoles(void);
and if we dont think anyone else wants to call it ...
static void __init disable_boot_consoles(void);
-mike
-
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/
Re: Early printk behaviour
On Fri 17 Aug 2007 17:09, Mike Frysinger pondered:
On 8/17/07, Robin Getz [EMAIL PROTECTED] wrote:
Something like:
Index: kernel/printk.c
===
--- kernel/printk.c (revision 3568)
+++ kernel/printk.c (working copy)
@@ -1104,6 +1104,22 @@
}
EXPORT_SYMBOL(unregister_console);
+int __init disable_boot_consoles(void)
+{
+ struct console *con;
+
+ for (con = console_drivers; con; con = con-next) {
+ if (con-flags CON_BOOT) {
+ printk(KERN_INFO Unregister BootConsole %s%d\n,
+ con-name, con-index);
+ unregister_console(con);
+ }
+ }
+ return 0;
+}
+late_initcall(disable_boot_consoles);
is there any need for a return value then ?
void __init disable_boot_consoles(void);
So, we don't get compiler warnings?
Otherwise:
kernel/printk.c:1119: warning: initialization from incompatible pointer type
and if we dont think anyone else wants to call it ...
static void __init disable_boot_consoles(void);
So I think static is Ok, but it needs to be int - that is the proper prototype
-Robin
-
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/
Re: Early printk behaviour
On Thu 16 Aug 2007 03:45, Gerd Hoffmann pondered: > Robin Getz wrote: > > I was putting together an early printk implementation for the Blackfin, and > > was wondering what the expected behaviour was in this situation. > > > > When I set up my bootargs earlyprintk=serial,ttyBF0,57600 and have no > > console > > defined (no graphical console, no serial console). > > > > based on the patch: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511 > > > > which no longer calls disable_early_printk, the earlyprintk console never > > gets > > turned off (because nothing else ever calls register_console). I get > > everything out the early console, until the init section is released (where > > the console structure is sitting), and it starts printing out garbage. > > > > Is this expected behaviour? > > Hmm, sort of, although I didn't think about the case of no real console > replacing the early console. The intention of the patch is to have a > smooth handover from the boot console to the real console. And, yes, if > no real console is ever registered the boot console keeps running ... > > So you can either let it running and *not* mark it __init, so it can > keep on going without breaking. Or you can explicitly unregister your > boot console at some point, maybe using a late_initcall. Thanks. Doing things with late_initcall seems to work - is there any problem calling unregister_console on an already unregistered console? I looked in the code, and didn't see any nastyness. -Robin - 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/
Re: Early printk behaviour
On 8/16/07, Gerd Hoffmann <[EMAIL PROTECTED]> wrote: > Robin Getz wrote: > > I was putting together an early printk implementation for the Blackfin, and > > was wondering what the expected behaviour was in this situation. > > > > When I set up my bootargs earlyprintk=serial,ttyBF0,57600 and have no > > console > > defined (no graphical console, no serial console). > > > > based on the patch: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511 > > > > which no longer calls disable_early_printk, the earlyprintk console never > > gets > > turned off (because nothing else ever calls register_console). I get > > everything out the early console, until the init section is released (where > > the console structure is sitting), and it starts printing out garbage. > > > > Is this expected behaviour? > > Hmm, sort of, although I didn't think about the case of no real console > replacing the early console. The intention of the patch is to have a > smooth handover from the boot console to the real console. And, yes, if > no real console is ever registered the boot console keeps running ... i think it also occurs in the case where real console != early console > So you can either let it running and *not* mark it __init, so it can > keep on going without breaking. Or you can explicitly unregister your > boot console at some point, maybe using a late_initcall. wouldnt a common kernel late_initcall() be more appropriate ? if early console hasnt switched over (for whatever reason), then kill it ... -mike - 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/
Re: Early printk behaviour
Robin Getz wrote: > I was putting together an early printk implementation for the Blackfin, and > was wondering what the expected behaviour was in this situation. > > When I set up my bootargs earlyprintk=serial,ttyBF0,57600 and have no console > defined (no graphical console, no serial console). > > based on the patch: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511 > > which no longer calls disable_early_printk, the earlyprintk console never > gets > turned off (because nothing else ever calls register_console). I get > everything out the early console, until the init section is released (where > the console structure is sitting), and it starts printing out garbage. > > Is this expected behaviour? Hmm, sort of, although I didn't think about the case of no real console replacing the early console. The intention of the patch is to have a smooth handover from the boot console to the real console. And, yes, if no real console is ever registered the boot console keeps running ... So you can either let it running and *not* mark it __init, so it can keep on going without breaking. Or you can explicitly unregister your boot console at some point, maybe using a late_initcall. cheers, Gerd - 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/
Re: Early printk behaviour
Robin Getz wrote: I was putting together an early printk implementation for the Blackfin, and was wondering what the expected behaviour was in this situation. When I set up my bootargs earlyprintk=serial,ttyBF0,57600 and have no console defined (no graphical console, no serial console). based on the patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511 which no longer calls disable_early_printk, the earlyprintk console never gets turned off (because nothing else ever calls register_console). I get everything out the early console, until the init section is released (where the console structure is sitting), and it starts printing out garbage. Is this expected behaviour? Hmm, sort of, although I didn't think about the case of no real console replacing the early console. The intention of the patch is to have a smooth handover from the boot console to the real console. And, yes, if no real console is ever registered the boot console keeps running ... So you can either let it running and *not* mark it __init, so it can keep on going without breaking. Or you can explicitly unregister your boot console at some point, maybe using a late_initcall. cheers, Gerd - 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/
Re: Early printk behaviour
On 8/16/07, Gerd Hoffmann [EMAIL PROTECTED] wrote: Robin Getz wrote: I was putting together an early printk implementation for the Blackfin, and was wondering what the expected behaviour was in this situation. When I set up my bootargs earlyprintk=serial,ttyBF0,57600 and have no console defined (no graphical console, no serial console). based on the patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511 which no longer calls disable_early_printk, the earlyprintk console never gets turned off (because nothing else ever calls register_console). I get everything out the early console, until the init section is released (where the console structure is sitting), and it starts printing out garbage. Is this expected behaviour? Hmm, sort of, although I didn't think about the case of no real console replacing the early console. The intention of the patch is to have a smooth handover from the boot console to the real console. And, yes, if no real console is ever registered the boot console keeps running ... i think it also occurs in the case where real console != early console So you can either let it running and *not* mark it __init, so it can keep on going without breaking. Or you can explicitly unregister your boot console at some point, maybe using a late_initcall. wouldnt a common kernel late_initcall() be more appropriate ? if early console hasnt switched over (for whatever reason), then kill it ... -mike - 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/
Re: Early printk behaviour
On Thu 16 Aug 2007 03:45, Gerd Hoffmann pondered: Robin Getz wrote: I was putting together an early printk implementation for the Blackfin, and was wondering what the expected behaviour was in this situation. When I set up my bootargs earlyprintk=serial,ttyBF0,57600 and have no console defined (no graphical console, no serial console). based on the patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511 which no longer calls disable_early_printk, the earlyprintk console never gets turned off (because nothing else ever calls register_console). I get everything out the early console, until the init section is released (where the console structure is sitting), and it starts printing out garbage. Is this expected behaviour? Hmm, sort of, although I didn't think about the case of no real console replacing the early console. The intention of the patch is to have a smooth handover from the boot console to the real console. And, yes, if no real console is ever registered the boot console keeps running ... So you can either let it running and *not* mark it __init, so it can keep on going without breaking. Or you can explicitly unregister your boot console at some point, maybe using a late_initcall. Thanks. Doing things with late_initcall seems to work - is there any problem calling unregister_console on an already unregistered console? I looked in the code, and didn't see any nastyness. -Robin - 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/
Early printk behaviour
I was putting together an early printk implementation for the Blackfin, and was wondering what the expected behaviour was in this situation. When I set up my bootargs earlyprintk=serial,ttyBF0,57600 and have no console defined (no graphical console, no serial console). based on the patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511 which no longer calls disable_early_printk, the earlyprintk console never gets turned off (because nothing else ever calls register_console). I get everything out the early console, until the init section is released (where the console structure is sitting), and it starts printing out garbage. Is this expected behaviour? -Robin - 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/
Early printk behaviour
I was putting together an early printk implementation for the Blackfin, and was wondering what the expected behaviour was in this situation. When I set up my bootargs earlyprintk=serial,ttyBF0,57600 and have no console defined (no graphical console, no serial console). based on the patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69331af79cf29e26d1231152a172a1a10c2df511 which no longer calls disable_early_printk, the earlyprintk console never gets turned off (because nothing else ever calls register_console). I get everything out the early console, until the init section is released (where the console structure is sitting), and it starts printing out garbage. Is this expected behaviour? -Robin - 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/
