Am Dienstag 23 Februar 2010 18:10:22 schrieb Amit Shah: > Hey Rusty, Christian, > > Christoph Hellwig asked why we don't need a barrier before this code in > virtcons_probe(): > > > + /* Start using the new console output. */ > > + early_put_chars = NULL; > > return 0; > > Since only s390 uses early_put_chars so far, you'd know why it's not > needed / why we're safe.
lguest is also using early_put_chars. See arch/x86/lguest/boot.c Anyway I had to look into linux-next to see this code. I guess that is the version you are talking about. (I remember seeing these patches several month ago). So what would a barrier do? Protect against gcc moving the early_put_chars=NULL before the virtqueue is fully initialized and ready? In practice this should not be necessary since the last thing probe might do is add_port which is doing send_control_msg which contains cpu_relax (which is a barrier). So gcc should not be able to move the early_put_chars = NULL before the add_port loop. Anyway, an explicit barrier might be a cleaner and more future proof way of doing it. _______________________________________________ Virtualization mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/virtualization
