mizi support for jffs2
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
Signature · 9 lines
Luca Contini ------------------------------------------------------- Tecneitalia - AKHELA System Engineer Office: (+39) 070 2466 5503 Mobile: (+39) 328 911 6656 Fax: (+39) 070 2466 7111 [email protected] URL: http://www.akhela.com --------------------------------------------------------
Re: mizi support for jffs2 - FAQ
Quoted 4 lines · 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?
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
I can't use un up to date kernel thanks for your help
luca
----- Original Message -----
From: "Thomas Gleixner" <[email protected]>
To: "Luca Contini" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, October 05, 2004 7:17 PM
Subject: Re: mizi support for jffs2 - FAQ
Quoted 16 lines · Luca Contini
Quoted 4 lines
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 obsoleteUse an up to date and supported kernel.
tglx
Re: mizi support for jffs2 - FAQ
Quoted 1 line
I can't use un up to date kernel
Why not?
-J.
Re: mizi support for jffs2 - FAQ
Quoted 3 lines · On Wed, Oct 06, 2004 at 10:10:11AM +0100, [email protected] wrote:
Quoted 1 line
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....
Signature · 3 lines
Ben ([email protected], http://www.fluff.org/) 'a smiley only costs 4 bytes'
Re: mizi support for jffs2 - FAQ
In reply to [email protected]Quoted 3 lines · On Wed, 2004-10-06 at 11:10, [email protected] wrote:
Quoted 1 line
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
Quoted 6 lines · Thomas Gleixner
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.
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 2 lines
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?
Quoted 10 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
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 :)
Quoted 2 lines
That's my daily experience as a serious and contributing Linux consultant / service provider.
Amen :)
Signature · 1 line
dwmw2