> As far as I can tell from this conversation there are special "Xen" > drivers that need this not the rest of the system. Yes, but in general when a driver that runs on multiple architectures (including IA64 btw) needs something architecture specific we usually add it to asm, not add ifdefs. > > > for those special xen drivers. > > > > Well there might be reasons someone else uses this in the future too. > > It's also not exactly Linux style - normally we try to add generic > > facilities. > > What possible use could there be to someone else? e.g. for other hypervisors or possibly for special hardware access (e.g. I could imagine it being used for some kind of cluster interconnect) I remember Alan was using a similar hack in his EDAC drivers because it was the only way to clear ECC errors. > The "atomic" ops lock/unlock crap exists only for i386 as far as I can > tell. As you said most architectures either always use atomic ops or > never. The lock/unlock atomic ops are i386 specific material that > better stay contained. Its arch specific and not generic. Well we have our share of weird hacks for IA64 too in generic code. Just adding a single line #include for a wrapper asm-generic surely isn't a undue burden for the other architectures, and it will save some mess in the Xen drivers. -Andi
