mizi support for jffs2

mizi support for jffs2

[Luca Contini]

Hi all,
I'm working on Samsung smdk2410 board using mizi linux (kernel 2.4.18).
Did anyone succeeded in modifying the kernel to support jffs2 instead of 
cramfs?

regards

Luca

-- 
Luca Contini
-------------------------------------------------------
Tecneitalia - AKHELA 
System Engineer
Office: (+39) 070 2466 5503
Mobile: (+39) 328 911 6656
Fax: (+39) 070 2466 7111
luca.contini@akhela.com
URL: http://www.akhela.com
--------------------------------------------------------

Re: mizi support for jffs2 - FAQ

[Thomas Gleixner]

On Tue, 2004-10-05 at 16:41, Luca Contini wrote:
> Hi all,
> I'm working on Samsung smdk2410 board using mizi linux (kernel 2.4.18).
> Did anyone succeeded in modifying the kernel to support jffs2 instead of 
> cramfs?

This starts to become a FAQ.

1. We don't know anything about MIZI Linux
2. 2.4.18 is a kernel from the last century and more than obsolete

Use an up to date and supported kernel.

tglx

Re: mizi support for jffs2 - FAQ

[Luca Contini]

I can't use un up to date kernel
thanks for your help

luca

----- Original Message ----- 
From: "Thomas Gleixner" <tglx@linutronix.de>
To: "Luca Contini" <luca.contini@akhela.com>
Cc: <linux-mtd@lists.infradead.org>
Sent: Tuesday, October 05, 2004 7:17 PM
Subject: Re: mizi support for jffs2 - FAQ


> On Tue, 2004-10-05 at 16:41, Luca Contini wrote:
> > Hi all,
> > I'm working on Samsung smdk2410 board using mizi linux (kernel 2.4.18).
> > Did anyone succeeded in modifying the kernel to support jffs2 instead of
> > cramfs?
>
> This starts to become a FAQ.
>
> 1. We don't know anything about MIZI Linux
> 2. 2.4.18 is a kernel from the last century and more than obsolete
>
> Use an up to date and supported kernel.
>
> tglx
>
>

Re: mizi support for jffs2 - FAQ

[jasmine]

> I can't use un up to date kernel

Why not?

-J.

Re: mizi support for jffs2 - FAQ

[Ben Dooks]

On Wed, Oct 06, 2004 at 10:10:11AM +0100, jasmine@linuxgrrls.org wrote:
> > I can't use un up to date kernel
> 
> Why not?

because no-one seems to be interested in maintaining the board
at the moment... I put base support in when I started sorting
2.6.x out, but as I have no SMDK2410 (and three other boards to
deal with for my work) I've not pursued anyone.

Oh, and to help matters, it seems the same board keeps turning
up with different names, and people keep registering it with
the linux/arm database....

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: mizi support for jffs2 - FAQ

[Thomas Gleixner]

On Wed, 2004-10-06 at 11:10, jasmine@linuxgrrls.org wrote:
> > I can't use un up to date kernel
> 
> Why not?

This answer is showing up repeadetly. There are various reasons:

1. I love the bugs and security holes in 2.4.18. This makes my job safe
and I can tinker for another couple of years.

2. It works and I'm not allowed to touch it, except for adding
functionality, because adding functionality is not disturbing the
working parts and we do not have to go through the whole test procedure
again. That's also known as the QA loophole.

3. Kernel versions are like red wine. Let them mature a couple of years
and you will be surprised how reliable they still work.

4. I have no time for porting to a new kernel version. I was told to
apply the XXX patch to the current one until tomorrow. It's your fault
that I will fail. So you are responsible. Hurry and safe my job. Send me
the backported patch.

5. This is the official kernel for this board which was supplied from my
vendor along with the nice click tools for my Windooze box to install
it. 

Seriously, not all of the above is fun and sarcasm. Sadly enough a lot
of it is reality.

But OTH this it not always the fault of the guy who is posting such
questions / requests. There are others to blame also.

1. Board vendors and semiconductor manufacturers. They provide crappy
and ugly kernel ports with random patched kernels which blow up at the
first ping -f. No way to update.

2. The sales guys who babble until the customer believes that the kernel
provided by (1) is the perfect solution.

3. Companies with self advertised "linux expertise" providing random
patched kernels, where you have a 8 Megabyte patch as a result of a diff
against the vanilla kernel it pretends to be forked of. No way to
update.

4. The sales guys who babble until the customer believes that the kernel
provided by (3) is the perfect solution.

