On Wed, Jun 25, 2014 at 10:08:02AM -0700, Linus Torvalds wrote:
> Ted,
> going through pending issues, and wondering if I'm expected to pick
> this up directly? The original came through your tree (commit
> 1f3e55fe02d1: "fs/mbcache.c: doucple the locking of local from global
> data") and is in 3.
Ted,
going through pending issues, and wondering if I'm expected to pick
this up directly? The original came through your tree (commit
1f3e55fe02d1: "fs/mbcache.c: doucple the locking of local from global
data") and is in 3.15 too, so the patch should be marked for stable as
well.
It's hopefully
On Tue, 24 Jun 2014, Thavatchai Makphaibulchoke wrote:
> > This change causes breakage:
> >
> > fs/built-in.o: In function `__mb_cache_entry_release':
> > mbcache.c:(.text+0x56b3c): undefined reference to `log2'
> > mbcache.c:(.text+0x56b3c): relocation truncated to fit: R_MIPS_26 against
> > `
On 06/24/2014 04:03 PM, Maciej W. Rozycki wrote:
> On Thu, 3 Apr 2014, Theodore Ts'o wrote:
>
>> fs/mbcache.c: doucple the locking of local from global data
>
> This change causes breakage:
>
> fs/built-in.o: In function `__mb_cache_entry_release':
> mbcache.c:(.text+0x56b3c): undefined r
On Thu, 3 Apr 2014, Theodore Ts'o wrote:
> fs/mbcache.c: doucple the locking of local from global data
This change causes breakage:
fs/built-in.o: In function `__mb_cache_entry_release':
mbcache.c:(.text+0x56b3c): undefined reference to `log2'
mbcache.c:(.text+0x56b3c): relocation truncat
It is quite frankly ridiculous how much work it takes to wire up a new system
call. It should be possible to do it across architectures without all this
crap.
On April 9, 2014 11:23:24 AM PDT, Theodore Ts'o wrote:
>On Wed, Apr 09, 2014 at 07:48:32PM +0200, Geert Uytterhoeven wrote:
>> >
>> > I
On Wed, Apr 09, 2014 at 07:48:32PM +0200, Geert Uytterhoeven wrote:
> >
> > I'm missing context here, but as an x86 maintainer I have no intention
> > of allowing system calls that aren't x86-specific to be added to x86-64
> > only.
>
> commit 520c8b16505236fc82daa352e6c5e73cd9870cff
> Author: Mik
Hi Peter,
On Wed, Apr 9, 2014 at 6:55 PM, H. Peter Anvin wrote:
> On 04/09/2014 09:40 AM, Geert Uytterhoeven wrote:
>> On Tue, Apr 8, 2014 at 3:47 PM, Theodore Ts'o wrote:
>>> On Mon, Apr 07, 2014 at 10:25:30PM +0200, Geert Uytterhoeven wrote:
> maintainers would have no idea that a new sysc
On 04/09/2014 09:40 AM, Geert Uytterhoeven wrote:
> On Tue, Apr 8, 2014 at 3:47 PM, Theodore Ts'o wrote:
>> On Mon, Apr 07, 2014 at 10:25:30PM +0200, Geert Uytterhoeven wrote:
maintainers would have no idea that a new syscall has been added.
>>>
>>> If i386 has the new syscall, scripts/checks
On Tue, Apr 8, 2014 at 3:47 PM, Theodore Ts'o wrote:
> On Mon, Apr 07, 2014 at 10:25:30PM +0200, Geert Uytterhoeven wrote:
>> > maintainers would have no idea that a new syscall has been added.
>>
>> If i386 has the new syscall, scripts/checksyscalls.sh will catch it and
>> inform us about it duri
On Tue, Apr 8, 2014 at 4:25 AM, Heiko Carstens
wrote:
>
> Also it would be nice if somebody would pick up the patch below as well :)
Picked up.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mor
On Mon, Apr 07, 2014 at 10:25:30PM +0200, Geert Uytterhoeven wrote:
> > maintainers would have no idea that a new syscall has been added.
>
> If i386 has the new syscall, scripts/checksyscalls.sh will catch it and
> inform us about it during our next kernel build.
>
> If you add it to x86_64 only
On Mon, Apr 07, 2014 at 10:25:30PM +0200, Geert Uytterhoeven wrote:
> On Mon, Apr 7, 2014 at 4:07 PM, Theodore Ts'o wrote:
> > On Mon, Apr 07, 2014 at 03:15:36PM +0200, Miklos Szeredi wrote:
> >> >
> >> > Is there anything obvious that I might be doing wrong?
> >>
> >> I only wired up the syscall
On Fri, Apr 04, 2014 at 04:23:23PM -0400, Theodore Ts'o wrote:
> Ah yes, I had forgotten that you had sent those patches, thanks.
>
> It looks like that since you worded it as "just RFC for now since they
> aren't in 3.15 yet", the xfstests folks never actually accepted your
> changes into xfstest
On Mon, Apr 7, 2014 at 4:07 PM, Theodore Ts'o wrote:
> On Mon, Apr 07, 2014 at 03:15:36PM +0200, Miklos Szeredi wrote:
>> >
>> > Is there anything obvious that I might be doing wrong?
>>
>> I only wired up the syscall for x86_64. Who's responsible for adding
>> all the syscall tables for the var
On Mon, Apr 07, 2014 at 03:15:36PM +0200, Miklos Szeredi wrote:
> >
> > Is there anything obvious that I might be doing wrong?
>
> I only wired up the syscall for x86_64. Who's responsible for adding
> all the syscall tables for the various architectures?
Ah, and I was testing with i386, not x8
On Sat, Apr 5, 2014 at 1:43 AM, Theodore Ts'o wrote:
> On Fri, Apr 04, 2014 at 07:16:25PM +0200, Miklos Szeredi wrote:
>>
>> http://marc.info/?l=linux-kernel&m=139523745403081&w=2
>
> I tried applying this patch on top of xfstests commit 3948694eb1, but
> running on ext4.git's test branch, which h
On Fri, Apr 04, 2014 at 07:16:25PM +0200, Miklos Szeredi wrote:
>
> http://marc.info/?l=linux-kernel&m=139523745403081&w=2
I tried applying this patch on top of xfstests commit 3948694eb1, but
running on ext4.git's test branch, which has the your cross-rename
patches applied:
http://git.kernel.o
Ah yes, I had forgotten that you had sent those patches, thanks.
It looks like that since you worded it as "just RFC for now since they
aren't in 3.15 yet", the xfstests folks never actually accepted your
changes into xfstests, and so I never picked it up.
For future reference, the tests for COLL
On Fri, Apr 4, 2014 at 3:44 PM, Jan Kara wrote:
> On Thu 03-04-14 23:53:08, Ted Tso wrote:
>> On Thu, Apr 03, 2014 at 12:39:42PM -0700, Linus Torvalds wrote:
>> > Btw, since I'm planning on getting to the filesystem pulls later today
>> > (or perhaps tomorrow), I wanted to check: are you ok with t
On Thu 03-04-14 23:53:08, Ted Tso wrote:
> On Thu, Apr 03, 2014 at 12:39:42PM -0700, Linus Torvalds wrote:
> > Btw, since I'm planning on getting to the filesystem pulls later today
> > (or perhaps tomorrow), I wanted to check: are you ok with the ext4
> > parts of the cross-rename patches from Mik
On Thu, Apr 03, 2014 at 12:39:42PM -0700, Linus Torvalds wrote:
> Btw, since I'm planning on getting to the filesystem pulls later today
> (or perhaps tomorrow), I wanted to check: are you ok with the ext4
> parts of the cross-rename patches from Miklos?
>
> They are currently at
>
> git://git.
Btw, since I'm planning on getting to the filesystem pulls later today
(or perhaps tomorrow), I wanted to check: are you ok with the ext4
parts of the cross-rename patches from Miklos?
They are currently at
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git cross-rename
in case you
Note: there will be a minor patch conflict since you included an
earlier version of the"atomically set inode->i_flags in
ext4_set_inode_flags()" in 3.14 bbefore you decided that
set_mask_bits() wasn't a good interface to be exposing because people
could too easily misuse it. The merge conflict is
24 matches
Mail list logo
