2009/6/21 Arnd Bergmann a...@arndb.de:
On Sunday 21 June 2009, Marco wrote:
I was thinking about your comment and I think I'll use __kernel_off_t
for the exported headers. I know that it will differ between 32 and 64
bit architectures, but for this kind of fs there isn't any compatibility
How do you handle hard-links, then?
Indeed hard-links are not supported :) Due to the design of this fs
there are some limitations explained in the documentation as not
hard-link, only private memory mapping and so on. However this
limitations don't limit the fs itself because you must
Pavel Machek wrote:
How do you handle hard-links, then?
Indeed hard-links are not supported :) Due to the design of this fs
there are some limitations explained in the documentation as not
hard-link, only private memory mapping and so on. However this
limitations don't limit the fs itself
On Mon 2009-06-22 10:31:28, Tim Bird wrote:
Pavel Machek wrote:
How do you handle hard-links, then?
Indeed hard-links are not supported :) Due to the design of this fs
there are some limitations explained in the documentation as not
hard-link, only private memory mapping and so on.
Arnd Bergmann wrote:
On Monday 22 June 2009, Marco Stornelli wrote:
It's still a problem. You might be creating a file system image
for an embedded board with a different endianess.
It's not possible to create an image with pramfs, it's like tmpfs.
But the data is persistant, you even
Pavel Machek wrote:
On Mon 2009-06-22 10:31:28, Tim Bird wrote:
Pavel Machek wrote:
How do you handle hard-links, then?
Indeed hard-links are not supported :) Due to the design of this fs
there are some limitations explained in the documentation as not
hard-link, only private memory mapping
On Monday 22 June 2009, Marco wrote:
Sorry, I meant it's not currently possible. At the moment the only way
to use it as rootfs it's to copy all the data in an already mounted
(empty) ram partition and reboot. However it's not my first item on my
todo list because I think that it's possible
Pavel Machek wrote:
On Mon 2009-06-22 10:31:28, Tim Bird wrote:
Pavel Machek wrote:
I did not see that in the changelog. If it is not general purpose
filesystem, it is lot less interesting.
PRAMFS is not a general purpose filesystem. Please read
the introductory post to this thread, or look
Arnd Bergmann wrote:
On Monday 22 June 2009, Marco wrote:
Sorry, I meant it's not currently possible. At the moment the only way
to use it as rootfs it's to copy all the data in an already mounted
(empty) ram partition and reboot. However it's not my first item on my
todo list because I think
On Mon, Jun 22, 2009 at 08:31:10PM +0100, Chris Simmonds wrote:
Arnd Bergmann wrote:
On Monday 22 June 2009, Marco wrote:
Sorry, I meant it's not currently possible. At the moment the only way
to use it as rootfs it's to copy all the data in an already mounted
(empty) ram partition and
On Mon, 22 Jun 2009, Marco wrote:
I don't think, I think it's very clear:
In summary, PRAMFS is a light-weight, full-featured, and
space-efficient special filesystem that is ideal for systems with a
block of fast non-volatile RAM that need to access data on it using a
standard filesytem
On Mon 2009-06-22 20:07:06, Marco wrote:
Pavel Machek wrote:
On Mon 2009-06-22 10:31:28, Tim Bird wrote:
Pavel Machek wrote:
How do you handle hard-links, then?
Indeed hard-links are not supported :) Due to the design of this fs
there are some limitations explained in the documentation
On Mon 2009-06-22 11:55:04, Tim Bird wrote:
Pavel Machek wrote:
On Mon 2009-06-22 10:31:28, Tim Bird wrote:
Pavel Machek wrote:
I did not see that in the changelog. If it is not general purpose
filesystem, it is lot less interesting.
PRAMFS is not a general purpose filesystem. Please
On Mon, 22 June 2009 20:31:10 +0100, Chris Simmonds wrote:
I disagree: that adds an unnecessary overhead for those architectures
where the cpu byte order does not match the data structure ordering. I
think the data structures should be native endian and when mkpramfs is
written it can
On Mon 2009-06-22 14:50:01, Tim Bird wrote:
Pavel Machek wrote:
block of fast non-volatile RAM that need to access data on it using a
standard filesytem interface.
Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
better with ext2.
Not if you want the RAM-based
On Mon 2009-06-22 23:57:53, Pavel Machek wrote:
On Mon 2009-06-22 14:50:01, Tim Bird wrote:
Pavel Machek wrote:
block of fast non-volatile RAM that need to access data on it using a
standard filesytem interface.
Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
On Monday 22 June 2009, Jörn Engel wrote:
Four loops doing the same increment with different data types: long,
u64, we32 (wrong-endian) and we64. Compile with no optimizations.
Results on my i386 notebook:
long: 453953 us
we32: 880273 us
u64: 504214 us
we64:2259953 us
It should be possible to read a file-system on your x86 64bit
box that you wrote with your small powerpc target.
For a (NV)RAM-based filesystem?? WTH???
dd the full image - dig into it.
Usefull is you have post-mortem info there.
Sam
--
To unsubscribe from this list: send the
On Mon, 22 June 2009 23:20:39 +0100, David Woodhouse wrote:
On Mon, 2009-06-22 at 23:41 +0200, Jörn Engel wrote:
Four loops doing the same increment with different data types: long,
u64, we32 (wrong-endian) and we64. Compile with _no_ optimizations.
That's a bit of a poor test then.
19 matches
Mail list logo
