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 support using it as a root file > system, so the data has to have a way to get there. Even if you > don't do it right now, I don't see any fundamental limitation that > prevents you from creating an image on one machine and dumping it > into the nvram of another machine as part of manufacturing or testing. >
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 to use it as rootfs but it isn't the standard use for this fs. >>> Or even on the same machine, you could be looking at the file system >>> contents >>> with a 32 bit process running on a 64 bit kernel. >> Yes, indeed the most important thing is to be sure that a 64bit kernel >> works well. I'll try to test it in this environment. If there are >> "64bit guys" to help me to test it, it'd be great. > > This particular problem (__kernel_off_t on 64-bit machines) can be avoided > by just switching to __kernel_loff_t, which is 64 bit long on all machines, > while __kernel_off_t is always the register length (32 or 64 bits). > > Arnd <>< > Yep, it can be a good idea, thanks for the tip. Marco -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
