> > i've noticed that we do 'cld' way too often. Maybe there is some
> > nonobvious reason to use it, but isnt it so that all kernel entry points
> > do a cld currently.
>
> This should be fine as long as you verify that all kernel entry points do
> have the cld - which I think they do. I'm nervous about it, though,
> because even if there _is_ a missing cld somewhere, it would very seldom
> show up as a bug (because almost nothing sets cld, so even with a missing
> cld it _usually_ does the right thing).
yes, it's extremely subtle, but there is a trick to verify this change:
lets connect the change to some other, already verified object. Any entry
point which should do the 'cld' necessarily has to have a new '%ds' loaded
as well. So the task is to find all places which manipulate '%ds' in
assembly, and verify wether they all have the proper 'cld'. A missing
'%ds' causes definit and immediate crashes. Thus if we verify the 'link'
between %ds and the direction, we have verified that all cld's are at
least as safe as %ds loading is, q.e.d. :)
The following places have '%ds' manipulation (grepping over %ds):
drivers/char/apm_bios.c: safe, the code does a 'pushfl/popfl'
arch/i386/boot/compressed/head.S: safe, does cld on bootup
arch/i386/kernel/entry.S: safe, all places do cld on entry
arch/i386/kernel/head.S: safe, does cld
arch/i386/kernel/process.c: unsafe, but reboot doesnt matter, does it? ;)
arch/i386/kernel/trampoline.S: safe, later code does cld
arch/i386/kernel/irq.h: safe, we do cld on entry
[we might put this 'linking' between %ds and the direction flag into a
macro, so nobody can mess things up accidentally in the future?]
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu