linux-kernel - Re: [PATCH 06/14] Pramfs: Include files

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4A3FC7F1.5050108@gmail.com>
Date:	Mon, 22 Jun 2009 20:05:37 +0200
From:	Marco <marco.stornelli@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Sam Ravnborg <sam@...nborg.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Linux Embedded <linux-embedded@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 06/14] Pramfs: Include files

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/