Re: Architectures where unaligned access is (not) OK?
On Fri, Nov 21, 2014 at 12:42:34PM +, Simon McVittie wrote: > A couple of questions for people who know low-level things: > > * Of Debian's architectures (official and otherwise), which ones are > known/defined/designed to be OK with unaligned accesses from > user-space, and which ones (can be configured to) crash or give wrong > answers? > > * Would it be safer to assume that future architectures are in the > "unaligned accesses are OK" category, or the "not OK" > category? > > The ones I know for sure are: > > - OK: any-i386, any-amd64 > - not OK: armel > > I believe powerpc, s390 and arm64 might be in the "OK" category, and > mips* and sparc in the "not OK" category. I've seen conflicting > information about which category armhf is in: on #757037, Marc > Kleine-Budde said that ARMv6 and up guarantee that unaligned access is > fine, but I've also found Ubuntu bug reports about unaligned access > failures on armhf. So, the short answer for the ARM case is that ARMv6 and up guarantee that the processor can be configured such that_some_ unaligned accesses are fine (or at least just inefficient). Linux by default enab this mode - so: - All <=32-bit load/store operations can be unaligned. - NEON load-stores can be unaligned (unless an explicit alignment is specified in the encoding). But: - VFP load/stores must be naturally aligned. - Load-multiple/store-multiple and ldrd/strd do not work with <32-bit alignment, but can sometimes get fixed up by the kernel _at_a_substantial_performance_penalty_. PUSH/POP usually requires 32-bit alignment, but then the ABI requires 64-bit alignment of the stack, so that is less of an issue. Unaligned load-exclusive/store-exclusive operations are not supported. No unaligned accesses are permitted to memory regions of Device or Strongly-ordered type. But some permutation of this will be true for most architectures, and in user-space this would only affect things prodding /dev/mem or otherwise mmaping from a device driver. ARM64 similarly makes it possible to trap unaligned accesses, but if that is not enabled (which it isn't by Linux), everything apart from load-exclusive/store-exclusive, load-acquire/store-release and Device memory accesses will be handled by hardware. There are additional restrictions with regards to guarantees about the atomicity of memory accesses, but I won't go into that now since it is a bit of a special case. / Leif -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141121140055.gk22...@bivouac.eciton.net
Can/should we have an efi/efi-any platform architecture?
When working on UEFI kernel support, for both armhf and arm64, we came across packages (in several distributions) that were manually set to build for architectures where UEFI was available - and so would not be built for the ARM architectures. These are some obvious utilites such as: - efibootmgr - efivar/libefivar - future versions of gnu-efi (upstream support for arm* has not trickled back down yet) But also installer-specific ones like: - partman-efi And some weakly related-to, but not really part of: - dmidecode ... and definitely other ones I haven't come across yet. The point is, when we add support for another architecture which supports UEFI, there are a number of packages that you will want to enable for that architecture. Currently, this means trawling through all of the packages and explicitly adding entries for If we could transition this to be able to specify efi-all (or whatever) instead of an explicit list of certain architectures, this would be a lot more straightforward operation. Most, if not all, of these tools use only standard posix interfaces, so will build cleanly for any architecture. An alternative would of course be to simply do like with acpica-tools, and build all of these tools for all architectures. The problem there would be with packages which depend on packages that only exist on architectures that have UEFI - i.e. partman-efi vs. efi-modules. Would this be useful, desirable, an accident waiting to happen? / Leif -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141211180858.gs2...@bivouac.eciton.net
Re: debian-efi mailing list
On Thu, Dec 11, 2014 at 07:00:34PM +, Steve McIntyre wrote: > Hi folks, > > I'm thinking it might be useful to set up a specific debian-efi > mailing list to help as a central space for discussion about (U)EFI > issues and support in Debian. This sounds very useful to me. > There's been quite a lot of development in this area recently, and (as > Leif just mentioned on -devel) there are a number of packages that > might benefit from wider discussion and (maybe?) group maintenance. We > could also help out with targeted support for users with EFI-related > problems. > > So, pursuant to the HOWTO [1], I'm asking here who else might be > interested in using such a list. Please follow up here and we'll see > how far we get. I would use it. / Leif -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212194042.ga15...@bivouac.eciton.net
