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
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
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
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:
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
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 the
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 mmap
and
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
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
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
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
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 persistent
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.
The needs for a
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 particular, it has no metadata
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
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
> > 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
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 from rom to
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: see Documentation/filesystems/xip.txt
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 rely on a
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: see Documentation/filesystems/xip.txt
Depends
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.
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 :)
but
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
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
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
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
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 unsubscribe linux-kernel
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: see Documentation/filesystems/xip.txt
As I understand it, xip
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 have their code segments duplicated in ram?
Only ext2 supports it today: see
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
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 question is,
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 tmpfs to use
such 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
such 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.html
Please
42 matches
Mail list logo
