Re: [patch] ext2: xip check fix
> > 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 relaying here): > For some period of time, the flash memory is not usable and thus we > need to make sure we can nuke the page table entries that we have in > userland page tables. For that, we need a callback from the device so > that it can ask to get its references back. Oh, and a put_xip_page > counterpart to get_xip_page, so that the driver knows when it's safe > to erase. Well... That's the biggest/hardest problem, yes. But not the first. First we got to tackle the easy read only case, which doesn't require any of that unpleasantness, yet which is used in a bunch of out of tree hacks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 expert at all, just relaying here): For some period of time, the flash memory is not usable and thus we need to make sure we can nuke the page table entries that we have in userland page tables. For that, we need a callback from the device so that it can ask to get its references back. Oh, and a put_xip_page counterpart to get_xip_page, so that the driver knows when it's safe to erase. cheers, Carsten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 relaying here): For some period of time, the flash memory is not usable and thus we need to make sure we can nuke the page table entries that we have in userland page tables. For that, we need a callback from the device so that it can ask to get its references back. Oh, and a put_xip_page counterpart to get_xip_page, so that the driver knows when it's safe to erase. Well... That's the biggest/hardest problem, yes. But not the first. First we got to tackle the easy read only case, which doesn't require any of that unpleasantness, yet which is used in a bunch of out of tree hacks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 expert at all, just relaying here): For some period of time, the flash memory is not usable and thus we need to make sure we can nuke the page table entries that we have in userland page tables. For that, we need a callback from the device so that it can ask to get its references back. Oh, and a put_xip_page counterpart to get_xip_page, so that the driver knows when it's safe to erase. cheers, Carsten -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
> 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 driver thingy, which I don't understand, that's specific to the s390. > How does "struct page" enter into this? Don't sweat it, it has to do with the way filemap_xip.c works. > What I want to know is, are you saying execute in place doesn't work on things > like arm and mips? (I so, I was unaware of this. I heard about somebody > getting it to work on a Nintendo DS: > http://forums.maxconsole.net/showthread.php?t=18668 ) XIP works fine on things like arm and mips. However there is mixed support in the mainline kernel for it. For example, you can build an XiP kernel image for arm since like 2.6.10 or 12. Also MTD has an XiP aware mode that protects XiP objects in flash from get screwed up during programs and erases. But there is no mainlined solution for XiP of applications from the filesystem. However there have been patches for cramfs to do this for years. They are kind of messy and keep getting rejected. I do have a solution in the works for this part of it - http://axfs.sf.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 memory extensions have not been implemented > > > > (yet?). And it enables testing xip on other platforms. The patch is on > > > > my must-read list. > > > > > > query: which feature is currently s390 only? (Execute In Place?) > > > > 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. > > 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. > > How does "struct page" enter into this? > > What I want to know is, are you saying execute in place doesn't work on > things > like arm and mips? (I so, I was unaware of this. I heard about somebody > getting it to work on a Nintendo DS: > http://forums.maxconsole.net/showthread.php?t=18668 ) It's just that the only device driver with XIP support for the moment is s390 (and an obscure powerpc one). Now with my ramdisk patch, anybody can use it. That's just using regular RAM, but there is nothing preventing XIP backed by more exotic storage, provided the CPU can natively address and execute from it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 enables testing xip on other platforms. The patch is on > > > my must-read list. > > > > query: which feature is currently s390 only? (Execute In Place?) > > 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. 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. How does "struct page" enter into this? What I want to know is, are you saying execute in place doesn't work on things like arm and mips? (I so, I was unaware of this. I heard about somebody getting it to work on a Nintendo DS: http://forums.maxconsole.net/showthread.php?t=18668 ) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
> > 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 must-read list. > > query: which feature is currently s390 only? (Execute In Place?) 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 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 must-read list. query: which feature is currently s390 only? (Execute In Place?) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 that the flash memory extensions have not been implemented (yet?). And it enables testing xip on other platforms. The patch is on my must-read list. Actually another one's recently sprung up too (arch/powerpc/sysdev/axonram.c) but it looks like that one should be fine as it looks to be all simply memory mapped. Oh I know, the author's office is aproximately 500 meters away from mine, next building. I have'nt heared of anyone actually using that one lately. cheers, Carsten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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, in what way? > I have done some archeology, and our ancient CVS logs show this check > was introduced in early 2005 into our 2.6.x. codebase. However, it > existed way before, and was copied from our prehistorical ext2 split > named xip2 back in the old days of 2.4.x where we did not really have > a block device behind because that one was scamped into the file > system in a very queer way. 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?). > After all, I don't see any risk in removing the check. The only driver > we have that does direct_access is drivers/s390/block/dcssblk.c, and > that one only supports block_size == PAGE_SIZE. I think the patch > should go into mainline. Actually another one's recently sprung up too (arch/powerpc/sysdev/axonram.c) but it looks like that one should be fine as it looks to be all simply memory mapped. > Acked-by: Carsten Otte <[EMAIL PROTECTED]> Thanks! Andrew, would you queue this up for 2.6.25 please? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 logs show this check was introduced in early 2005 into our 2.6.x. codebase. However, it existed way before, and was copied from our prehistorical ext2 split named xip2 back in the old days of 2.4.x where we did not really have a block device behind because that one was scamped into the file system in a very queer way. After all, I don't see any risk in removing the check. The only driver we have that does direct_access is drivers/s390/block/dcssblk.c, and that one only supports block_size == PAGE_SIZE. I think the patch should go into mainline. Acked-by: Carsten Otte <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 how it looks after your patch as a bugfix where our > >>tester tried a 4k filesystem on a 2k blockdev. > >>Did I miss something? > > > >However, the bdev block size may be changed with sb_set_blocksize. It > >doesn't actually have to match the hardware sector size -- if this > >does matter for XIP, then I think you need some other check here. > Hhh. For a bdev with PAGE_SIZE hardsect size, there is no other > valid value then PAGE_SIZE that one could set it to. Or can it indeed > be changed to a value greater then PAGE_SIZE or smaller then hardsect > size? It can't be made smaller (or larger, in current kernels). But you already get all that checking done for you -- both by checking that the filesystem blocksize == PAGE_SIZE, and by the error checking in sb_set_blocksize. 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? Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 4k filesystem on a 2k blockdev. Did I miss something? However, the bdev block size may be changed with sb_set_blocksize. It doesn't actually have to match the hardware sector size -- if this does matter for XIP, then I think you need some other check here. Hhh. For a bdev with PAGE_SIZE hardsect size, there is no other valid value then PAGE_SIZE that one could set it to. Or can it indeed be changed to a value greater then PAGE_SIZE or smaller then hardsect size? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 4k filesystem on a 2k blockdev. Did I miss something? However, the bdev block size may be changed with sb_set_blocksize. It doesn't actually have to match the hardware sector size -- if this does matter for XIP, then I think you need some other check here. Hhh. For a bdev with PAGE_SIZE hardsect size, there is no other valid value then PAGE_SIZE that one could set it to. Or can it indeed be changed to a value greater then PAGE_SIZE or smaller then hardsect size? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 how it looks after your patch as a bugfix where our tester tried a 4k filesystem on a 2k blockdev. Did I miss something? However, the bdev block size may be changed with sb_set_blocksize. It doesn't actually have to match the hardware sector size -- if this does matter for XIP, then I think you need some other check here. Hhh. For a bdev with PAGE_SIZE hardsect size, there is no other valid value then PAGE_SIZE that one could set it to. Or can it indeed be changed to a value greater then PAGE_SIZE or smaller then hardsect size? It can't be made smaller (or larger, in current kernels). But you already get all that checking done for you -- both by checking that the filesystem blocksize == PAGE_SIZE, and by the error checking in sb_set_blocksize. 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? Thanks, Nick -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 logs show this check was introduced in early 2005 into our 2.6.x. codebase. However, it existed way before, and was copied from our prehistorical ext2 split named xip2 back in the old days of 2.4.x where we did not really have a block device behind because that one was scamped into the file system in a very queer way. After all, I don't see any risk in removing the check. The only driver we have that does direct_access is drivers/s390/block/dcssblk.c, and that one only supports block_size == PAGE_SIZE. I think the patch should go into mainline. Acked-by: Carsten Otte [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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, in what way? I have done some archeology, and our ancient CVS logs show this check was introduced in early 2005 into our 2.6.x. codebase. However, it existed way before, and was copied from our prehistorical ext2 split named xip2 back in the old days of 2.4.x where we did not really have a block device behind because that one was scamped into the file system in a very queer way. 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?). After all, I don't see any risk in removing the check. The only driver we have that does direct_access is drivers/s390/block/dcssblk.c, and that one only supports block_size == PAGE_SIZE. I think the patch should go into mainline. Actually another one's recently sprung up too (arch/powerpc/sysdev/axonram.c) but it looks like that one should be fine as it looks to be all simply memory mapped. Acked-by: Carsten Otte [EMAIL PROTECTED] Thanks! Andrew, would you queue this up for 2.6.25 please? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 that the flash memory extensions have not been implemented (yet?). And it enables testing xip on other platforms. The patch is on my must-read list. Actually another one's recently sprung up too (arch/powerpc/sysdev/axonram.c) but it looks like that one should be fine as it looks to be all simply memory mapped. Oh I know, the author's office is aproximately 500 meters away from mine, next building. I have'nt heared of anyone actually using that one lately. cheers, Carsten -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 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 must-read list. query: which feature is currently s390 only? (Execute In Place?) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 must-read list. query: which feature is currently s390 only? (Execute In Place?) 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 enables testing xip on other platforms. The patch is on my must-read list. query: which feature is currently s390 only? (Execute In Place?) 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. 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. How does struct page enter into this? What I want to know is, are you saying execute in place doesn't work on things like arm and mips? (I so, I was unaware of this. I heard about somebody getting it to work on a Nintendo DS: http://forums.maxconsole.net/showthread.php?t=18668 ) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 memory extensions have not been implemented (yet?). And it enables testing xip on other platforms. The patch is on my must-read list. query: which feature is currently s390 only? (Execute In Place?) 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. 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. How does struct page enter into this? What I want to know is, are you saying execute in place doesn't work on things like arm and mips? (I so, I was unaware of this. I heard about somebody getting it to work on a Nintendo DS: http://forums.maxconsole.net/showthread.php?t=18668 ) It's just that the only device driver with XIP support for the moment is s390 (and an obscure powerpc one). Now with my ramdisk patch, anybody can use it. That's just using regular RAM, but there is nothing preventing XIP backed by more exotic storage, provided the CPU can natively address and execute from it. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 driver thingy, which I don't understand, that's specific to the s390. How does struct page enter into this? Don't sweat it, it has to do with the way filemap_xip.c works. What I want to know is, are you saying execute in place doesn't work on things like arm and mips? (I so, I was unaware of this. I heard about somebody getting it to work on a Nintendo DS: http://forums.maxconsole.net/showthread.php?t=18668 ) XIP works fine on things like arm and mips. However there is mixed support in the mainline kernel for it. For example, you can build an XiP kernel image for arm since like 2.6.10 or 12. Also MTD has an XiP aware mode that protects XiP objects in flash from get screwed up during programs and erases. But there is no mainlined solution for XiP of applications from the filesystem. However there have been patches for cramfs to do this for years. They are kind of messy and keep getting rejected. I do have a solution in the works for this part of it - http://axfs.sf.net. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 Piggin <[EMAIL PROTECTED]>
> >---
> >Index: linux-2.6/fs/ext2/super.c
> >===
> >--- linux-2.6.orig/fs/ext2/super.c
> >+++ linux-2.6/fs/ext2/super.c
> >@@ -844,8 +844,7 @@ static int ext2_fill_super(struct super_
> >
> > blocksize = BLOCK_SIZE << le32_to_cpu(sbi->s_es->s_log_block_size);
> >
> >-if ((ext2_use_xip(sb)) && ((blocksize != PAGE_SIZE) ||
> >- (sb->s_blocksize != blocksize))) {
> >+if (ext2_use_xip(sb) && blocksize != PAGE_SIZE) {
> > if (!silent)
> > printk("XIP: Unsupported blocksize\n");
> > goto failed_mount;
> "blocksize" contains the blocksize of the device here, and
> sb->s_blocksize does contain the filesystem block size as saved in the
> super block.
You mean blocksize is the size of the ext2 block, and s_blocksize is the
default size of the block device.
> 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 4k filesystem on a 2k blockdev.
> Did I miss something?
However, the bdev block size may be changed with sb_set_blocksize. It
doesn't actually have to match the hardware sector size -- if this
does matter for XIP, then I think you need some other check here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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
===
--- linux-2.6.orig/fs/ext2/super.c
+++ linux-2.6/fs/ext2/super.c
@@ -844,8 +844,7 @@ static int ext2_fill_super(struct super_
blocksize = BLOCK_SIZE << le32_to_cpu(sbi->s_es->s_log_block_size);
- if ((ext2_use_xip(sb)) && ((blocksize != PAGE_SIZE) ||
- (sb->s_blocksize != blocksize))) {
+ if (ext2_use_xip(sb) && blocksize != PAGE_SIZE) {
if (!silent)
printk("XIP: Unsupported blocksize\n");
goto failed_mount;
"blocksize" contains the blocksize of the device here, and
sb->s_blocksize does contain the filesystem block size as saved in the
super block. 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 4k filesystem on a 2k blockdev.
Did I miss something?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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
===
--- linux-2.6.orig/fs/ext2/super.c
+++ linux-2.6/fs/ext2/super.c
@@ -844,8 +844,7 @@ static int ext2_fill_super(struct super_
blocksize = BLOCK_SIZE le32_to_cpu(sbi-s_es-s_log_block_size);
- if ((ext2_use_xip(sb)) ((blocksize != PAGE_SIZE) ||
- (sb-s_blocksize != blocksize))) {
+ if (ext2_use_xip(sb) blocksize != PAGE_SIZE) {
if (!silent)
printk(XIP: Unsupported blocksize\n);
goto failed_mount;
blocksize contains the blocksize of the device here, and
sb-s_blocksize does contain the filesystem block size as saved in the
super block. 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 4k filesystem on a 2k blockdev.
Did I miss something?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
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 Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/fs/ext2/super.c
===
--- linux-2.6.orig/fs/ext2/super.c
+++ linux-2.6/fs/ext2/super.c
@@ -844,8 +844,7 @@ static int ext2_fill_super(struct super_
blocksize = BLOCK_SIZE le32_to_cpu(sbi-s_es-s_log_block_size);
-if ((ext2_use_xip(sb)) ((blocksize != PAGE_SIZE) ||
- (sb-s_blocksize != blocksize))) {
+if (ext2_use_xip(sb) blocksize != PAGE_SIZE) {
if (!silent)
printk(XIP: Unsupported blocksize\n);
goto failed_mount;
blocksize contains the blocksize of the device here, and
sb-s_blocksize does contain the filesystem block size as saved in the
super block.
You mean blocksize is the size of the ext2 block, and s_blocksize is the
default size of the block device.
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 4k filesystem on a 2k blockdev.
Did I miss something?
However, the bdev block size may be changed with sb_set_blocksize. It
doesn't actually have to match the hardware sector size -- if this
does matter for XIP, then I think you need some other check here.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] ext2: xip check fix
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
===
--- linux-2.6.orig/fs/ext2/super.c
+++ linux-2.6/fs/ext2/super.c
@@ -844,8 +844,7 @@ static int ext2_fill_super(struct super_
blocksize = BLOCK_SIZE << le32_to_cpu(sbi->s_es->s_log_block_size);
- if ((ext2_use_xip(sb)) && ((blocksize != PAGE_SIZE) ||
- (sb->s_blocksize != blocksize))) {
+ if (ext2_use_xip(sb) && blocksize != PAGE_SIZE) {
if (!silent)
printk("XIP: Unsupported blocksize\n");
goto failed_mount;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] ext2: xip check fix
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
===
--- linux-2.6.orig/fs/ext2/super.c
+++ linux-2.6/fs/ext2/super.c
@@ -844,8 +844,7 @@ static int ext2_fill_super(struct super_
blocksize = BLOCK_SIZE le32_to_cpu(sbi-s_es-s_log_block_size);
- if ((ext2_use_xip(sb)) ((blocksize != PAGE_SIZE) ||
- (sb-s_blocksize != blocksize))) {
+ if (ext2_use_xip(sb) blocksize != PAGE_SIZE) {
if (!silent)
printk(XIP: Unsupported blocksize\n);
goto failed_mount;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
