see attached.
I am not sure what reaction this will get, but let's see.
ron
ron minnich wrote:
calling console output functions BEFORE console_init is called is an error. This kind of band-aid covers up an error in code, but does not fix it.
I'm in favor, but it could maybe become more complicated when looking at several different console types, because they can only be initialized at different points during startup.
//Peter
On Mon, Apr 13, 2009 at 10:24 AM, Peter Stuge peter@stuge.se wrote:
ron minnich wrote:
calling console output functions BEFORE console_init is called is an error. This kind of band-aid covers up an error in code, but does not fix it.
I'm in favor, but it could maybe become more complicated when looking at several different console types, because they can only be initialized at different points during startup.
right, but that's not how the code works. Basically, as written, the code assumes that no console output is possible before console_init is called, and it assumes that all output is possible after console_init is called.
Hence, if people follow the simple rule: don't call these before console_init, and it's ok to call them after console_init, we can remove the bandaid and make this code usable in CAR.
ron
On Mon, Apr 13, 2009 at 11:28 AM, ron minnich rminnich@gmail.com wrote:
On Mon, Apr 13, 2009 at 10:24 AM, Peter Stuge peter@stuge.se wrote:
ron minnich wrote:
calling console output functions BEFORE console_init is called is an error. This kind of band-aid covers up an error in code, but does not fix it.
I'm in favor, but it could maybe become more complicated when looking at several different console types, because they can only be initialized at different points during startup.
right, but that's not how the code works. Basically, as written, the code assumes that no console output is possible before console_init is called, and it assumes that all output is possible after console_init is called.
Hence, if people follow the simple rule: don't call these before console_init, and it's ok to call them after console_init, we can remove the bandaid and make this code usable in CAR.
Is there a good way to tell what breaks when we take this out? How can you tell from the code whether it's too early to call the functions? I like the cleanup, but if it will break my boards I'd like to know how to fix it afterward.
Thanks, Myles
On Tue, Apr 21, 2009 at 7:32 AM, Myles Watson mylesgw@gmail.com wrote:
Is there a good way to tell what breaks when we take this out? How can you tell from the code whether it's too early to call the functions? I like the cleanup, but if it will break my boards I'd like to know how to fix it afterward.
We need to figure out when it's ok to call them and put that call in hardwaremain, in the right place;
I'll put this on the to-do list. I still think the way it is done is a mistake but I can understand the fear that people have of changing it.
ron
On 21.04.2009 16:46, ron minnich wrote:
On Tue, Apr 21, 2009 at 7:32 AM, Myles Watson mylesgw@gmail.com wrote:
Is there a good way to tell what breaks when we take this out? How can you tell from the code whether it's too early to call the functions? I like the cleanup, but if it will break my boards I'd like to know how to fix it afterward.
We need to figure out when it's ok to call them and put that call in hardwaremain, in the right place;
I'll put this on the to-do list. I still think the way it is done is a mistake but I can understand the fear that people have of changing it.
v3 has/had that issue as well. Basically, we want to print stuff as early as possible, but doing that before the Super I/O is set up is questionable at best. It may work for some machines due to favourable default settings, but I wouldn't count on it.
Regards, Carl-Daniel
On Tue, Apr 21, 2009 at 7:53 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
v3 has/had that issue as well. Basically, we want to print stuff as early as possible, but doing that before the Super I/O is set up is questionable at best. It may work for some machines due to favourable default settings, but I wouldn't count on it.
Every kernel I've ever worked on has this problem. At some point, you can print. Before that point, you can not. The simplest way to handle the problem is to make sure people don't call any print functions before it is possible to do it.
My experience has been that the way we're doing it can cause trouble, because people end up calling print functions that never print anything.
ron
On 21.04.2009 17:08, ron minnich wrote:
On Tue, Apr 21, 2009 at 7:53 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
v3 has/had that issue as well. Basically, we want to print stuff as early as possible, but doing that before the Super I/O is set up is questionable at best. It may work for some machines due to favourable default settings, but I wouldn't count on it.
Every kernel I've ever worked on has this problem. At some point, you can print. Before that point, you can not. The simplest way to handle the problem is to make sure people don't call any print functions before it is possible to do it.
My experience has been that the way we're doing it can cause trouble, because people end up calling print functions that never print anything.
I need to dig up that v3 patch of mine which buffered printk messages until serial was working.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Myles Watson -
Peter Stuge -
ron minnich