On 2.6.0-test5 jffs generates a warning about type mismatch because it casting a short
to a pointer. Look like an obvious typo.
Builds clean, not tested on real hardware.
diff -Nru a/fs/jffs/inode-v23.c b/fs/jffs/inode-v23.c
--- a/fs/jffs/inode-v23.c Tue Sep 9 14:41:53 2003
+++ b/fs/jffs/inode-v23.c Tue Sep 9 14:41:53 2003
@@ -1734,7 +1734,7 @@
the device should be read from the flash memory and then
added to the inode's i_rdev member. */
u16 val;
- jffs_read_data(f, (char *)val, 0, 2);
+ jffs_read_data(f, (char *)&val, 0, 2);
init_special_inode(inode, inode->i_mode,
old_decode_dev(val));
}
On Tue, Sep 09, 2003 at 02:44:20PM -0700, Stephen Hemminger wrote:
> On 2.6.0-test5 jffs generates a warning about type mismatch because it casting a short
> to a pointer. Look like an obvious typo.
Which it is. Thanks for spotting. Linux, please apply.
> Builds clean, not tested on real hardware.
>
> diff -Nru a/fs/jffs/inode-v23.c b/fs/jffs/inode-v23.c
> --- a/fs/jffs/inode-v23.c Tue Sep 9 14:41:53 2003
> +++ b/fs/jffs/inode-v23.c Tue Sep 9 14:41:53 2003
> @@ -1734,7 +1734,7 @@
> the device should be read from the flash memory and then
> added to the inode's i_rdev member. */
> u16 val;
> - jffs_read_data(f, (char *)val, 0, 2);
> + jffs_read_data(f, (char *)&val, 0, 2);
> init_special_inode(inode, inode->i_mode,
> old_decode_dev(val));
> }
On Wed, 10 Sep 2003 [email protected] wrote:
> On Tue, Sep 09, 2003 at 02:44:20PM -0700, Stephen Hemminger wrote:
> > On 2.6.0-test5 jffs generates a warning about type mismatch because it casting a short
> > to a pointer. Look like an obvious typo.
>
> Which it is. Thanks for spotting. Linux, please apply.
>
> > Builds clean, not tested on real hardware.
> >
> > diff -Nru a/fs/jffs/inode-v23.c b/fs/jffs/inode-v23.c
> > --- a/fs/jffs/inode-v23.c Tue Sep 9 14:41:53 2003
> > +++ b/fs/jffs/inode-v23.c Tue Sep 9 14:41:53 2003
> > @@ -1734,7 +1734,7 @@
> > the device should be read from the flash memory and then
> > added to the inode's i_rdev member. */
> > u16 val;
> > - jffs_read_data(f, (char *)val, 0, 2);
> > + jffs_read_data(f, (char *)&val, 0, 2);
> > init_special_inode(inode, inode->i_mode,
> > old_decode_dev(val));
> > }
Is this endian-safe?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Sep 10, 2003 at 07:14:37PM +0200, Geert Uytterhoeven wrote:
> Is this endian-safe?
JFFS is host-endian. If you want to make it swing both ways - feel free,
but AFAICS it's not worth the trouble.
On Wed, 10 Sep 2003 [email protected] wrote:
>
> JFFS is host-endian. If you want to make it swing both ways - feel free,
Please don't.
Dual-endianness is _evil_.
Admittedly host-endian is stupid too, but it's less stupid than being
dual.
The only sane thing to do is fixed-endianness. I'm sure the m68k people
remember being forced to fix their ext2 partitions back in the bad old
days. It's painful once, but after that, fixed-endian is a lot more
efficient and much simpler to handle.
Linus
On Wed, Sep 10, 2003 at 11:54:13AM -0700, Linus Torvalds wrote:
>
> On Wed, 10 Sep 2003 [email protected] wrote:
> >
> > JFFS is host-endian. If you want to make it swing both ways - feel free,
>
> Please don't.
>
> Dual-endianness is _evil_.
>
> Admittedly host-endian is stupid too, but it's less stupid than being
> dual.
>
> The only sane thing to do is fixed-endianness. I'm sure the m68k people
> remember being forced to fix their ext2 partitions back in the bad old
> days. It's painful once, but after that, fixed-endian is a lot more
> efficient and much simpler to handle.
a) you've snipped the critical part ;-)
b) nobody sane uses that beast these days
c) if somebody wants to grow a private patch - it's their time,
after all...
Seriously, though, by now fs/jffs/* has only one real use - extracting
data from old filesystem. IIRC, there was even a talk about having it go
the way of ext and xiafs. He's dead, Jim...
On Wed, Sep 10, 2003 at 08:03:04PM +0100, [email protected] wrote:
>
> a) you've snipped the critical part ;-)
> b) nobody sane uses that beast these days
> c) if somebody wants to grow a private patch - it's their time,
> after all...
>
> Seriously, though, by now fs/jffs/* has only one real use - extracting
> data from old filesystem. IIRC, there was even a talk about having it go
> the way of ext and xiafs. He's dead, Jim...
It isn't that dead - I get the occasional patch from people wanting to keep
it working, although I really wish people would send them to dwmw2 rather
than myself.
--
Russell King ([email protected]) http://www.arm.linux.org.uk/personal/
Linux kernel maintainer of:
2.6 ARM Linux - http://www.arm.linux.org.uk/
2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Wed, 10 September 2003 20:16:07 +0100, Russell King wrote:
> On Wed, Sep 10, 2003 at 08:03:04PM +0100, [email protected] wrote:
> >
> > Seriously, though, by now fs/jffs/* has only one real use - extracting
> > data from old filesystem. IIRC, there was even a talk about having it go
> > the way of ext and xiafs. He's dead, Jim...
>
> It isn't that dead - I get the occasional patch from people wanting to keep
> it working, although I really wish people would send them to dwmw2 rather
> than myself.
Yes, it still beats jffs2 in cases where people have <=5 flash blocks
and want a r/w filesystem on them. Until David, myself or someone
else finds the time to improve jffs2 for corner cases like this, jffs
has a use - sadly.
J?rn
--
When you close your hand, you own nothing. When you open it up, you
own the whole world.
-- Li Mu Bai in Tiger & Dragon