Re: errors when compiling 2.6 kernel source
> > Looks like it hasn't been touched in ages, then. BenH should correct me if
> > I'm way off base, but you basically need to replace, at a minimum:
> >
> > save_flags(flags)+cli() by local_irq_save(flags)
> > restore_flags(flags) by local_irq_restore(flags)
> > sti() by local_irq_enable()
> >
> > for uniprocessor use (are there any SMP capable machines with SWIM3??). If
> > that compiles and runs, you can proceed to using proper spinlock
> > functions (a spinlock has already been added to the driver but isn't
> > currently used).
> >
>
> This code needs to be SMP safe (see Bug#271517). You'll need proper
That's why I asked about SMP machines with SWIM3.
> locking primitives (ie. spin_lock_irqsave(), etc...). The locks will
> compile away on UP machines.
Sure.
> Keep in mind that this isn't a simple case of search and replace. You
> should understand what data needs mutual exclusion. The stray sti()
> looks like a hack. Enabling interrupts with sti() before return is bad
The PC floppy driver does things in much the same way, from a quick
glance. Most notably, the spinlock is never used in that driver either.
Same for the swim_iop driver. I conclude there's not much need for mutual
exclusion here. Yes, I'm aware that the interrupt handling isn't the same
for Intel and PowerPC hardware ...
> practice because your function could be returning to a function that
> expects interrupts to still be disabled.
The driver should make sure this doesn't happen, naturally. Seems to have
worked at some time in the past.
I'm aware that my suggestions are just a first thing to try. If the
machine freezes, or other bad things happen, look more closely. Don't try
this on mission critical hardware :-)
Michael
Reply to: