> > I think so. The filemap_xip.c functionality doesn't work for Flash
> > memory yet. Flash memory doesn't have struct pages to back it up with
> > which this stuff depends on.
>
> Struct page is not the major issue. The primary problem is writing to
> the media (and I am not a flash expert at
Jared Hulbert wrote:
I think so. The filemap_xip.c functionality doesn't work for Flash
memory yet. Flash memory doesn't have struct pages to back it up with
which this stuff depends on.
Struct page is not the major issue. The primary problem is writing to
the media (and I am not a flash
I think so. The filemap_xip.c functionality doesn't work for Flash
memory yet. Flash memory doesn't have struct pages to back it up with
which this stuff depends on.
Struct page is not the major issue. The primary problem is writing to
the media (and I am not a flash expert at all, just
Jared Hulbert wrote:
I think so. The filemap_xip.c functionality doesn't work for Flash
memory yet. Flash memory doesn't have struct pages to back it up with
which this stuff depends on.
Struct page is not the major issue. The primary problem is writing to
the media (and I am not a flash
> Um, trying to clarify: S390. Also known as zSeries, big iron machine, uses
> its own weird processor design rather than x86, x86-64, arm, or mips
> processors.
Right. filemap_xip.c allows for an XIP filesystem. The only
filesystem that is supported is ext2. Even that requires a block
On Thu, Dec 06, 2007 at 10:17:39PM -0600, Rob Landley wrote:
> On Thursday 06 December 2007 21:22:25 Jared Hulbert wrote:
> > > > I have'nt looked at it yet. I do appreciate it, I think it might
> > > > broaden the user-base of this feature which is up to now s390 only due
> > > > to the fact that
On Thursday 06 December 2007 21:22:25 Jared Hulbert wrote:
> > > I have'nt looked at it yet. I do appreciate it, I think it might
> > > broaden the user-base of this feature which is up to now s390 only due
> > > to the fact that the flash memory extensions have not been implemented
> > > (yet?).
> > I have'nt looked at it yet. I do appreciate it, I think it might
> > broaden the user-base of this feature which is up to now s390 only due
> > to the fact that the flash memory extensions have not been implemented
> > (yet?). And it enables testing xip on other platforms. The patch is on
> >
On Thursday 06 December 2007 04:24:20 Carsten Otte wrote:
> Nick Piggin wrote:
> > OK, thanks for taking a look at that. It will be helpful for testing
> > XIP with my new ramdisk driver (did you see the patch?).
>
> I have'nt looked at it yet. I do appreciate it, I think it might
> broaden the
Nick Piggin wrote:
OK, thanks for taking a look at that. It will be helpful for testing
XIP with my new ramdisk driver (did you see the patch?).
I have'nt looked at it yet. I do appreciate it, I think it might
broaden the user-base of this feature which is up to now s390 only due
to the fact
On Thu, Dec 06, 2007 at 10:59:02AM +0100, Carsten Otte wrote:
> Nick Piggin wrote:
> >After my patch, we can do XIP in a hardsect size < PAGE_SIZE block
> >device -- this seems to be a fine thing to do at least for the
> >ramdisk code. Would this situation be problematic for existing drivers,
>
Nick Piggin wrote:
After my patch, we can do XIP in a hardsect size < PAGE_SIZE block
device -- this seems to be a fine thing to do at least for the
ramdisk code. Would this situation be problematic for existing drivers,
and if so, in what way?
I have done some archeology, and our ancient CVS
On Thu, Dec 06, 2007 at 09:43:27AM +0100, Carsten Otte wrote:
> Nick Piggin wrote:
> >>Xip does only work, if both do match PAGE_SIZE because it
> >>does'nt support multiple calls to direct_access in the get_xip_page
> >>address space operation. Thus we check both here, actually this was
>
Nick Piggin wrote:
Xip does only work, if both do match PAGE_SIZE because it
does'nt support multiple calls to direct_access in the get_xip_page
address space operation. Thus we check both here, actually this was
changed from how it looks after your patch as a bugfix where our
tester tried a
Nick Piggin wrote:
Xip does only work, if both do match PAGE_SIZE because it
does'nt support multiple calls to direct_access in the get_xip_page
address space operation. Thus we check both here, actually this was
changed from how it looks after your patch as a bugfix where our
tester tried a
On Thu, Dec 06, 2007 at 09:43:27AM +0100, Carsten Otte wrote:
Nick Piggin wrote:
Xip does only work, if both do match PAGE_SIZE because it
does'nt support multiple calls to direct_access in the get_xip_page
address space operation. Thus we check both here, actually this was
changed from
Nick Piggin wrote:
After my patch, we can do XIP in a hardsect size PAGE_SIZE block
device -- this seems to be a fine thing to do at least for the
ramdisk code. Would this situation be problematic for existing drivers,
and if so, in what way?
I have done some archeology, and our ancient CVS
On Thu, Dec 06, 2007 at 10:59:02AM +0100, Carsten Otte wrote:
Nick Piggin wrote:
After my patch, we can do XIP in a hardsect size PAGE_SIZE block
device -- this seems to be a fine thing to do at least for the
ramdisk code. Would this situation be problematic for existing drivers,
and if so,
Nick Piggin wrote:
OK, thanks for taking a look at that. It will be helpful for testing
XIP with my new ramdisk driver (did you see the patch?).
I have'nt looked at it yet. I do appreciate it, I think it might
broaden the user-base of this feature which is up to now s390 only due
to the fact
On Thursday 06 December 2007 04:24:20 Carsten Otte wrote:
Nick Piggin wrote:
OK, thanks for taking a look at that. It will be helpful for testing
XIP with my new ramdisk driver (did you see the patch?).
I have'nt looked at it yet. I do appreciate it, I think it might
broaden the user-base
I have'nt looked at it yet. I do appreciate it, I think it might
broaden the user-base of this feature which is up to now s390 only due
to the fact that the flash memory extensions have not been implemented
(yet?). And it enables testing xip on other platforms. The patch is on
my
On Thursday 06 December 2007 21:22:25 Jared Hulbert wrote:
I have'nt looked at it yet. I do appreciate it, I think it might
broaden the user-base of this feature which is up to now s390 only due
to the fact that the flash memory extensions have not been implemented
(yet?). And it
On Thu, Dec 06, 2007 at 10:17:39PM -0600, Rob Landley wrote:
On Thursday 06 December 2007 21:22:25 Jared Hulbert wrote:
I have'nt looked at it yet. I do appreciate it, I think it might
broaden the user-base of this feature which is up to now s390 only due
to the fact that the flash
Um, trying to clarify: S390. Also known as zSeries, big iron machine, uses
its own weird processor design rather than x86, x86-64, arm, or mips
processors.
Right. filemap_xip.c allows for an XIP filesystem. The only
filesystem that is supported is ext2. Even that requires a block
device
On Wed, Dec 05, 2007 at 04:43:16PM +0100, Carsten Otte wrote:
> Nick Piggin wrote:
> >Am I missing something here? I wonder how s390 works without this change?
> >
> >--
> >ext2 should not worry about checking sb->s_blocksize for XIP before the
> >sb's blocksize actually gets set.
> >
>
Nick Piggin wrote:
Am I missing something here? I wonder how s390 works without this change?
--
ext2 should not worry about checking sb->s_blocksize for XIP before the
sb's blocksize actually gets set.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/fs/ext2/super.c
Nick Piggin wrote:
Am I missing something here? I wonder how s390 works without this change?
--
ext2 should not worry about checking sb-s_blocksize for XIP before the
sb's blocksize actually gets set.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/fs/ext2/super.c
On Wed, Dec 05, 2007 at 04:43:16PM +0100, Carsten Otte wrote:
Nick Piggin wrote:
Am I missing something here? I wonder how s390 works without this change?
--
ext2 should not worry about checking sb-s_blocksize for XIP before the
sb's blocksize actually gets set.
Signed-off-by: Nick
Am I missing something here? I wonder how s390 works without this change?
--
ext2 should not worry about checking sb->s_blocksize for XIP before the
sb's blocksize actually gets set.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/fs/ext2/super.c
Am I missing something here? I wonder how s390 works without this change?
--
ext2 should not worry about checking sb-s_blocksize for XIP before the
sb's blocksize actually gets set.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/fs/ext2/super.c
30 matches
Mail list logo