Note, that (2) and (4) have different intentions. (2) want to sell chips
/ boards and dont care about the troubles. "Hey, you wanted a linux
kernel. You got one". (4) want to sell their dubious expertise in form
of more dubious support contracts or even use the linux bundle as an
entry to finally promote a proprietary solution which they have in their
portfolio too, when the customer fails with his linux project. "Hey, you
wanted linux. We always said use YYYY. But we could help you to fulfil
your project plan, if you use YYYY." Both want to lock in customers.

5. The managers who fall for the crap promoted by (1)-(4).

6. The managers who make themselve believe, that Linux is without costs.
They base project budgets and timelines on the erroneous assumption that
the community will fix all their problems for free within no time. 

7. The naivety of employees and their lack of courage to stand against
braindead management decisions. "He will kick my ass if I tell him that
the decision is braindead even if I can argue coherently" - Later - "He
is kicking my ass because I failed to tell him that I already new that
it is braindead before the decision was made." or "He is kicking my ass
because I'm failing to accomplish his braindead plan, but I must
succeed". 

In most of this cases there is a quick and dirty hack in the last minute
which rescues the ass and the loop starts over at (1)

That's my daily experience as a serious and contributing Linux
consultant / service provider. 

tglx

Re: mizi support for jffs2 - FAQ

[David Woodhouse]

On Thu, 2004-10-07 at 23:37 +0200, Thomas Gleixner wrote:
> But OTH this it not always the fault of the guy who is posting such
> questions / requests. There are others to blame also.
> 
> 1. Board vendors and semiconductor manufacturers. They provide crappy
> and ugly kernel ports with random patched kernels which blow up at the
> first ping -f. No way to update.

Invalid excuse. What muppet bought hardware for which there aren't real
GPL'd drivers which are actually merged (or at least mergeable). Clean
code doesn't stop working from version to version. It it ain't supported
or supportable, buy something else. Or make it supported. But don't come
crying to me.

> 2. The sales guys who babble until the customer believes that the kernel
> provided by (1) is the perfect solution.

Invalid excuse. If they're really that clueless it's fixable by taking a
newer kernel and just changing the numbers back. Long term solution is
to take a baseball bat to your sales team.

> 3. Companies with self advertised "linux expertise" providing random
> patched kernels, where you have a 8 Megabyte patch as a result of a diff
> against the vanilla kernel it pretends to be forked of. No way to
> update.

Invalid excuse. If anyone out there is really proud of giving money to
such muppets please contact me privately. I have a bridge you may be
interested in.

> 4. The sales guys who babble until the customer believes that the kernel
> provided by (3) is the perfect solution.

Fish. Didn't we do this one?

> Note, that (2) and (4) have different intentions. (2) want to sell chips
> / boards and dont care about the troubles. "Hey, you wanted a linux
> kernel. You got one". (4) want to sell their dubious expertise in form
> of more dubious support contracts or even use the linux bundle as an
> entry to finally promote a proprietary solution which they have in their
> portfolio too, when the customer fails with his linux project. "Hey, you
> wanted linux. We always said use YYYY. But we could help you to fulfil
> your project plan, if you use YYYY." Both want to lock in customers.
> 
> 5. The managers who fall for the crap promoted by (1)-(4).

Invalid excuse. The working relationship is wrong here. It is the duty
of the manager to protect the engineer from the horrid nasty customers
-- and it is the duty of the engineer to protect his manager from idiocy
like the above.

> 6. The managers who make themselve believe, that Linux is without costs.
> They base project budgets and timelines on the erroneous assumption that
> the community will fix all their problems for free within no time. 

Invalid excuse. And it's only going to make it worse if you try to cover
it up.

> 7. The naivety of employees and their lack of courage to stand against
> braindead management decisions. "He will kick my ass if I tell him that
> the decision is braindead even if I can argue coherently" - Later - "He
> is kicking my ass because I failed to tell him that I already new that
> it is braindead before the decision was made." or "He is kicking my ass
> because I'm failing to accomplish his braindead plan, but I must
> succeed". 

You only really have one option in this situation if you want to retain
long-term credibility. You just say 'no'.

It's very simple. These people come to you because you are supposed to
know best. If they were capable of making decisions and writing code for
themselves, you wouldn't be talking to them in the first place. 

So you either do it right, and build a reputation for being perhaps a
little bit forthright but generally useful, or you bodge together some
crap and continuously get associated with the kind of results that
achieves. Your call. 

Personally, I know which side I prefer to err on :)

> That's my daily experience as a serious and contributing Linux
> consultant / service provider. 

Amen :)

-- 
dwmw2