* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Johnny Hung @ 2010-01-20 2:32 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Ricard Wanderlof, kernelnewbies, linux-mtd@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, linux-embedded@vger.kernel.org
In-Reply-To: <20100119140600.GH16182@darwin>
2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
> El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
>
>> On Tue, 19 Jan 2010, Johnny Hung wrote:
>>
>>> Okay, I think the steps is below if my rootfs is ramdisk and configure
>>> files in jffs2,
>>>
>>> 1. cp /etc/* /mnt/mtd/etc/ (/mnt/mtd is my jffs2 fs)
>>> 2. rm -rf /etc/*
>>> 3. make symbolic links from all /etc/xx to /mnt/mtd/etc/xxx
>>> 4. remake ramdisk rootfs
>>>
>>> It seems all files in ramdisk rootfs /etc all links to /mnt/mtd/etc/
>>> and try to modify these files is effective after reboot.
>>> But is this a common way in embedded linux ?
>>
Thanks, I understand.
>> In principle, but it is easier (and cleaner) to make a symbolic link from
>> (say) /etc -> /mnt/mtd/etc without linking every individual file and
>> directory.
>
> i totally agree with ricard when you want to move the entire directory
> to jffs2 and not only some selected files
>
>> You could also use a jffs2 file system in flash for your rootfs, that way
>> you wouldn't need a ramdisk at all.
>
> i'd also recommend you to consider if you really need the
> ramdisk. when using a ram disk its entire content is loaded to the RAM
> occupying space, even if you don't use certain files (or part of
> them). other filesystems are more efficient in this aspect.
> if the main purpose is to have a read only rootfs, i'd suggest a look
> at squashfs.
I consider to use ramdisk as rootfs because worry about wrong
operation in rootfs (is use jffs2 rootfs) and it will cause system
boot up failed.
Another query, does the syslogd/klogd log files also store in jffs2
rootfs? Write to jffs2 frequently will reduce flash life cycle.
BRs, H. Johnny
>
> --
> Matthias Kaehlcke
> Embedded Linux Developer
> Barcelona
>
> La posibilidad de realizar un suenyo es lo
> que hace que la vida sea interesante
> .''`.
> using free software / Debian GNU/Linux | http://debian.org : :' :
> `. `'`
> gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
>
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Matthias Kaehlcke @ 2010-01-19 14:06 UTC (permalink / raw)
To: Ricard Wanderlof
Cc: Johnny Hung, kernelnewbies, linux-mtd@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, linux-embedded@vger.kernel.org
In-Reply-To: <Pine.LNX.4.64.1001191414090.32263@lnxricardw.se.axis.com>
El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
> On Tue, 19 Jan 2010, Johnny Hung wrote:
>
>> Okay, I think the steps is below if my rootfs is ramdisk and configure
>> files in jffs2,
>>
>> 1. cp /etc/* /mnt/mtd/etc/ (/mnt/mtd is my jffs2 fs)
>> 2. rm -rf /etc/*
>> 3. make symbolic links from all /etc/xx to /mnt/mtd/etc/xxx
>> 4. remake ramdisk rootfs
>>
>> It seems all files in ramdisk rootfs /etc all links to /mnt/mtd/etc/
>> and try to modify these files is effective after reboot.
>> But is this a common way in embedded linux ?
>
> In principle, but it is easier (and cleaner) to make a symbolic link from
> (say) /etc -> /mnt/mtd/etc without linking every individual file and
> directory.
i totally agree with ricard when you want to move the entire directory
to jffs2 and not only some selected files
> You could also use a jffs2 file system in flash for your rootfs, that way
> you wouldn't need a ramdisk at all.
i'd also recommend you to consider if you really need the
ramdisk. when using a ram disk its entire content is loaded to the RAM
occupying space, even if you don't use certain files (or part of
them). other filesystems are more efficient in this aspect.
if the main purpose is to have a read only rootfs, i'd suggest a look
at squashfs.
--
Matthias Kaehlcke
Embedded Linux Developer
Barcelona
La posibilidad de realizar un suenyo es lo
que hace que la vida sea interesante
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Ricard Wanderlof @ 2010-01-19 13:17 UTC (permalink / raw)
To: Johnny Hung
Cc: kernelnewbies, linuxppc-dev@lists.ozlabs.org,
linux-mtd@lists.infradead.org, linux-embedded@vger.kernel.org,
Matthias Kaehlcke
In-Reply-To: <cb9ecdfa1001190403v433d839dy6ba2bc018024ce15@mail.gmail.com>
On Tue, 19 Jan 2010, Johnny Hung wrote:
> Okay, I think the steps is below if my rootfs is ramdisk and configure
> files in jffs2,
>
> 1. cp /etc/* /mnt/mtd/etc/ (/mnt/mtd is my jffs2 fs)
> 2. rm -rf /etc/*
> 3. make symbolic links from all /etc/xx to /mnt/mtd/etc/xxx
> 4. remake ramdisk rootfs
>
> It seems all files in ramdisk rootfs /etc all links to /mnt/mtd/etc/
> and try to modify these files is effective after reboot.
> But is this a common way in embedded linux ?
In principle, but it is easier (and cleaner) to make a symbolic link from
(say) /etc -> /mnt/mtd/etc without linking every individual file and
directory.
You could also use a jffs2 file system in flash for your rootfs, that way
you wouldn't need a ramdisk at all.
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Johnny Hung @ 2010-01-19 12:03 UTC (permalink / raw)
To: Matthias Kaehlcke; +Cc: linux-embedded, linuxppc-dev, linux-mtd, kernelnewbies
In-Reply-To: <20100119102026.GF16182@darwin>
2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
> El Tue, Jan 19, 2010 at 06:13:07PM +0800 Johnny Hung ha dit:
>
>> 2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
>> > El Tue, Jan 19, 2010 at 05:20:53PM +0800 Johnny Hung ha dit:
>> >
>> >> I have build an embedded Linux system and rootfs is a ramdisk. Ramdisk
>> >> rootfs resides in memory so modify files is non-effective after a
>> >> reboot. Some directories in rootfs, like /etc, /usr, ... are contain
>> >> many application configuration files and I want to mount it to jffs2
>> >> flash filesysyem so it will take effect after a reboot. Is it
>> >> possible?
>> >
>> How to do it? The ramdisk rootfs is ext2 filesystem and I try,
>> mount /mnt/mtd/etc /etc
>>
>> Try to modify /etc/ files is not works.
>
> ok, i understood you want to substitute the ramdisk rootfs by jffs2
> based one
>
> mounting the ramdisk as writable with the flash as backing storage
> isn't possible AFAIK. and even if it was possible it wouldn't be
> recommended as ext2 doesn't care about flash wear out, in consequence
> you would write the same blocks over and over again.
>
>> > yes, this is possible
>> >
>> >> I know the flash has write times limited so the log files
>> >> (syslogd/klogd) should not store in flash. In general, how to deploy
>> >> root file system for embedded linux with flash storage?
>> >
>> > - add jffs2 support to your kernel
>> > - create your image using mkfs.jffs2 from mtd-utils
>> > - flash the image
>> > - specify the rootfs partition and type in the bootargs of the kernel
>> The above procedure is to create a jffs2 rootfs image but I prefer to
>> use ramdisk rootfs.
>> I think the rootfs is build as ramdisk and some configurable file is
>> store in jffs2 flash.
>
Okay, I think the steps is below if my rootfs is ramdisk and configure
files in jffs2,
1. cp /etc/* /mnt/mtd/etc/ (/mnt/mtd is my jffs2 fs)
2. rm -rf /etc/*
3. make symbolic links from all /etc/xx to /mnt/mtd/etc/xxx
4. remake ramdisk rootfs
It seems all files in ramdisk rootfs /etc all links to /mnt/mtd/etc/
and try to modify these files is effective after reboot.
But is this a common way in embedded linux ?
I also have another idea, keep ramdisk rootfs /etc files and add a shell script.
1. The shell script execute when system boot up.
2. Check /mnt/mtd/etc/xxx if is exist. If yes, remove /etc/xxx file
and make a symbolic link to /mnt/mtd/etc/xxx. If no, keep /etc/xxx
file.
3. repeat 2 for all /etc files
Any suggestion?
Thank your help.
BRs, H. Johnny
> in this case follow the above steps, except the last one about the
> bootargs and mount the jffs2 partition from your init script. you
> could use symlinks from your ramdisk to the files on jffs2 to
> integrate them in your rootfs
>
> --
> Matthias Kaehlcke
> Embedded Linux Developer
> Barcelona
>
> Anyone who has never made a mistake has never tried anything new
> (Albert Einstein)
> .''`.
> using free software / Debian GNU/Linux | http://debian.org : :' :
> `. `'`
> gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
>
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Matthias Kaehlcke @ 2010-01-19 10:20 UTC (permalink / raw)
To: Johnny Hung; +Cc: linux-embedded, linuxppc-dev, linux-mtd, kernelnewbies
In-Reply-To: <cb9ecdfa1001190213u69469505k9c42142bdc17f750@mail.gmail.com>
El Tue, Jan 19, 2010 at 06:13:07PM +0800 Johnny Hung ha dit:
> 2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
> > El Tue, Jan 19, 2010 at 05:20:53PM +0800 Johnny Hung ha dit:
> >
> >> I have build an embedded Linux system and rootfs is a ramdisk. Ramdisk
> >> rootfs resides in memory so modify files is non-effective after a
> >> reboot. Some directories in rootfs, like /etc, /usr, ... are contain
> >> many application configuration files and I want to mount it to jffs2
> >> flash filesysyem so it will take effect after a reboot. Is it
> >> possible?
> >
> How to do it? The ramdisk rootfs is ext2 filesystem and I try,
> mount /mnt/mtd/etc /etc
>
> Try to modify /etc/ files is not works.
ok, i understood you want to substitute the ramdisk rootfs by jffs2
based one
mounting the ramdisk as writable with the flash as backing storage
isn't possible AFAIK. and even if it was possible it wouldn't be
recommended as ext2 doesn't care about flash wear out, in consequence
you would write the same blocks over and over again.
> > yes, this is possible
> >
> >> I know the flash has write times limited so the log files
> >> (syslogd/klogd) should not store in flash. In general, how to deploy
> >> root file system for embedded linux with flash storage?
> >
> > - add jffs2 support to your kernel
> > - create your image using mkfs.jffs2 from mtd-utils
> > - flash the image
> > - specify the rootfs partition and type in the bootargs of the kernel
> The above procedure is to create a jffs2 rootfs image but I prefer to
> use ramdisk rootfs.
> I think the rootfs is build as ramdisk and some configurable file is
> store in jffs2 flash.
in this case follow the above steps, except the last one about the
bootargs and mount the jffs2 partition from your init script. you
could use symlinks from your ramdisk to the files on jffs2 to
integrate them in your rootfs
--
Matthias Kaehlcke
Embedded Linux Developer
Barcelona
Anyone who has never made a mistake has never tried anything new
(Albert Einstein)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Johnny Hung @ 2010-01-19 10:13 UTC (permalink / raw)
To: Matthias Kaehlcke; +Cc: linux-embedded, linuxppc-dev, linux-mtd, kernelnewbies
In-Reply-To: <20100119095024.GD16182@darwin>
2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
> El Tue, Jan 19, 2010 at 05:20:53PM +0800 Johnny Hung ha dit:
>
>> I have build an embedded Linux system and rootfs is a ramdisk. Ramdisk
>> rootfs resides in memory so modify files is non-effective after a
>> reboot. Some directories in rootfs, like /etc, /usr, ... are contain
>> many application configuration files and I want to mount it to jffs2
>> flash filesysyem so it will take effect after a reboot. Is it
>> possible?
>
How to do it? The ramdisk rootfs is ext2 filesystem and I try,
mount /mnt/mtd/etc /etc
Try to modify /etc/ files is not works.
> yes, this is possible
>
>> I know the flash has write times limited so the log files
>> (syslogd/klogd) should not store in flash. In general, how to deploy
>> root file system for embedded linux with flash storage?
>
> - add jffs2 support to your kernel
> - create your image using mkfs.jffs2 from mtd-utils
> - flash the image
> - specify the rootfs partition and type in the bootargs of the kernel
The above procedure is to create a jffs2 rootfs image but I prefer to
use ramdisk rootfs.
I think the rootfs is build as ramdisk and some configurable file is
store in jffs2 flash.
Thank your reply.
BRs, H. Johnny
>
> for further information i recommend the lecture of
> http://free-electrons.com/doc/flash-filesystems.pdf
>
> depending on your requirements/size of the rootfs partitions UBIFS
> might be an option to consider
>
> --
> Matthias Kaehlcke
> Embedded Linux Developer
> Barcelona
>
> El trabajo es el refugio de los que no tienen nada que hacer
> (Oscar Wilde)
> .''`.
> using free software / Debian GNU/Linux | http://debian.org : :' :
> `. `'`
> gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
>
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Matthias Kaehlcke @ 2010-01-19 9:50 UTC (permalink / raw)
To: Johnny Hung; +Cc: linux-embedded, linuxppc-dev, linux-mtd, kernelnewbies
In-Reply-To: <cb9ecdfa1001190120r593f7799sf566df5a855b8a54@mail.gmail.com>
El Tue, Jan 19, 2010 at 05:20:53PM +0800 Johnny Hung ha dit:
> I have build an embedded Linux system and rootfs is a ramdisk. Ramdisk
> rootfs resides in memory so modify files is non-effective after a
> reboot. Some directories in rootfs, like /etc, /usr, ... are contain
> many application configuration files and I want to mount it to jffs2
> flash filesysyem so it will take effect after a reboot. Is it
> possible?
yes, this is possible
> I know the flash has write times limited so the log files
> (syslogd/klogd) should not store in flash. In general, how to deploy
> root file system for embedded linux with flash storage?
- add jffs2 support to your kernel
- create your image using mkfs.jffs2 from mtd-utils
- flash the image
- specify the rootfs partition and type in the bootargs of the kernel
for further information i recommend the lecture of
http://free-electrons.com/doc/flash-filesystems.pdf
depending on your requirements/size of the rootfs partitions UBIFS
might be an option to consider
--
Matthias Kaehlcke
Embedded Linux Developer
Barcelona
El trabajo es el refugio de los que no tienen nada que hacer
(Oscar Wilde)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ
^ permalink raw reply
* mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Johnny Hung @ 2010-01-19 9:20 UTC (permalink / raw)
To: linux-embedded, linuxppc-dev, linux-mtd, kernelnewbies
Hi ALL,
I have build an embedded Linux system and rootfs is a ramdisk. Ramdisk
rootfs resides in memory so modify files is non-effective after a
reboot. Some directories in rootfs, like /etc, /usr, ... are contain
many application configuration files and I want to mount it to jffs2
flash filesysyem so it will take effect after a reboot. Is it
possible? I know the flash has write times limited so the log files
(syslogd/klogd) should not store in flash. In general, how to deploy
root file system for embedded linux with flash storage?
H. Johnny
^ permalink raw reply
* Re: jffs2_gcd_mtdx thread and umount problem.
From: Joakim Tjernlund @ 2010-01-18 9:13 UTC (permalink / raw)
To: Johnny Hung; +Cc: linux-embedded, linux-mtd, linuxppc-dev
In-Reply-To: <cb9ecdfa1001180026q5856b170t3f4c71191a7b99d8@mail.gmail.com>
Johnny Hung <johnny.hacking@gmail.com> wrote on 18/01/2010 09:26:26:
>
Please don't top post.
> Yes, umount / reboot command doesn't hang after first boot + wait for
> 20 minutes. The jffs2_gcd_mtdx will re-erase empty blocks but how do I
> know it is finished?
You don't or just monitor jffs2_gcd_mtdx until it is finished.
>
> BTW, why jffs2_gcd_mtd need to re-erase empty blocks and it will cause
> some command cannot work if erase block is necessary. I mean many
> pepple could meet this problem if it is need to erase empty block and
> how do they overcome or workaround it.
Because it might not be completely erased due to power failure in the
middle of an erase. You get random bit flips if that happens.
You can avoid this by writing clean markers in every empty block when you
install it, a bit messy though and it won't solve the general problem: Try
removing a few big files and then reboot, you will have to wait then too.
If you don't use JFFS2 as a module and unload it, you can my old patch which will
solve both problems.
Jocke
>
> Thank you so much, Jocke
> BRs, H. Johnny
>
> > I guess this is the first reboot after mounting a new JFFS2 FS?
> > Then JFFS2 is reerasing empty blocks and you will have to wait
> > until it is done.
> >
> > I posted a patch long ago for this, but it was racy w.r.t JFSS2 module unload so
> > it didn't make it into the repo. Search the list for
> > "[JFFS2] Stop erasing blocks when rebooting." to find my old patch
> >
> > Jocke
> >
> >
>
^ permalink raw reply
* Re: jffs2_gcd_mtdx thread and umount problem.
From: Johnny Hung @ 2010-01-18 8:26 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linux-embedded, linux-mtd, linuxppc-dev
In-Reply-To: <OF593A1F75.3C3C7D18-ONC12576AF.002B1239-C12576AF.002BB30A@transmode.se>
Yes, umount / reboot command doesn't hang after first boot + wait for
20 minutes. The jffs2_gcd_mtdx will re-erase empty blocks but how do I
know it is finished?
BTW, why jffs2_gcd_mtd need to re-erase empty blocks and it will cause
some command cannot work if erase block is necessary. I mean many
pepple could meet this problem if it is need to erase empty block and
how do they overcome or workaround it.
Thank you so much, Jocke
BRs, H. Johnny
> I guess this is the first reboot after mounting a new JFFS2 FS?
> Then JFFS2 is reerasing empty blocks and you will have to wait
> until it is done.
>
> I posted a patch long ago for this, but it was racy w.r.t JFSS2 module unload so
> it didn't make it into the repo. Search the list for
> "[JFFS2] Stop erasing blocks when rebooting." to find my old patch
>
> Jocke
>
>
^ permalink raw reply
* Re: jffs2_gcd_mtdx thread and umount problem.
From: Joakim Tjernlund @ 2010-01-18 7:57 UTC (permalink / raw)
To: Johnny Hung; +Cc: linuxppc-dev, linux-mtd, linux-embedded
In-Reply-To: <cb9ecdfa1001172304q132d5324qa963d0d5cdfb7806@mail.gmail.com>
>
> Hi All,
>
> I have a customized MPC8313 (ppc arch) board with SPANSION 64MB NOR
> flash, everything works fine but I found a abnormal about JFFS2 flahs
> filesystem.
>
> The system will mount JFFS2 to /mnt/mtd when system boot up. I try to
> execute umount /mnt/mtd or sync or reboot right away after login then
> these commands hangs. Use ps command to check process status and is D
> (Uninterruptible sleep, usually IO). I try to kill jffs2_gcd_mtd4 and
> umount/reboot/syc commands execute successfully. I think
> jffs2_gcd_mtd4 (mount /dev/mtd4) do something in the background so I
> wait for 10 minutes after login and execute the same commands and it
> doesn't hangs.
>
> The following procedure is I to make jffs2 file system and write to
> flash then mount to /mnt/mtd.
>
> 1. mkfs.jffs2 -d mtd -e 0x20000 --pad 0x3080000 -o mtd.jffs2 (erase
> block size is 128KB and jffs2 partition size is 48.5MB)
>
> 2. write jffs2 file system to flash in uboot.
> tftpboot 200000 mtd.jffs2; (load mtd.jffs2 to memory)
> protect off f8f80000 fbffffff;
> erase f8f80000 fbffffff; (erase all 48.5MB)
> cp.b 200000 f8f80000 $filesize; (program mtd.jffs2 to flash)
> protect on f8f80000 fbffffff;
> cmp.b 200000 f8f80000 $filesize
>
> 3. Add below in /etc/fstab file to mount to /mnt/mtd
> /dev/mtdblock4 /mnt/mtd jffs2 defaults 1 1
>
> Does anyone knows what purpose for jffs2_gcd_mtdx thread and why it
> cause umount/sync/reboot commands hangs it is reasonable or something
> I did wrong?
I guess this is the first reboot after mounting a new JFFS2 FS?
Then JFFS2 is reerasing empty blocks and you will have to wait
until it is done.
I posted a patch long ago for this, but it was racy w.r.t JFSS2 module unload so
it didn't make it into the repo. Search the list for
"[JFFS2] Stop erasing blocks when rebooting." to find my old patch
Jocke
^ permalink raw reply
* jffs2_gcd_mtdx thread and umount problem.
From: Johnny Hung @ 2010-01-18 7:04 UTC (permalink / raw)
To: linux-embedded, linuxppc-dev, linux-mtd
Hi All,
I have a customized MPC8313 (ppc arch) board with SPANSION 64MB NOR
flash, everything works fine but I found a abnormal about JFFS2 flahs
filesystem.
The system will mount JFFS2 to /mnt/mtd when system boot up. I try to
execute umount /mnt/mtd or sync or reboot right away after login then
these commands hangs. Use ps command to check process status and is D
(Uninterruptible sleep, usually IO). I try to kill jffs2_gcd_mtd4 and
umount/reboot/syc commands execute successfully. I think
jffs2_gcd_mtd4 (mount /dev/mtd4) do something in the background so I
wait for 10 minutes after login and execute the same commands and it
doesn't hangs.
The following procedure is I to make jffs2 file system and write to
flash then mount to /mnt/mtd.
1. mkfs.jffs2 -d mtd -e 0x20000 --pad 0x3080000 -o mtd.jffs2 (erase
block size is 128KB and jffs2 partition size is 48.5MB)
2. write jffs2 file system to flash in uboot.
tftpboot 200000 mtd.jffs2; (load mtd.jffs2 to memory)
protect off f8f80000 fbffffff;
erase f8f80000 fbffffff; (erase all 48.5MB)
cp.b 200000 f8f80000 $filesize; (program mtd.jffs2 to flash)
protect on f8f80000 fbffffff;
cmp.b 200000 f8f80000 $filesize
3. Add below in /etc/fstab file to mount to /mnt/mtd
/dev/mtdblock4 /mnt/mtd jffs2 defaults 1 1
Does anyone knows what purpose for jffs2_gcd_mtdx thread and why it
cause umount/sync/reboot commands hangs it is reasonable or something
I did wrong?
BRs, H. Johnny
^ permalink raw reply
* Re: flash_platform_data namespace collision
From: David Brownell @ 2010-01-16 19:23 UTC (permalink / raw)
To: Matt Mackall
Cc: Russell King, David Woodhouse, Linux Mailing List, linux-embedded
In-Reply-To: <1263664079.29868.6289.camel@calx>
On Saturday 16 January 2010, Matt Mackall wrote:
> On Sat, 2010-01-16 at 11:04 +0000, Russell King wrote:
> > On Fri, Jan 15, 2010 at 11:41:15PM -0600, Matt Mackall wrote:
> > > I've got a board here with SPI, NOR, and NAND flash devices and I've
> > > just run into a namespace collision on flash_platform_data from
> >
> > The one in arch/arm/include/asm/mach/flash.h is designed to have great
> > appeal and flexibility across different platforms, and indeed we have
> > at least 70 users across six different MTD NOR flash drivers and two
> > MTD NAND drivers.
Yet it doesn't do what's needed for SPI flash (identify the chip type,
when it can't probed); and for that application none of those methods
are useful (and their slots are just wasted/confusing space).
> > If anything, I believe that this header should move into linux/mtd/
> > and become a standard structure for platforms to communicate their
> > requirements to flash drivers.
>
> Yeah, I think this is probably the way to go. Davids, any objections?
I had similar thoughts when I first happened across that structure.
But such a move wouldn't resolve $SUBJECT ... which is IMO best addressed
by the obvious rename of the one to spi_flash_platform_data.
- dave
^ permalink raw reply
* Re: flash_platform_data namespace collision
From: Matt Mackall @ 2010-01-16 17:47 UTC (permalink / raw)
To: Russell King
Cc: David Brownell, David Woodhouse, Linux Mailing List,
linux-embedded
In-Reply-To: <20100116110420.GB31282@flint.arm.linux.org.uk>
On Sat, 2010-01-16 at 11:04 +0000, Russell King wrote:
> On Fri, Jan 15, 2010 at 11:41:15PM -0600, Matt Mackall wrote:
> > I've got a board here with SPI, NOR, and NAND flash devices and I've
> > just run into a namespace collision on flash_platform_data from
>
> The one in arch/arm/include/asm/mach/flash.h is designed to have great
> appeal and flexibility across different platforms, and indeed we have
> at least 70 users across six different MTD NOR flash drivers and two
> MTD NAND drivers.
>
> If anything, I believe that this header should move into linux/mtd/
> and become a standard structure for platforms to communicate their
> requirements to flash drivers.
Yeah, I think this is probably the way to go. Davids, any objections?
--
http://selenic.com : development and support for Mercurial and Linux
^ permalink raw reply
* Re: flash_platform_data namespace collision
From: Russell King @ 2010-01-16 11:04 UTC (permalink / raw)
To: Matt Mackall
Cc: David Brownell, David Woodhouse, Linux Mailing List,
linux-embedded
In-Reply-To: <1263620475.29868.6280.camel@calx>
On Fri, Jan 15, 2010 at 11:41:15PM -0600, Matt Mackall wrote:
> I've got a board here with SPI, NOR, and NAND flash devices and I've
> just run into a namespace collision on flash_platform_data from
The one in arch/arm/include/asm/mach/flash.h is designed to have great
appeal and flexibility across different platforms, and indeed we have
at least 70 users across six different MTD NOR flash drivers and two
MTD NAND drivers.
If anything, I believe that this header should move into linux/mtd/
and become a standard structure for platforms to communicate their
requirements to flash drivers.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: flash_platform_data namespace collision
From: David Brownell @ 2010-01-16 6:03 UTC (permalink / raw)
To: Matt Mackall
Cc: Russell King, David Woodhouse, Linux Mailing List, linux-embedded
In-Reply-To: <1263620475.29868.6280.camel@calx>
On Friday 15 January 2010, Matt Mackall wrote:
> I've got a board here with SPI, NOR, and NAND flash devices and I've
> just run into a namespace collision on flash_platform_data from
>
> include/spi/flash.h
>
> and
>
> arch/arm/include/asm/mach/flash.h
>
> And each appears to have a bunch of users.
ISTR someone noting that before but omitting a patch.
You can do that one better. :)
I think changing the SPI flash name will affect fewer platforms.
- Dave
^ permalink raw reply
* flash_platform_data namespace collision
From: Matt Mackall @ 2010-01-16 5:41 UTC (permalink / raw)
To: David Brownell, Russell King, David Woodhouse
Cc: Linux Mailing List, linux-embedded
I've got a board here with SPI, NOR, and NAND flash devices and I've
just run into a namespace collision on flash_platform_data from
include/spi/flash.h
and
arch/arm/include/asm/mach/flash.h
And each appears to have a bunch of users.
--
http://selenic.com : development and support for Mercurial and Linux
^ permalink raw reply
* [PATCH] modpost: Support objects with more than 64k sections
From: Denys Vlasenko @ 2010-01-15 4:50 UTC (permalink / raw)
To: Linus Torvalds
Cc: Tim Bird, linux-embedded, linux-kernel, Tim Abbott,
Anders Kaseorg, Waseem Daher, Rusty Russell, Andi Kleen,
Stephen Rothwell, H. Peter Anvin
In order to help a bit with future merge of -ffunction-sections
work, I am resending a self-contained prerequisiste:
fix for "modpost + more than 64000 sections" situation.
This patch makes modpost able to process object files with more than
64k sections. Needed for huge kernel builds (allyesconfig, for example)
with -ffunction-sections.
Rediffed against 2.6.33-rc4-next-20100114, placated checkpatch.pl
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
[andersk@mit.edu: updated for 2.6.29]
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
diff -d -urpN linux-2.6.33-rc4-next-20100114.org/scripts/mod/file2alias.c linux-2.6.33-rc4-next-20100114/scripts/mod/file2alias.c
--- linux-2.6.33-rc4-next-20100114.org/scripts/mod/file2alias.c 2010-01-13 06:15:00.000000000 +0100
+++ linux-2.6.33-rc4-next-20100114/scripts/mod/file2alias.c 2010-01-15 04:23:21.000000000 +0100
@@ -839,16 +839,16 @@ void handle_moddevtable(struct module *m
char *zeros = NULL;
/* We're looking for a section relative symbol */
- if (!sym->st_shndx || sym->st_shndx >= info->hdr->e_shnum)
+ if (!sym->st_shndx || get_secindex(info, sym) >= info->num_sections)
return;
/* Handle all-NULL symbols allocated into .bss */
- if (info->sechdrs[sym->st_shndx].sh_type & SHT_NOBITS) {
+ if (info->sechdrs[get_secindex(info, sym)].sh_type & SHT_NOBITS) {
zeros = calloc(1, sym->st_size);
symval = zeros;
} else {
symval = (void *)info->hdr
- + info->sechdrs[sym->st_shndx].sh_offset
+ + info->sechdrs[get_secindex(info, sym)].sh_offset
+ sym->st_value;
}
diff -d -urpN linux-2.6.33-rc4-next-20100114.org/scripts/mod/modpost.c linux-2.6.33-rc4-next-20100114/scripts/mod/modpost.c
--- linux-2.6.33-rc4-next-20100114.org/scripts/mod/modpost.c 2010-01-13 06:15:00.000000000 +0100
+++ linux-2.6.33-rc4-next-20100114/scripts/mod/modpost.c 2010-01-15 05:25:12.000000000 +0100
@@ -253,7 +253,7 @@ static enum export export_no(const char
return export_unknown;
}
-static enum export export_from_sec(struct elf_info *elf, Elf_Section sec)
+static enum export export_from_sec(struct elf_info *elf, unsigned int sec)
{
if (sec == elf->export_sec)
return export_plain;
@@ -373,6 +373,8 @@ static int parse_elf(struct elf_info *in
Elf_Ehdr *hdr;
Elf_Shdr *sechdrs;
Elf_Sym *sym;
+ const char *secstrings;
+ unsigned int symtab_idx = ~0U, symtab_shndx_idx = ~0U;
hdr = grab_file(filename, &info->size);
if (!hdr) {
@@ -417,8 +419,19 @@ static int parse_elf(struct elf_info *in
return 0;
}
+ /* Fixup for more than 64k sections */
+ info->num_sections = hdr->e_shnum;
+ if (info->num_sections == 0) { /* more than 64k sections? */
+ /* note: it doesn't need shndx2secindex() */
+ info->num_sections = TO_NATIVE(sechdrs[0].sh_size);
+ }
+ info->secindex_strings = hdr->e_shstrndx;
+ if (info->secindex_strings == SHN_XINDEX)
+ info->secindex_strings =
+ shndx2secindex(TO_NATIVE(sechdrs[0].sh_link));
+
/* Fix endianness in section headers */
- for (i = 0; i < hdr->e_shnum; i++) {
+ for (i = 0; i < info->num_sections; i++) {
sechdrs[i].sh_name = TO_NATIVE(sechdrs[i].sh_name);
sechdrs[i].sh_type = TO_NATIVE(sechdrs[i].sh_type);
sechdrs[i].sh_flags = TO_NATIVE(sechdrs[i].sh_flags);
@@ -431,9 +444,8 @@ static int parse_elf(struct elf_info *in
sechdrs[i].sh_entsize = TO_NATIVE(sechdrs[i].sh_entsize);
}
/* Find symbol table. */
- for (i = 1; i < hdr->e_shnum; i++) {
- const char *secstrings
- = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
+ secstrings = (void *)hdr + sechdrs[info->secindex_strings].sh_offset;
+ for (i = 1; i < info->num_sections; i++) {
const char *secname;
int nobits = sechdrs[i].sh_type == SHT_NOBITS;
@@ -461,14 +473,26 @@ static int parse_elf(struct elf_info *in
else if (strcmp(secname, "__ksymtab_gpl_future") == 0)
info->export_gpl_future_sec = i;
- if (sechdrs[i].sh_type != SHT_SYMTAB)
- continue;
+ if (sechdrs[i].sh_type == SHT_SYMTAB) {
+ unsigned int sh_link_idx;
+ symtab_idx = i;
+ info->symtab_start = (void *)hdr +
+ sechdrs[i].sh_offset;
+ info->symtab_stop = (void *)hdr +
+ sechdrs[i].sh_offset + sechdrs[i].sh_size;
+ sh_link_idx = shndx2secindex(sechdrs[i].sh_link);
+ info->strtab = (void *)hdr +
+ sechdrs[sh_link_idx].sh_offset;
+ }
- info->symtab_start = (void *)hdr + sechdrs[i].sh_offset;
- info->symtab_stop = (void *)hdr + sechdrs[i].sh_offset
- + sechdrs[i].sh_size;
- info->strtab = (void *)hdr +
- sechdrs[sechdrs[i].sh_link].sh_offset;
+ /* 32bit section no. table? ("more than 64k sections") */
+ if (sechdrs[i].sh_type == SHT_SYMTAB_SHNDX) {
+ symtab_shndx_idx = i;
+ info->symtab_shndx_start = (void *)hdr +
+ sechdrs[i].sh_offset;
+ info->symtab_shndx_stop = (void *)hdr +
+ sechdrs[i].sh_offset + sechdrs[i].sh_size;
+ }
}
if (!info->symtab_start)
fatal("%s has no symtab?\n", filename);
@@ -480,6 +504,21 @@ static int parse_elf(struct elf_info *in
sym->st_value = TO_NATIVE(sym->st_value);
sym->st_size = TO_NATIVE(sym->st_size);
}
+
+ if (symtab_shndx_idx != ~0U) {
+ Elf32_Word *p;
+ if (symtab_idx !=
+ shndx2secindex(sechdrs[symtab_shndx_idx].sh_link))
+ fatal("%s: SYMTAB_SHNDX has bad sh_link: %u!=%u\n",
+ filename,
+ shndx2secindex(sechdrs[symtab_shndx_idx].sh_link),
+ symtab_idx);
+ /* Fix endianness */
+ for (p = info->symtab_shndx_start; p < info->symtab_shndx_stop;
+ p++)
+ *p = TO_NATIVE(*p);
+ }
+
return 1;
}
@@ -514,7 +553,7 @@ static void handle_modversions(struct mo
Elf_Sym *sym, const char *symname)
{
unsigned int crc;
- enum export export = export_from_sec(info, sym->st_shndx);
+ enum export export = export_from_sec(info, get_secindex(info, sym));
switch (sym->st_shndx) {
case SHN_COMMON:
@@ -656,19 +695,19 @@ static const char *sym_name(struct elf_i
return "(unknown)";
}
-static const char *sec_name(struct elf_info *elf, int shndx)
+static const char *sec_name(struct elf_info *elf, int secindex)
{
Elf_Shdr *sechdrs = elf->sechdrs;
return (void *)elf->hdr +
- elf->sechdrs[elf->hdr->e_shstrndx].sh_offset +
- sechdrs[shndx].sh_name;
+ elf->sechdrs[elf->secindex_strings].sh_offset +
+ sechdrs[secindex].sh_name;
}
static const char *sech_name(struct elf_info *elf, Elf_Shdr *sechdr)
{
return (void *)elf->hdr +
- elf->sechdrs[elf->hdr->e_shstrndx].sh_offset +
- sechdr->sh_name;
+ elf->sechdrs[elf->secindex_strings].sh_offset +
+ sechdr->sh_name;
}
/* if sym is empty or point to a string
@@ -1023,11 +1062,14 @@ static Elf_Sym *find_elf_symbol(struct e
Elf_Sym *near = NULL;
Elf64_Sword distance = 20;
Elf64_Sword d;
+ unsigned int relsym_secindex;
if (relsym->st_name != 0)
return relsym;
+
+ relsym_secindex = get_secindex(elf, relsym);
for (sym = elf->symtab_start; sym < elf->symtab_stop; sym++) {
- if (sym->st_shndx != relsym->st_shndx)
+ if (get_secindex(elf, sym) != relsym_secindex)
continue;
if (ELF_ST_TYPE(sym->st_info) == STT_SECTION)
continue;
@@ -1089,9 +1131,9 @@ static Elf_Sym *find_elf_symbol2(struct
for (sym = elf->symtab_start; sym < elf->symtab_stop; sym++) {
const char *symsec;
- if (sym->st_shndx >= SHN_LORESERVE)
+ if (is_shndx_special(sym->st_shndx))
continue;
- symsec = sec_name(elf, sym->st_shndx);
+ symsec = sec_name(elf, get_secindex(elf, sym));
if (strcmp(symsec, sec) != 0)
continue;
if (!is_valid_name(elf, sym))
@@ -1288,7 +1330,7 @@ static void check_section_mismatch(const
const char *tosec;
enum mismatch mismatch;
- tosec = sec_name(elf, sym->st_shndx);
+ tosec = sec_name(elf, get_secindex(elf, sym));
mismatch = section_mismatch(fromsec, tosec);
if (mismatch != NO_MISMATCH) {
Elf_Sym *to;
@@ -1315,7 +1357,7 @@ static unsigned int *reloc_location(stru
Elf_Shdr *sechdr, Elf_Rela *r)
{
Elf_Shdr *sechdrs = elf->sechdrs;
- int section = sechdr->sh_info;
+ int section = shndx2secindex(sechdr->sh_info);
return (void *)elf->hdr + sechdrs[section].sh_offset +
(r->r_offset - sechdrs[section].sh_addr);
@@ -1423,7 +1465,7 @@ static void section_rela(const char *mod
r.r_addend = TO_NATIVE(rela->r_addend);
sym = elf->symtab_start + r_sym;
/* Skip special sections */
- if (sym->st_shndx >= SHN_LORESERVE)
+ if (is_shndx_special(sym->st_shndx))
continue;
check_section_mismatch(modname, elf, &r, sym, fromsec);
}
@@ -1481,7 +1523,7 @@ static void section_rel(const char *modn
}
sym = elf->symtab_start + r_sym;
/* Skip special sections */
- if (sym->st_shndx >= SHN_LORESERVE)
+ if (is_shndx_special(sym->st_shndx))
continue;
check_section_mismatch(modname, elf, &r, sym, fromsec);
}
@@ -1506,7 +1548,7 @@ static void check_sec_ref(struct module
Elf_Shdr *sechdrs = elf->sechdrs;
/* Walk through all sections */
- for (i = 0; i < elf->hdr->e_shnum; i++) {
+ for (i = 0; i < elf->num_sections; i++) {
check_section(modname, elf, &elf->sechdrs[i]);
/* We want to process only relocation sections and not .init */
if (sechdrs[i].sh_type == SHT_RELA)
diff -d -urpN linux-2.6.33-rc4-next-20100114.org/scripts/mod/modpost.h linux-2.6.33-rc4-next-20100114/scripts/mod/modpost.h
--- linux-2.6.33-rc4-next-20100114.org/scripts/mod/modpost.h 2010-01-13 06:15:00.000000000 +0100
+++ linux-2.6.33-rc4-next-20100114/scripts/mod/modpost.h 2010-01-15 04:23:21.000000000 +0100
@@ -129,8 +129,51 @@ struct elf_info {
const char *strtab;
char *modinfo;
unsigned int modinfo_len;
+
+ /* support for 32bit section numbers */
+
+ unsigned int num_sections; /* max_secindex + 1 */
+ unsigned int secindex_strings;
+ /* if Nth symbol table entry has .st_shndx = SHN_XINDEX,
+ * take shndx from symtab_shndx_start[N] instead */
+ Elf32_Word *symtab_shndx_start;
+ Elf32_Word *symtab_shndx_stop;
};
+static inline int is_shndx_special(unsigned int i)
+{
+ return i != SHN_XINDEX && i >= SHN_LORESERVE && i <= SHN_HIRESERVE;
+}
+
+/* shndx is in [0..SHN_LORESERVE) U (SHN_HIRESERVE, 0xfffffff], thus:
+ * shndx == 0 <=> sechdrs[0]
+ * ......
+ * shndx == SHN_LORESERVE-1 <=> sechdrs[SHN_LORESERVE-1]
+ * shndx == SHN_HIRESERVE+1 <=> sechdrs[SHN_LORESERVE]
+ * shndx == SHN_HIRESERVE+2 <=> sechdrs[SHN_LORESERVE+1]
+ * ......
+ * fyi: sym->st_shndx is uint16, SHN_LORESERVE = ff00, SHN_HIRESERVE = ffff,
+ * so basically we map 0000..feff -> 0000..feff
+ * ff00..ffff -> (you are a bad boy, dont do it)
+ * 10000..xxxx -> ff00..(xxxx-0x100)
+ */
+static inline unsigned int shndx2secindex(unsigned int i)
+{
+ if (i <= SHN_HIRESERVE)
+ return i;
+ return i - (SHN_HIRESERVE + 1 - SHN_LORESERVE);
+}
+
+/* Accessor for sym->st_shndx, hides ugliness of "64k sections" */
+static inline unsigned int get_secindex(const struct elf_info *info,
+ const Elf_Sym *sym)
+{
+ if (sym->st_shndx != SHN_XINDEX)
+ return sym->st_shndx;
+ return shndx2secindex(info->symtab_shndx_start[sym -
+ info->symtab_start]);
+}
+
/* file2alias.c */
extern unsigned int cross_build;
void handle_moddevtable(struct module *mod, struct elf_info *info,
^ permalink raw reply
* Re: [PATCH V2 6/8] lzma: Make lzma ... thunderbird ok
From: Marco Stornelli @ 2010-01-07 17:26 UTC (permalink / raw)
To: Hein_Tibosch; +Cc: Phillip Lougher, linux-embedded
In-Reply-To: <4B4590B8.80604@yahoo.es>
Il 07/01/2010 08:43, Hein_Tibosch ha scritto:
> On 7-1-2010 08:37, Phillip Lougher wrote:
>> Sorry, I was worried it might do that - the curse of Thunderbird. I
>> normally use a
>> really dumb client like mailx to send patches, but I obviously didn't have the
>> email thread under mailx to do that.
>>
> Thunderbird: not a real curse for patches. Try the following:
>
> Tools -> Options -> Advanced -> General -> Config Editor
>
> mailnews.send_plaintext_flowed user boolean false
> mailnews.display.disable_flowed_support user boolean true
> mailnews.wraplength user integer 512
>
> And see this patch below:
>
> ---
> diff --git a/thunderbird b/thunderbird
> +++
> ---
> if (using_thunderbird) {
> you can send patches safely
> }
> ---
>
> Hein
>
And with pasteCode and Toggle Word Wrap extensions it is even more easier ;)
Marco
^ permalink raw reply
* Re: [PATCH V2 6/8] lzma: Make lzma ... thunderbird ok
From: Hein_Tibosch @ 2010-01-07 7:43 UTC (permalink / raw)
To: Phillip Lougher; +Cc: linux-embedded
In-Reply-To: <bffbecbb1001061637i31260775ja14523458cc1ed51@mail.gmail.com>
On 7-1-2010 08:37, Phillip Lougher wrote:
> Sorry, I was worried it might do that - the curse of Thunderbird. I
> normally use a
> really dumb client like mailx to send patches, but I obviously didn't have the
> email thread under mailx to do that.
>
Thunderbird: not a real curse for patches. Try the following:
Tools -> Options -> Advanced -> General -> Config Editor
mailnews.send_plaintext_flowed user boolean false
mailnews.display.disable_flowed_support user boolean true
mailnews.wraplength user integer 512
And see this patch below:
---
diff --git a/thunderbird b/thunderbird
+++
---
if (using_thunderbird) {
you can send patches safely
}
---
Hein
^ permalink raw reply
* [PATCH V2 6/8] lzma: Make lzma available to non initramfs/initrd code
From: Phillip Lougher @ 2010-01-07 0:49 UTC (permalink / raw)
To: albin.tonnerre, sfr, linux-kernel, linux-fsdevel, linux-embedded,
akpm
Fix up patch resend using a nice and dumb email client.
If I'm lucky, email readers may even get the threading right :-)
Phillip
From 1cf6d32e1427398368ff189aece68aa533092e98 Mon Sep 17 00:00:00 2001
From: Phillip Lougher <phillip@lougher.demon.co.uk>
Date: Wed, 6 Jan 2010 23:50:12 +0000
Subject: [PATCH] lzo: Fix-up add support for lzo compressed kernels patch
The add support for lzo compressed kernels patch relies on
INIT and error definitions which have been moved to
separate xxx_mm.h files for each decompressor.
This patch adds a unlzo_mm.h file which supplies these
definitions.
Signed-off-by: Phillip Lougher <phillip@lougher.demon.co.uk>
---
include/linux/decompress/unlzo_mm.h | 13 +++++++++++++
lib/decompress_unlzo.c | 1 +
2 files changed, 14 insertions(+), 0 deletions(-)
create mode 100644 include/linux/decompress/unlzo_mm.h
diff --git a/include/linux/decompress/unlzo_mm.h b/include/linux/decompress/unlzo_mm.h
new file mode 100644
index 0000000..27fe0ab
--- /dev/null
+++ b/include/linux/decompress/unlzo_mm.h
@@ -0,0 +1,13 @@
+#ifndef UNLZO_MM_H
+#define UNLZO_MM_H
+
+#ifdef STATIC
+/* Code active when included from pre-boot environment: */
+#define INIT
+#else
+/* Compile for initramfs/initrd code only */
+#define INIT __init
+static void(*error)(char *m);
+#endif
+
+#endif
diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c
index db521f4..edd82c3 100644
--- a/lib/decompress_unlzo.c
+++ b/lib/decompress_unlzo.c
@@ -39,6 +39,7 @@
#include <linux/types.h>
#include <linux/lzo.h>
+#include <linux/decompress/unlzo_mm.h>
#include <linux/decompress/mm.h>
#include <linux/compiler.h>
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH V2 6/8] lzma: Make lzma available to non initramfs/initrd code
From: Phillip Lougher @ 2010-01-07 0:37 UTC (permalink / raw)
To: Andrew Morton
Cc: Phillip Lougher, linux-embedded, linux-fsdevel, linux-kernel,
tim.bird, Stephen Rothwell, Albin Tonnerre
In-Reply-To: <20100106163113.637e47db.akpm@linux-foundation.org>
On Thu, Jan 7, 2010 at 12:31 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> Your email client is doing space-stuffing.
>
Sorry, I was worried it might do that - the curse of Thunderbird. I
normally use a
really dumb client like mailx to send patches, but I obviously didn't have the
email thread under mailx to do that.
If you want, I can resend the patch using my favourite dumb client.
Phillip
^ permalink raw reply
* Re: [PATCH V2 6/8] lzma: Make lzma available to non initramfs/initrd code
From: Andrew Morton @ 2010-01-07 0:31 UTC (permalink / raw)
To: Phillip Lougher
Cc: linux-embedded, linux-fsdevel, linux-kernel, phillip.lougher,
tim.bird, Stephen Rothwell, Albin Tonnerre
In-Reply-To: <4B4528C8.3020603@lougher.demon.co.uk>
On Thu, 07 Jan 2010 00:20:24 +0000
Phillip Lougher <phillip@lougher.demon.co.uk> wrote:
> Andrew Morton wrote:
>
> > So what to do? I guess I could go ahead with the mainline merge, and
> > Stephen drops <whatever that tree was> from linux-next until it has
> > been fixed up?
> >
>
> Yes, I'm happy with that. The following patch is the necessary fix
> that needs to go into linux-next when you've gone ahead with the
> mainline merge of the lib-add-support-for-lzo-compressed-kernels.patch.
ooh, goody, thanks.
> diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c
> index db521f4..edd82c3 100644
> --- a/lib/decompress_unlzo.c
> +++ b/lib/decompress_unlzo.c
> @@ -39,6 +39,7 @@
>
> #include <linux/types.h>
> #include <linux/lzo.h>
> +#include <linux/decompress/unlzo_mm.h>
> #include <linux/decompress/mm.h>
>
> #include <linux/compiler.h>
Your email client is doing space-stuffing.
^ permalink raw reply
* Re: [PATCH V2 6/8] lzma: Make lzma available to non initramfs/initrd code
From: Phillip Lougher @ 2010-01-07 0:20 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-embedded, linux-fsdevel, linux-kernel, phillip.lougher,
tim.bird, Stephen Rothwell, Albin Tonnerre
In-Reply-To: <20100106140409.ba0f63d1.akpm@linux-foundation.org>
Andrew Morton wrote:
> So what to do? I guess I could go ahead with the mainline merge, and
> Stephen drops <whatever that tree was> from linux-next until it has
> been fixed up?
>
Yes, I'm happy with that. The following patch is the necessary fix
that needs to go into linux-next when you've gone ahead with the
mainline merge of the lib-add-support-for-lzo-compressed-kernels.patch.
Once I know the mainline merge has gone ahead, I can add this to
my linux-next tree.
Phillip
From 1cf6d32e1427398368ff189aece68aa533092e98 Mon Sep 17 00:00:00 2001
From: Phillip Lougher <phillip@lougher.demon.co.uk>
Date: Wed, 6 Jan 2010 23:50:12 +0000
Subject: [PATCH] lzo: Fix-up add support for lzo compressed kernels patch
The add support for lzo compressed kernels patch relies on
INIT and error definitions which have been moved to
separate xxx_mm.h files for each decompressor.
This patch adds a unlzo_mm.h file which supplies these
definitions.
Signed-off-by: Phillip Lougher <phillip@lougher.demon.co.uk>
---
include/linux/decompress/unlzo_mm.h | 13 +++++++++++++
lib/decompress_unlzo.c | 1 +
2 files changed, 14 insertions(+), 0 deletions(-)
create mode 100644 include/linux/decompress/unlzo_mm.h
diff --git a/include/linux/decompress/unlzo_mm.h b/include/linux/decompress/unlzo_mm.h
new file mode 100644
index 0000000..27fe0ab
--- /dev/null
+++ b/include/linux/decompress/unlzo_mm.h
@@ -0,0 +1,13 @@
+#ifndef UNLZO_MM_H
+#define UNLZO_MM_H
+
+#ifdef STATIC
+/* Code active when included from pre-boot environment: */
+#define INIT
+#else
+/* Compile for initramfs/initrd code only */
+#define INIT __init
+static void(*error)(char *m);
+#endif
+
+#endif
diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c
index db521f4..edd82c3 100644
--- a/lib/decompress_unlzo.c
+++ b/lib/decompress_unlzo.c
@@ -39,6 +39,7 @@
#include <linux/types.h>
#include <linux/lzo.h>
+#include <linux/decompress/unlzo_mm.h>
#include <linux/decompress/mm.h>
#include <linux/compiler.h>
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH V2 6/8] lzma: Make lzma available to non initramfs/initrd code
From: Stephen Rothwell @ 2010-01-07 0:04 UTC (permalink / raw)
To: Andrew Morton
Cc: Phillip Lougher, linux-embedded, linux-fsdevel, linux-kernel,
phillip.lougher, tim.bird, Albin Tonnerre
In-Reply-To: <20100106140409.ba0f63d1.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]
Hi Andrew,
On Wed, 6 Jan 2010 14:04:09 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> So if I go ahead with that merge, linux-next will need fixing. And I
> didn't get down and work what the appropriate fix is, and I don't want
> to break linux-next in serious ways.
Why not, everyone else does :-)
> So what to do? I guess I could go ahead with the mainline merge, and
> Stephen drops <whatever that tree was> from linux-next until it has
> been fixed up?
Just do the merge ... I will just need to drop the squashfs tree until
they do a merge/rebase with Linus' tree and fix it all up.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox