H. Peter Anvin wrote:
> Al Boldi wrote:
> > You don't really think that anybody is suggesting to store the tmpfs
> > data without any coherency, do you?
> >
> > I am suggesting that you can easily isolate tmpfs coherency from the
> > rest of the page-cache, by simply streaming tmpfs data out to an
Al Boldi wrote:
>
> You don't really think that anybody is suggesting to store the tmpfs data
> without any coherency, do you?
>
> I am suggesting that you can easily isolate tmpfs coherency from the rest of
> the page-cache, by simply streaming tmpfs data out to an mmap and plugging
> it with
H. Peter Anvin wrote:
> Al Boldi wrote:
> >> What you're talking about is, *and should be*, a different filesystem.
> >> You will relatively quickly find that you have to deal with the same
> >> kind of stuff that you have to in any filesystem.
> >
> > That's exactly what I want to avoid, as this w
Al Boldi wrote:
>
>> What you're talking about is, *and should be*, a different filesystem.
>> You will relatively quickly find that you have to deal with the same
>> kind of stuff that you have to in any filesystem.
>
> That's exactly what I want to avoid, as this would introduce a performance
H. Peter Anvin wrote:
> Al Boldi wrote:
> > H. Peter Anvin wrote:
> >> Al Boldi wrote:
> >>> Isn't everything really just temporary?
> >>>
> >>> Would something like an mmap'd tmpfs be possible?
> >>
> >> No. tmpfs relies on being able to leave data structures in the running
> >> kernel. In parti
Al Boldi wrote:
> H. Peter Anvin wrote:
>> Al Boldi wrote:
>>> Isn't everything really just temporary?
>>>
>>> Would something like an mmap'd tmpfs be possible?
>> No. tmpfs relies on being able to leave data structures in the running
>> kernel. In particular, it has no metadata store at all.
>>
H. Peter Anvin wrote:
> Al Boldi wrote:
> > Isn't everything really just temporary?
> >
> > Would something like an mmap'd tmpfs be possible?
>
> No. tmpfs relies on being able to leave data structures in the running
> kernel. In particular, it has no metadata store at all.
>
> The needs for a pe
Al Boldi wrote:
>
> Isn't everything really just temporary?
>
> Would something like an mmap'd tmpfs be possible?
>
No. tmpfs relies on being able to leave data structures in the running
kernel. In particular, it has no metadata store at all.
The needs for a persistent filesystem are very di
Al Boldi wrote:
> Dmitry Krivoschekov wrote:
>> Al Boldi wrote:
>>> Now, if there were only an easy way to make tmpfs persistent?
>> It would be not a tmpfs (*temporary* fs)then,
>
> Isn't everything really just temporary?
Would you like to talk about this?
Not with me, I'm not a psychoanalyst :)
On Thu, 3 May 2007 13:38:22 +0200, Erik Mouw wrote:
> On Wed, May 02, 2007 at 03:04:44PM +0100, Hugh Dickins wrote:
> >
> > Only ext2 supports it today: see Documentation/filesystems/xip.txt
>
> IIRC JFFS2 also supports XIP.
Definitely not. AXFS does, if you want to consider out-of-tree patches
om memory rather than copying
> > them to ram first, then executing from there. I was wondering if
> > rootfs or tmpfs support such execute in place today, or if
> > binaries executed from there have their code segments duplicated
> > in ram?
>
> Only ext2 supports it toda
Dmitry Krivoschekov wrote:
> Al Boldi wrote:
> > Now, if there were only an easy way to make tmpfs persistent?
>
> It would be not a tmpfs (*temporary* fs)then,
Isn't everything really just temporary?
> but something like this
>
> http://pramfs.sourceforge.net/
Thanks a lot, but this seems to re
> > the original rom memory rather than copying them to ram first, then
> > executing
> > from there. I was wondering if rootfs or tmpfs support such execute in
> > place
> > today, or if binaries executed from there have their code segments
> > duplicated
> &
Al Boldi wrote:
> Hugh Dickins wrote:
>> On Wed, 2 May 2007, Phillip Susi wrote:
>>> Hugh Dickins wrote:
tmpfs doesn't store its stuff in the page cache twice: that's true,
and I didn't mean to imply otherwise. But tmpfs doesn't contain any
support for rom memory: you'd have to copy
Hugh Dickins wrote:
> On Wed, 2 May 2007, Phillip Susi wrote:
> > Hugh Dickins wrote:
> > > tmpfs doesn't store its stuff in the page cache twice: that's true,
> > > and I didn't mean to imply otherwise. But tmpfs doesn't contain any
> > > support for rom memory: you'd have to copy from rom to tmp
On Wed, 2 May 2007, Phillip Susi wrote:
> Hugh Dickins wrote:
> > tmpfs doesn't store its stuff in the page cache twice: that's true,
> > and I didn't mean to imply otherwise. But tmpfs doesn't contain any
> > support for rom memory: you'd have to copy from rom to tmpfs to use it.
>
> The questio
Hugh Dickins wrote:
tmpfs doesn't store its stuff in the page cache twice: that's true,
and I didn't mean to imply otherwise. But tmpfs doesn't contain any
support for rom memory: you'd have to copy from rom to tmpfs to use it.
Hugh
The question is, when you execute a binary on tmpfs, does it
s to directly
> > > execute binaries out of the original rom memory rather than copying
> > > them to ram first, then executing from there. I was wondering if
> > > rootfs or tmpfs support such execute in place today, or if binaries
> > > executed from there
om memory rather than copying
> > them to ram first, then executing from there. I was wondering if
> > rootfs or tmpfs support such execute in place today, or if binaries
> > executed from there have their code segments duplicated in ram?
>
> Only ext2 supports it today
om there. I was wondering if rootfs or tmpfs support such execute in place
> today, or if binaries executed from there have their code segments duplicated
> in ram?
Only ext2 supports it today: see Documentation/filesystems/xip.txt
Hugh
-
To unsubscribe from this list: send the line "u
execute in place today, or if binaries executed from there
have their code segments duplicated in ram?
-
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.h
21 matches
Mail list logo
