Re: [PATCH 06/14] Pramfs: Include files
2009/6/23 Arnd Bergmann : > On Tuesday 23 June 2009, David Woodhouse wrote: >> And dd on /dev/mem would work, surely? > > Actually, reading from /dev/mem is only valid on real RAM. If the nvram > is part of an IO memory mapping, you have to do mmap()+memcpy() rather > than read(). So dd won't do it, but it's still easy to read from user > space. For "security" reasons pram reserve the region of memory with reserve_mem_region_exclusive(). > >> I'd definitely recommend making it fixed-endian. Not doing so for JFFS2 >> was a mistake I frequently regretted. > > Right. > > Arnd <>< > -- 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
Re: I:Re: [PATCH 06/14] Pramfs: Include files
> On Tue, 23 June 2009 19:38:33 +0200, Marco wrote: >> >> dd? You haven't got any device file to have a dump. I think we're going >> a bit out of scope. I had some doubt to support rootfs in pram and after >> some feedback and the comments of this review I think I'll remove it >> from the next release (to understand some aspects of this fs with the >> kernel community was my main goal for this review). I agree to use the >> native endian. As I said the important thing is that if an user want to >> use it in a 64bit environment then the fs must work well and then it >> must be designed to support even this situation, I think it's obvious. > > Glancing at the discussion with Pawel, I see two paths to follow. One > is to turn pramfs into a full-features all-round general-purpose > filesystem with mkfs, fsck, xattr and any number of additional features. > That way lies doom, as you would compete against ext2+xip and have > little new to offer. > > The other path is to make/keep pramfs as simple as possible for > comparatively specialized purposes, like flight recorder data and dump > information. Main selling point here is the amount of vulnerable code > in the total package. ext2 + block layer + vfs helpers is relatively > large and many things may go wrong in a panic situation. > > So I agree with you that many things expected from general purpose > filesystems simply don't apply to pramfs. Moving mkfs into the kernel > is a fair tradeoff, when the required code is small. Endianness is a > different case imo. dd may not work, but a jtag probe will happily get > you the dump to your development machine. > I quite agree, but I'd like to say that it was _not_ my intention to submit a general-purpose fs comparable with ext2 or ext3. > And even within the same box you can have more than one architecture and > endianness. http://www.top500.org/system/9707 will show you one such > beast, which happens to have the top bragging rights at the moment. I > don't want to endorse such strange beasts, but there is no good reason > not to support reading the ppc-written fs from the opteron. In fact, > there is no reason full stop. > > Jörn > MmmJtag dump makes more sense, ok in the next release I rework the layout to have an independent endianess layout. 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
Re: How the kernel printk works before do console_setup.
Johnny Hung wrote: > Hi All: > I have a powerpc arch platform. The default console is ttyS1 not > ttyS0 in the platform. My question is how the kernel print debug > message > like DBG before parse kernel command line and do console_setup > function. The command line passed to kernel about console info is > console=ttyS1. > So kernel can not print anything before parse cmd line and initial > console but the result is against. Anyone point me or give me a clue > is appreciate. Before the console is set up, the printk data is formatted and put into the kernel log buffer, but not sent to any console. Any messages printk'ed before that are buffered but do not appear. When the console is initialized, then all buffered messages are sent to the console, and subsequent printks cause the message to go to the log buffer, but then immediately get sent from there to the console. Under certain conditions you can examine the log buffer of a kernel that failed to initialize it's console, after a warm reset of the machine, using the firmware memory dump command. See http://elinux.org/Kernel_Debugging_Tips#Accessing_the_printk_buffer_after_a_silent_hang_on_boot for some tips on accessing the log buffer of a previous boot. Note also, that if the serial console does not come up, but the kernel successfully boots, and you can get a network login on the machine, you can always print out the kernel log buffer messages using 'dmesg' at a user-space shell prompt. Hope this helps! -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- 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
How the kernel printk works before do console_setup.
Hi All: I have a powerpc arch platform. The default console is ttyS1 not ttyS0 in the platform. My question is how the kernel print debug message like DBG before parse kernel command line and do console_setup function. The command line passed to kernel about console info is console=ttyS1. So kernel can not print anything before parse cmd line and initial console but the result is against. Anyone point me or give me a clue is appreciate. BR, H. Johnny -- 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
Re: [PATCH 06/14] Pramfs: Include files
On Tuesday 23 June 2009, David Woodhouse wrote: > And dd on /dev/mem would work, surely? Actually, reading from /dev/mem is only valid on real RAM. If the nvram is part of an IO memory mapping, you have to do mmap()+memcpy() rather than read(). So dd won't do it, but it's still easy to read from user space. > I'd definitely recommend making it fixed-endian. Not doing so for JFFS2 > was a mistake I frequently regretted. Right. Arnd <>< -- 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
Re: [PATCH 06/14] Pramfs: Include files
On Tue, 2009-06-23 at 21:26 +0200, Jörn Engel wrote: > Endianness is a > different case imo. dd may not work, but a jtag probe will happily get > you the dump to your development machine. And dd on /dev/mem would work, surely? I'd definitely recommend making it fixed-endian. Not doing so for JFFS2 was a mistake I frequently regretted. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- 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
Re: [PATCH 06/14] Pramfs: Include files
On Tue, 23 June 2009 19:38:33 +0200, Marco wrote: > > dd? You haven't got any device file to have a dump. I think we're going > a bit out of scope. I had some doubt to support rootfs in pram and after > some feedback and the comments of this review I think I'll remove it > from the next release (to understand some aspects of this fs with the > kernel community was my main goal for this review). I agree to use the > native endian. As I said the important thing is that if an user want to > use it in a 64bit environment then the fs must work well and then it > must be designed to support even this situation, I think it's obvious. Glancing at the discussion with Pawel, I see two paths to follow. One is to turn pramfs into a full-features all-round general-purpose filesystem with mkfs, fsck, xattr and any number of additional features. That way lies doom, as you would compete against ext2+xip and have little new to offer. The other path is to make/keep pramfs as simple as possible for comparatively specialized purposes, like flight recorder data and dump information. Main selling point here is the amount of vulnerable code in the total package. ext2 + block layer + vfs helpers is relatively large and many things may go wrong in a panic situation. So I agree with you that many things expected from general purpose filesystems simply don't apply to pramfs. Moving mkfs into the kernel is a fair tradeoff, when the required code is small. Endianness is a different case imo. dd may not work, but a jtag probe will happily get you the dump to your development machine. And even within the same box you can have more than one architecture and endianness. http://www.top500.org/system/9707 will show you one such beast, which happens to have the top bragging rights at the moment. I don't want to endorse such strange beasts, but there is no good reason not to support reading the ppc-written fs from the opteron. In fact, there is no reason full stop. Jörn -- Beware of bugs in the above code; I have only proved it correct, but not tried it. -- Donald Knuth -- 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
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
On Tue 2009-06-23 20:07:23, Marco wrote: > 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 > >>> better with ext2. > >> Not if you want the RAM-based filesystem to persist over a kernel > >> invocation. > > > > Yes, you'll need to code Persistent, RAM-based _block_device_. > > First of all I have to say that I'd like to update the site and make it > clearer but at the moment it's not possible because I'm not the admin > and I've already asked to the sourceforge support to have this possibility. > > About the comments: sincerely I don't understand the comments. We have > *already* a fs that takes care to remap a piace of ram (ram, sram, > nvram, etc.), takes care of caching problems, takes care of write Well, it looks pramfs design is confused. 13MB/sec shows that caching _is_ useful for pramfs. So...? > You are talked about journaling. This schema works well for a disk, but > what about a piece of ram? What about a crazy kernel that write in that > area for a bug? Do you remember for example the e1000e bug? It's not I believe you need both journaling *and* write protection. How do you handle power fault while writing data? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
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 >>> better with ext2. >> Not if you want the RAM-based filesystem to persist over a kernel >> invocation. > > Yes, you'll need to code Persistent, RAM-based _block_device_. > Pavel First of all I have to say that I'd like to update the site and make it clearer but at the moment it's not possible because I'm not the admin and I've already asked to the sourceforge support to have this possibility. About the comments: sincerely I don't understand the comments. We have *already* a fs that takes care to remap a piace of ram (ram, sram, nvram, etc.), takes care of caching problems, takes care of write protection, takes care to be "persistent", can use xip and it's my intention to add in the next future other features like acl, xattr and so on. You are talked about journaling. This schema works well for a disk, but what about a piece of ram? What about a crazy kernel that write in that area for a bug? Do you remember for example the e1000e bug? It's not casual that this fs use an hw protection schema. I mean, this fs is not only a "yet another fs", but a fs born with a specific target. So I think modifying a ramdisk to have these behaviors isn't a little modification. 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
Re: [PATCH 06/14] Pramfs: Include files
Sam Ravnborg wrote: >>> 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 > dd? You haven't got any device file to have a dump. I think we're going a bit out of scope. I had some doubt to support rootfs in pram and after some feedback and the comments of this review I think I'll remove it from the next release (to understand some aspects of this fs with the kernel community was my main goal for this review). I agree to use the native endian. As I said the important thing is that if an user want to use it in a 64bit environment then the fs must work well and then it must be designed to support even this situation, I think it's obvious. 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
Re: [PATCH 06/14] Pramfs: Include files
On Tue, 2009-06-23 at 07:57 +0200, Jörn Engel wrote: > > Feel free to improve the test. It is admittedly crap and designed to > support Chris' argument. But seeing that it still fails to do so and > Arnd has already shown one improvement that weakened Chris' argument, > I > guess we can all agree that further improvments won't change the > conclusion, can we? ;) True. At this point, I'm actually more interested in just how crap the kernel code is, that's generated by your test. We don't have a portable way to store a wrong-endian number. Using st_le32() on PowerPC we can get it down to something like this... le32: 2875 cycles be32: 26564494 cycles loops: 1 le32: 21739926 cycles be32: 20289854 cycles loops: 1 le32: 25206069 cycles be32: 20289854 cycles loops: 1 le32: 21739435 cycles be32: 17391303 cycles loops: 1 le32: 22197744 cycles be32: 17391305 cycles loops: 1 le32: 22195411 cycles be32: 21946167 cycles loops: 1 a0: 7f 4c 42 e6 mftbl r26 a4: 2c 1a 00 00 cmpwi r26,0 a8: 41 a2 ff f8 beq-a0 <.init_module+0x54> ac: 3c 00 05 f5 lis r0,1525 b0: 3b 7f 00 70 addir27,r31,112 b4: 60 00 e1 00 ori r0,r0,57600 b8: 7d 20 dc 2c lwbrx r9,0,r27 bc: 39 29 00 01 addir9,r9,1 c0: 79 29 00 20 clrldi r9,r9,32 c4: 7d 20 dd 2c stwbrx r9,0,r27 c8: 34 00 ff ff addic. r0,r0,-1 cc: 40 82 ff ec bne+b8 <.init_module+0x6c> d0: 7f ac 42 e6 mftbl r29 d4: 2c 1d 00 00 cmpwi r29,0 d8: 41 a2 ff f8 beq-d0 <.init_module+0x84> dc: 3c 00 05 f5 lis r0,1525 e0: 60 00 e1 00 ori r0,r0,57600 e4: 81 3f 00 74 lwz r9,116(r31) e8: 39 29 00 01 addir9,r9,1 ec: 91 3f 00 74 stw r9,116(r31) f0: 34 00 ff ff addic. r0,r0,-1 f4: 40 82 ff f0 bne+e4 <.init_module+0x98> f8: 7f 8c 42 e6 mftbl r28 Interestingly, if we get rid of the (gratuitous, afaict) clrldi at 0xc0, the little-endian version goes _faster_: le32: 18839472 cycles be32: 21946166 cycles loops: 1 le32: 25923621 cycles be32: 29629625 cycles loops: 1 -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- 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
