On Friday 01 December 2006 18:21, Al Viro wrote:
> There is a tempting
> possibility to do that gradually, with all intermediates still in working
> state, provided that on all platforms currently supported by the kernel
> unsigned long and void * are indeed passed the same way (again, only for
>
As noticed by Peter Maydell, the EHCI device driver in Linux gets
miscompiled by some versions of arm-gcc (still need to find out which)
due to a combination of problems:
1. In include/linux/usb/ehci_def.h, struct ehci_caps is defined
with __attribute__((packed)), for no good reason. This is clear
On Wednesday 02 February 2011 17:37:02 Russell King - ARM Linux wrote:
> We used to use inline assembly at one point, but that got chucked out.
> The problem is that using asm() for this causes GCC to generate horrid
> code.
>
> 1. there's no way to tell GCC that the inline assembly is a load
>
On Thursday 03 February 2011 00:08:01 Måns Rullgård wrote:
> > But you really need that memory clobber there whether you like it or
> > not, see above.
>
> I don't know of any device where the side-effects are not explicitly
> indicated by other means in the code triggering them, so it probably
>
On Wednesday 02 February 2011, Russell King - ARM Linux wrote:
> On Wed, Feb 02, 2011 at 05:00:20PM +0100, Arnd Bergmann wrote:
> > I would suggest fixing this by:
> >
> > 2. Changing the ARM MMIO functions to use inline assembly instead of
> > direct pointer dereference
On Saturday 12 February 2011 20:41:01 H.J. Lu wrote:
> Hi,
>
> We made lots of progresses on x32 pABI:
>
> https://sites.google.com/site/x32abi/
>
> 1. Kernel interface with syscall is close to be finalized.
Really? I haven't seen this being posted for review yet ;-)
The basic concept looks en
On Sunday 13 February 2011, H. Peter Anvin wrote:
> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention. That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system calls, otherwise we're pla
On Sunday 13 February 2011, H. Peter Anvin wrote:
> We prototyped using the int $0x80 system call entry point. However,
> there are two disadvantages:
>
> a. the int $0x80 instruction is much slower than syscall. An actual
>i386 process can use the syscall instruction which is disambiguated
On Wednesday 27 April 2011 18:25:40 Alan Stern wrote:
> On Wed, 27 Apr 2011, Rabin Vincent wrote:
>
> > On Wed, Apr 27, 2011 at 00:21, Alan Stern wrote:
> > > On Tue, 26 Apr 2011, Rabin Vincent wrote:
> > >> In my case it's this writel() in ehci-hub.c that gets chopped into
> > >> strbs:
> > >>
>
On Thursday 28 April 2011, Alan Stern wrote:
> > The compiler does not complain, it just silently assumes that it needs
> > to do byte accesses. There is no way to tell the compiler to ignore
> > what it knows about the alignment, other than using inline assembly
> > for the actual pointer derefere
On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
> This is the x32 project status update:
>
> https://sites.google.com/site/x32abi/
>
I've had another look at the kernel patch. It basically
looks all good, but the system call table appears to
diverge from the x86_64 list for no (documented) reaso
On Wednesday 07 March 2012, Alex Shi wrote:
> Understand. thx. So is the following checking that your wanted?
> ===
> diff --git a/include/linux/rwlock.h b/include/linux/rwlock.h
> index bc2994e..64828a3 100644
> --- a/include/linux/rwlock.h
> +++ b/include/linux/rwlock.h
> @@ -21,10 +21,12 @@
>
>> there is an established process for obsoleting/removing support in other
>> components; besides binutils, GDB, and GLIBC, there's QEMU, newlib/libgloss,
>> and the Linux kernel. But, we need to get the ball rolling somewhere.
>
> CC:ing Arnd Bergmann regarding the obs
13 matches
Mail list logo
