On Fri, Jun 19, 2009 at 5:57 PM, Carl-Daniel Hailfingerc-d.hailfinger.devel.2006@gmx.net wrote:
On 20.06.2009 02:39, ron minnich wrote:
On Fri, Jun 19, 2009 at 4:46 PM, Carl-Daniel Hailfinger wrote
do_printk is defined in src/arch/i386/lib/printk_init.c as almost identical function, but without console_tx_flush and without locking. If only one CPU uses the lockless variant, we lose.
it's very useful. It can be used in the rom/CAR code before consoles really work.
Hm. AFAICS both versions have the same console requirements and just differ in locking (if you ignore the _flush no-op).
not at all. They are quite different in purpose as my earlier email points out. printk prints to all console_drivers and is intended for use when RAM is up and working. do_printk is meant for pre-RAM usage.
I actually did not write any of this stuff, but I got acquainted with it in the last two weeks.
True, but our console requirements for both versions are pretty minimal and I think we showed in v3 that a one-size-fits-all printk can work fine.
I do not recall that v3 printk was heavily tested with smp. In fact it's not smp safe from my reading of the code.
v3 printk looks most like do_printk in v2. Part of the reason is that we had decided, long ago, that the v3 console would only be serial. So we gave up the flexibility of v2 but gained simplicity.
Actually, I can verify that v3 printk works badly on multi-core, since I saw the intermixed output during my abortive attempt at getting core 2 going on v3. v3 does NOT solve the problem.
I'll say it again: getting this right is going to require careful thought and ripping up of the first couple ideas. It only looks simple. CAR makes things a bit messy, and the wide variant in CAR behavior among different vendor's CPUs makes it really messy. One size will NOT fit all.
ron