LinuxLists.cc - Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Sunday 27 October 2002 21:17, Rob Landley wrote:
> This is the next to last posting of this list. (When abbott and costello
> meet the monster, its time is almost up.) There will be at most one more,
> tomorrow, and it may just be a repost of this cc'd to Linus. (Those
> of you waiting for the last minute, this would be it.)

Knock off initramfs off...I'll be posting something that
supercedes it (IMO) within the next 72 hours.

Aside from providing full untar suppprt, it DRAMATICALLY
cleans up do_mounts.c and moves all the initrd code that was
there to initrd.c. Infact I pretty much entirly rewrote initrd,
so it makes sense. (purging prehistoric junk, etc.)

Dave

2002-10-30 07:34:26

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

Dave Cinege wrote:

>On Sunday 27 October 2002 21:17, Rob Landley wrote:
>
>
>>This is the next to last posting of this list. (When abbott and costello
>>meet the monster, its time is almost up.) There will be at most one more,
>>tomorrow, and it may just be a repost of this cc'd to Linus. (Those
>>of you waiting for the last minute, this would be it.)
>>
>>
>
>Knock off initramfs off...I'll be posting something that
>supercedes it (IMO) within the next 72 hours.
>
>Aside from providing full untar suppprt, it DRAMATICALLY
>cleans up do_mounts.c and moves all the initrd code that was
>there to initrd.c. Infact I pretty much entirly rewrote initrd,
>so it makes sense. (purging prehistoric junk, etc.)
>
>

lol

untar - cpio is better.
initrd - 99% moved out of the kernel
do_mounts - moved out of the kernel completely
initramfs - should be ready for Linus in the next day or so.

None of that junk -- and a whole lot more -- needs to be in the kernel
at all.

Jeff

2002-10-30 08:16:20

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Wednesday 30 October 2002 2:40, Jeff Garzik wrote:

> untar - cpio is better.

CPIO is commonly used and supported by NO ONE. (rpm, whoppee)
Kernels even come tar'ed. KISS....

> initrd - 99% moved out of the kernel

Great...you just killed the high level embedded linux market, and
the ability to play boot games from GRUB. (Network, etc)
Initrd is a good **OPTION* to have to fall back on...

> do_mounts - moved out of the kernel completely

And he's willing to completely purge initrd and do_mounts NOW???

> initramfs - should be ready for Linus in the next day or so.

Fire away with the 100K+ bloated POS. I'm backwards compatible,
could easily add 'linked kernel image' support, and only increase
the current code by 20K.

> None of that junk -- and a whole lot more -- needs to be in the kernel
> at all.

Do you have any serious sysadmin, clustering, or emebedded system
IMPLEMENTATION experience?

Dave

--
The time is now 22:48 (Totalitarian) - http://www.ccops.org/

2002-10-30 08:32:51

by Russell King

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Wed, Oct 30, 2002 at 03:22:17AM -0500, Dave Cinege wrote:
> Do you have any serious sysadmin, clustering, or emebedded system
> IMPLEMENTATION experience?

Please don't get personal, or you'll end up in peoples kill files.

ARM is basically embedded today, and I support initramfs. I don't
believe your "embedded system" argument holds any water. Yes, it
is a different way of doing things, but it can (and does here)
support initrd images.

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

2002-10-30 08:36:00

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

Dave Cinege wrote:

>On Wednesday 30 October 2002 2:40, Jeff Garzik wrote:
>
>
>
>>untar - cpio is better.
>>
>>
>
>CPIO is commonly used and supported by NO ONE. (rpm, whoppee)
>Kernels even come tar'ed. KISS....
>
Irrelevant to this problem. cpio unpack code is smaller, and its format
allows easy and painless concatenation.

>>initrd - 99% moved out of the kernel
>>
>>
>
>Great...you just killed the high level embedded linux market, and
>the ability to play boot games from GRUB. (Network, etc)
>Initrd is a good **OPTION* to have to fall back on...
>
Correct -- and after the initramfs merge, initrd behavior will be
completely unchanged.

>>do_mounts - moved out of the kernel completely
>>
>>
>
>And he's willing to completely purge initrd and do_mounts NOW???
>
Nothing is being purged. Things are being moved to userspace, making
the kernel smaller and less bloated. The kernel's behavior to the end
user is 100% unchanged.

>>initramfs - should be ready for Linus in the next day or so.
>>
>>
>
>Fire away with the 100K+ bloated POS. I'm backwards compatible,
>could easily add 'linked kernel image' support, and only increase
>the current code by 20K.
>
initramfs decreases the kernel size by a load, thank you very much.

Further, any initrd solution is bloated -- you are using a ram disk and
disk-based filesystem, the sum of which equates to ramfs -- with
additional wasted memory for filesystem and ramdisk overhead.

Jeff

2002-10-30 08:45:28

by Erik Andersen

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Wed Oct 30, 2002 at 03:22:17AM -0500, Dave Cinege wrote:
> On Wednesday 30 October 2002 2:40, Jeff Garzik wrote:
>
> > untar - cpio is better.
>
> CPIO is commonly used and supported by NO ONE. (rpm, whoppee)
> Kernels even come tar'ed. KISS....

Both formats are simple. But cpio is simpler.

> > initrd - 99% moved out of the kernel
>
> Great...you just killed the high level embedded linux market, and
> the ability to play boot games from GRUB. (Network, etc)
> Initrd is a good **OPTION* to have to fall back on...

Umm. No. See initramfs below. initrds have always been an
evil abomination. They do things terribly wrong and eliminating
them will _save_ space in embedded linux system. When busybox is
compiled without the special-case initrd workarounds, it does get
a bit smaller...

> > do_mounts - moved out of the kernel completely
>
> And he's willing to completely purge initrd and do_mounts NOW???
>
> > initramfs - should be ready for Linus in the next day or so.
>
> Fire away with the 100K+ bloated POS. I'm backwards compatible,
> could easily add 'linked kernel image' support, and only increase
> the current code by 20K.

Perhaps you have misunderstood. initramfs is simply an initrd
infrastructure that is done right. You don't need to use klibc
in your initramfs if you don't want to. Its just a piece of
normal unhosed-up userspace. Populate it as you see fit.

> Do you have any serious sysadmin, clustering, or emebedded system
> IMPLEMENTATION experience?

Yes he has plenty of experience. He also has good taste. IMHO
the embedded world (as well as everyone else) wants initramfs --
it is a major improvement.

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

2002-10-30 08:54:29

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

Erik Andersen <[email protected]> writes:
> IMHO the embedded world (as well as everyone else) wants initramfs --
> it is a major improvement.

I guess I'm part of the `embedded world,' and I don't want _either_
because they _both use RAM_!

[Well, OK, actually it'd be nice to have something like initramfs + some
other sort of fetch-the-bits-directly-from-ROM FS which I could
mix-n-match; anyway initramfs has got to be better than initrd...]

-Miles
--
Love is a snowmobile racing across the tundra. Suddenly it flips over,
pinning you underneath. At night the ice weasels come. --Nietzsche

2002-10-30 09:00:08

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

Miles Bader wrote:

>Erik Andersen <[email protected]> writes:
>
>
>>IMHO the embedded world (as well as everyone else) wants initramfs --
>>it is a major improvement.
>>
>>
>
>I guess I'm part of the `embedded world,' and I don't want _either_
>because they _both use RAM_!
>
>
hehe :)

>[Well, OK, actually it'd be nice to have something like initramfs + some
>other sort of fetch-the-bits-directly-from-ROM FS which I could
>mix-n-match; anyway initramfs has got to be better than initrd...]
>
>

It should be pretty easy to populate initramfs from ROM...

Jeff

2002-10-30 09:12:48

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

Jeff Garzik <[email protected]> writes:
> >[Well, OK, actually it'd be nice to have something like initramfs + some
> >other sort of fetch-the-bits-directly-from-ROM FS which I could
> >mix-n-match; anyway initramfs has got to be better than initrd...]
>
> It should be pretty easy to populate initramfs from ROM...

Actually what I was trying to say was that often I don't want to copy
from ROM to RAM, I just want to have file reads get the bits directly
from ROM (to avoid using, um, RAM).

Currently I do this by using a romfs filesystem stored in an MD device
which is reading from ROM.

-Miles
--
[|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that
will make every christian in the world foamm at the mouth?
[iddt] nurg, that's the goal

2002-10-30 09:20:38

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

Miles Bader wrote:

>Jeff Garzik <[email protected]> writes:
>
>
>>>[Well, OK, actually it'd be nice to have something like initramfs + some
>>>other sort of fetch-the-bits-directly-from-ROM FS which I could
>>>mix-n-match; anyway initramfs has got to be better than initrd...]
>>>
>>>
>>It should be pretty easy to populate initramfs from ROM...
>>
>>
>
>Actually what I was trying to say was that often I don't want to copy
>from ROM to RAM, I just want to have file reads get the bits directly
>from ROM (to avoid using, um, RAM).
>
>

Yep, that was my assumption.

If your ROM is directly addressable, i.e. not read over a single-bit bus
or anything, it should be doable. I'm not saying that initramfs will do
this out of the box :) but going from initramfs to "initromfs" should
not be a huge leap...

However, that said, things also depend on what proggies you are running
in your initramfs. You may be running code that only runs at startup
when the kernel boots, in which case the best space utilization would be
to uncompress a compressed image out of ROM to RAM, use it to bootstrap,
and then free [unlink] all the initramfs files that are no longer needed.

Jeff

2002-10-30 09:28:17

by Russell King

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Wed, Oct 30, 2002 at 04:06:00AM -0500, Jeff Garzik wrote:
> It should be pretty easy to populate initramfs from ROM...

Typical embedded initrds do fairly disgusting tricks to "work around"
the limitations of themselves. These tricks are solved cleanly by
initramfs, but I'll guess that the reason embedded people will complain
is because it is different, and embedded people don't like to unlearn
old tricks.

Here's two things that initramfs does that there is no way in hell an
initrd can ever do:

- once you've finished with various stuff, you can remove it and
thereby free up the space that file was occupying for use by anything
without having to wait for the whole filesystem to become unused.

- there's no need to mount a ramfs filesystem, or a blockdev /dev/ram
ext2fs-formatted filesystem for /tmp, /etc or /var/run (etc) since
/ is already a ramfs filesystem, thereby removing:
+ extra symlinks for writable files in these directories
+ extra mount points (with associated kernel structures)
+ ext2fs
+ rd

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

2002-10-30 09:26:10

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Wednesday 30 October 2002 3:37, Russell King wrote:
> On Wed, Oct 30, 2002 at 03:22:17AM -0500, Dave Cinege wrote:
> > Do you have any serious sysadmin, clustering, or emebedded system
> > IMPLEMENTATION experience?
>
> Please don't get personal, or you'll end up in peoples kill files.

It's not personal. He made a wild 'No one needs any of this[initrd]'
statement. Is he coming from 'this looks like a good idea'(coder) or
'I can prove this is a good idea through experience examples.'
(systems engineer)

I can prove to you (for one thing) that when the shit hits the
fan (disaster recovery) initrd is a good option to have.

> ARM is basically embedded today, and I support initramfs. I don't
> believe your "embedded system" argument holds any water. Yes, it

High level embedded systems...low level systems could care less.

> is a different way of doing things, but it can (and does here)
> support initrd images.

The point to this is:

Linking an image into the kernel LOOKS nice, but I would sure not
want to deploy it because it becomes an adminstation nightmare.
Even with initrd, a single file can be a problem...this is why my
patch supports extracting multiple tar.gz archives....to maintain
configuration modularity.

Having an image in the kernel is not a bad thing...making it the
only option is.

Dave

--
The time is now 22:48 (Totalitarian) - http://www.ccops.org/

2002-10-30 09:32:07

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

Jeff Garzik <[email protected]> writes:
> I'm not saying that initramfs will do
> this out of the box :) but going from initramfs to "initromfs" should
> not be a huge leap...

Do you mean by putting the `internal' format that initramfs normally
uses in RAM, in ROM, and skip the initial decompression step?

Or do you mean have it somehow avoid copying the data areas of the cpio
stream (i.e. store pointers from the tree-in-ram to the actual data
blocks in ROM).

I guess the latter sounds cleaner... it would also have the advantage
that you could have a tree with the bulk of data in ROM, but which
allowed new files to be written (which would be stored in RAM).

Hmmm...sounds very intersting...

-Miles
--
I'd rather be consing.

2002-10-30 09:36:14

by Erik Andersen

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Wed Oct 30, 2002 at 06:38:24PM +0900, Miles Bader wrote:
> Or do you mean have it somehow avoid copying the data areas of the cpio
> stream (i.e. store pointers from the tree-in-ram to the actual data
> blocks in ROM).
>
> I guess the latter sounds cleaner... it would also have the advantage
> that you could have a tree with the bulk of data in ROM, but which
> allowed new files to be written (which would be stored in RAM).
>
> Hmmm...sounds very intersting...

Now _that_ would be extremely useful!

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

2002-10-30 09:30:39

by Erik Andersen

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Wed Oct 30, 2002 at 04:06:00AM -0500, Jeff Garzik wrote:
> Miles Bader wrote:
> >[Well, OK, actually it'd be nice to have something like initramfs + some
> >other sort of fetch-the-bits-directly-from-ROM FS which I could
> >mix-n-match; anyway initramfs has got to be better than initrd...]
> >
> >
>
> It should be pretty easy to populate initramfs from ROM...

I imagine so. But that still leaves everything in RAM. On a
system with just 1 or 2 MB of ram (I have run Linux on such
things :-) there really isn't much point in trying to use any
sortof ramfs. Its just not going to work. For that type of
application you really want something like JFFS, JFFS2 and
whatnot living in ROM/flash. But I'm sure someone could find
a reason for a *ramfs to be useful, even then.... :)

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

2002-10-30 09:49:02

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Wednesday 30 October 2002 4:00, Miles Bader wrote:
> Erik Andersen <[email protected]> writes:
> > IMHO the embedded world (as well as everyone else) wants initramfs --
> > it is a major improvement.

Erik

#1 I'll be reviewing initramfs and adding loading image from
the kernel support. I don't deny it's a godo thig to have.

#2 My main bitch at jeff was he said if initramfs goes in
initrd comes out. initrd shodul not come out.

My patch is the best of both because

> I guess I'm part of the `embedded world,' and I don't want _either_
> because they _both use RAM_!

My patch supports this (well it can be in about 5 lines of code)

Right now for backwards compatiblity I have a
initrd_from_floppy option (which replaces load_ramdisk=).
I was debating changing that to initrd_from= and then you can
spec /dev/fd0, /dev/fd1, or in your case a memory device linux
understandings.

But I mostly dimissed it because that is the job of the
boot loader....but you bring up a good point where it
could be used.

--
The time is now 22:48 (Totalitarian) - http://www.ccops.org/

2002-10-30 09:53:25

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

Dave Cinege <[email protected]> writes:
> #2 My main bitch at jeff was he said if initramfs goes in
> initrd comes out. initrd shodul not come out.

So what are the advantages of initrd over initramfs? Is it just
historical compatibility, or are is there more?

-Miles
--
Come now, if we were really planning to harm you, would we be waiting here,
beside the path, in the very darkest part of the forest?

2002-10-30 09:49:01

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Wednesday 30 October 2002 3:51, Erik Andersen wrote:

Erik,

> Both formats are simple. But cpio is simpler.

untar runs about 5K...same as 'un-cpio'. No differece there.
But not from userland. Tar is used en masse, cpio isn't.
It's the only reason to use tar over cpio...I feel it's a
good one.

Erik

#1 I'll be reviewing initramfs and adding loading images from
the kernel support. I don't deny it's a good thing to have.

#2 My main complaint is Jeff said if initramfs goes in
initrd comes out. initrd should not come out. Let me clarify: the
abilty of the bootloader to load images/archives for the kernel
to extract should not come out.

My patch is the best of both because, it re-writes initrd
properly within a sane framework. (Not to mention I scrubed the hell
out of do_mounts.)

If you want to get rid of all the backwards compatible stuff
(IE identifing and loading raw images to /dev/ram0,
pivoting to /initrd) that's fine with me. The code is layed out now
so I can litterally cut it out 10K of that junk in 30 seconds.
Better yet I can ifdef it for the poor souls that still need it.

Dave

2002-10-30 10:00:50

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Wednesday 30 October 2002 4:34, Russell King wrote:

> - there's no need to mount a ramfs filesystem,

An implementation flaw I think I pointed out to Al a year ago.
You can not set a size limit on your root othewise.
That's why I mount a '/dev/tmpfs/'.

My patch will cometh later today. I need some sleep right now.

Dave

--
The time is now 22:48 (Totalitarian) - http://www.ccops.org/

2002-10-30 09:59:42

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

Dave Cinege wrote:

>#2 My main bitch at jeff was he said if initramfs goes in
>initrd comes out. initrd shodul not come out.
>
>

What part of "kernel's behavior is 100% unchanged" did you not understand?

Stop spreading FUD.

2002-10-30 10:08:34

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Wednesday 30 October 2002 5:05, Jeff Garzik wrote:
> Dave Cinege wrote:
> >#2 My main bitch at jeff was he said if initramfs goes in
> >initrd comes out. initrd shodul not come out.
>
> What part of "kernel's behavior is 100% unchanged" did you not understand?

You said this where?

> Stop spreading FUD.

You DID Say:

On Wednesday 30 October 2002 2:40, Jeff Garzik wrote:
> untar - cpio is better.
> initrd - 99% moved out of the kernel
> do_mounts - moved out of the kernel completely
> initramfs - should be ready for Linus in the next day or so.
>
> None of that junk -- and a whole lot more -- needs to be in the kernel
> at all.

Excuse me if I take this to mean something different then:
"kernel's behavior is 100% unchanged"

2002-10-30 10:18:31

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Wednesday 30 October 2002 4:59, Miles Bader wrote:
> Dave Cinege <[email protected]> writes:
> > #2 My main bitch at jeff was he said if initramfs goes in
> > initrd comes out. initrd shodul not come out.
>
> So what are the advantages of initrd over initramfs? Is it just
> historical compatibility, or are is there more?

I didn't intend to get into a crazy discussion like this now...

After I release my patch later today, and people see how it
works, then we can discuss this is a meaningful manner.

Until then, I'll end further comments to this thread.

Dave

--
The time is now 22:48 (Totalitarian) - http://www.ccops.org/

2002-10-30 10:18:42

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

Dave Cinege wrote:

>On Wednesday 30 October 2002 5:05, Jeff Garzik wrote:
>
>
>>Dave Cinege wrote:
>>
>>
>>>#2 My main bitch at jeff was he said if initramfs goes in
>>>initrd comes out. initrd shodul not come out.
>>>
>>>
>>What part of "kernel's behavior is 100% unchanged" did you not understand?
>>
>>
>
>You said this where?
>
>
Message-ID: <[email protected]>
Exact quote: "The kernel's behavior to the end user is 100% unchanged."

"To:" header: [email protected]

>You DID Say:
>
>On Wednesday 30 October 2002 2:40, Jeff Garzik wrote:
>
>
>>untar - cpio is better.
>>initrd - 99% moved out of the kernel
>>do_mounts - moved out of the kernel completely
>>initramfs - should be ready for Linus in the next day or so.
>>
>>None of that junk -- and a whole lot more -- needs to be in the kernel
>>at all.
>>
>>
>
>Excuse me if I take this to mean something different then:
>"kernel's behavior is 100% unchanged"
>
>
You appear to be unaware of early userspace. Moving code out of the
kernel does _not_ mean eliminating that code completely. I was hoping
it was obvious that it is impossible to eliminate the tasks that
do_mounts.c performs -- otherwise a Linux system would never have a root
filesystem mounted.

Being unaware of early userspace implies that you are not familiar with
initramfs.
Which implies you wish you merge your own code in place of something you
do not understand.

Jeff

2002-10-30 10:24:05

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

Dave Cinege wrote:

>On Wednesday 30 October 2002 3:51, Erik Andersen wrote:
>
>Erik,
>
>
>
>>Both formats are simple. But cpio is simpler.
>>
>>
>
>untar runs about 5K...same as 'un-cpio'. No differece there.
>
Wrong. un-cpio is obviously smaller. Just look at the generated
assembly... on any platform.

>But not from userland. Tar is used en masse, cpio isn't.
>It's the only reason to use tar over cpio...I feel it's a
>good one.
>
IOW you'd rather bloat the kernel because tarballs are popular...

>#1 I'll be reviewing initramfs and adding loading images from
>
>the kernel support. I don't deny it's a good thing to have.
>

There is no need to add anything.

>My patch is the best of both because, it re-writes initrd
>properly within a sane framework. (Not to mention I scrubed the hell
>out of do_mounts.)
>
No need for this, initramfs means that initrd and do_mounts are moved
out of the kernel.

>If you want to get rid of all the backwards compatible stuff
>(IE identifing and loading raw images to /dev/ram0,
>pivoting to /initrd) that's fine with me. The code is layed out now
>so I can litterally cut it out 10K of that junk in 30 seconds.
>Better yet I can ifdef it for the poor souls that still need it.
>
>

Or better yet use initramfs, where it simply doesn't exist in the kernel
image at all :)

Jeff

2002-10-30 10:36:24

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Wednesday 30 October 2002 5:24, Jeff Garzik wrote:

> You appear to be unaware of early userspace. Moving code out of the
> kernel does _not_ mean eliminating that code completely.

My appologies, I thought you meant do_mounts.c was being yanked
entirly if initramfs goes in.

> do_mounts.c performs -- otherwise a Linux system would never have a root
> filesystem mounted.

Actually it's very possible to eliminate it....require an initramfs image
to have scripts and tools (mount and pivotroot) to do it all and mount that
as the root. (An interesting but pretty bad idea IMO) This is what I thought
you meant.

> Being unaware of early userspace implies that you are not familiar with
> initramfs.

I'll accept your apology after you see how nicely I cleaned up do_mounts.c
(It's 11K now) However I did not know the 'rootfs' was called 'early
userspace'. (Or was my above assumption correct?)

> Which implies you wish you merge your own code in place of something you
> do not understand.

Jeff, be nice. I'm trying very hard myself...and if you knew me, you'd know
it's a difficult task. : >

Dave

2002-10-30 10:46:54

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

Erik Andersen wrote:

>On Wed Oct 30, 2002 at 04:06:00AM -0500, Jeff Garzik wrote:
>
>
>>Miles Bader wrote:
>>
>>
>>>[Well, OK, actually it'd be nice to have something like initramfs + some
>>>other sort of fetch-the-bits-directly-from-ROM FS which I could
>>>mix-n-match; anyway initramfs has got to be better than initrd...]
>>>
>>>
>>>
>>>
>>It should be pretty easy to populate initramfs from ROM...
>>
>>
>
>I imagine so. But that still leaves everything in RAM. On a
>system with just 1 or 2 MB of ram (I have run Linux on such
>things :-) there really isn't much point in trying to use any
>sortof ramfs.
>
It depends on what you're talking about... if it's just the do_mount.c
and mount-root-filesystem code, that code gets unlinked and removed from
RAM completely after the kernel booting completes.

If it's other filesystem data you want hanging around after boot
completes, check out my reply to Miles... it's doable.

Jeff

2002-10-30 10:44:44

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

Miles Bader wrote:

>Jeff Garzik <[email protected]> writes:
>
>
>>I'm not saying that initramfs will do
>>this out of the box :) but going from initramfs to "initromfs" should
>>not be a huge leap...
>>
>>
>
>Do you mean by putting the `internal' format that initramfs normally
>uses in RAM, in ROM, and skip the initial decompression step?
>
>Or do you mean have it somehow avoid copying the data areas of the cpio
>stream (i.e. store pointers from the tree-in-ram to the actual data
>blocks in ROM).
>
>I guess the latter sounds cleaner... it would also have the advantage
>that you could have a tree with the bulk of data in ROM, but which
>allowed new files to be written (which would be stored in RAM).
>
>

Well, Linux wants file data in pages, so you would need to be able to
get your kernel to point to page-aligned ROM regions. Otherwise you are
stuck with the same issues as fs/romfs or fs/cramfs or most other Linux
filesystems -- you gotta copy the data into a RAM page before the Linux
VFS will look at it[1]. For the initramfs cpio image itself, it can
either piggyback inside the kernel image, or be loaded separately via
bootloader, from ROM, or some other magic means. Unpacking [what is
essentially] pointers into the ROM would probably involve custom
userland code in an initramfs which mounts and populates a ROM-based
filesystem.

So one way or another you can have all of _your own_ data in ROM, but I
don't want to paint too rosy a picture -- if you want to be smarter than
fs/romfs is now, it will take some additional work. And of course the
ramfs-based rootfs will still be needed as the underlying writable fs.

Jeff

[1] or you can create your own file_operations and eliminate this
restriction... with a bunch of ROM-specific custom code that totally
bypasses the pagecache

2002-10-30 11:00:54

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

Dave Cinege wrote:

>On Wednesday 30 October 2002 5:24, Jeff Garzik wrote:
>
>
>
>>You appear to be unaware of early userspace. Moving code out of the
>>kernel does _not_ mean eliminating that code completely.
>>
>>
>
>My appologies, I thought you meant do_mounts.c was being yanked
>entirly if initramfs goes in.
>
>

Apology accepted -- and note my apology further down below ;-)

>>do_mounts.c performs -- otherwise a Linux system would never have a root
>>filesystem mounted.
>>
>>
>
>Actually it's very possible to eliminate it....require an initramfs image
>to have scripts and tools (mount and pivotroot) to do it all and mount that
>as the root. (An interesting but pretty bad idea IMO) This is what I thought
>you meant.
>

That's what is going to happen. The initramfs image is completely
removed from RAM after all this occurs, combined with moving code out of
the kernel to early userspace, is how the overall kernel size shrinks.

Looking at a kernel cleanliness perspective, mounting root, unpacking
initrd images, etc. get more and more complex -- with one simply copying
userspace code into the kernel to get the job done. In order to do NFS
root for example, the kernel has an internal BOOTP and DHCP client, to
snag an IP. This mess simply does not belong in the kernel. Never did.

>>Being unaware of early userspace implies that you are not familiar with
>>initramfs.
>>
>>
>
>I'll accept your apology after you see how nicely I cleaned up do_mounts.c
>(It's 11K now) However I did not know the 'rootfs' was called 'early
>userspace'. (Or was my above assumption correct?)
>
The absolutely smallest possible code is - unpack a cpio archive onto a
ramfs.

If you want to support initrd --in kernel-- you must add in much more
code: ram disk device, and filesystem of your choice
(minix/ext2/whatever). _Any_ initrd code in the kernel is quite simply
too much. It doesn't matter how much you clean up the do_mounts.c code,
"zero bytes" will always be smaller :)

>>Which implies you wish you merge your own code in place of something you
>>do not understand.
>>
>>
>
>Jeff, be nice. I'm trying very hard myself...and if you knew me, you'd know
>it's a difficult task. : >
>
>

lol

As promised above, I do apologize for jumping all over you. :) I
should have much more tact and approach posts with a more educational
perspective.

Further, if you are patient with _me_, I think I can explain how
initramfs can (a) keep your existing initrd images working just fine or
(b) help you shrink your startup images even more.

Jeff

2002-10-30 14:07:09

by Alan

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Wed, 2002-10-30 at 08:22, Dave Cinege wrote:
> > untar - cpio is better.
>
> CPIO is commonly used and supported by NO ONE. (rpm, whoppee)
> Kernels even come tar'ed. KISS....

I'm sorry but if you can't work cpio you probably shouldnt be hacking
kernels anyway. If you can work it and have to deal with cow-orkers who
can't then write them a nice drag and drop cpio builder.

> Great...you just killed the high level embedded linux market, and
> the ability to play boot games from GRUB. (Network, etc)
> Initrd is a good **OPTION* to have to fall back on...

They all work with initramfs

> Do you have any serious sysadmin, clustering, or emebedded system
> IMPLEMENTATION experience?

I do and I don't see the problem. The one reason you want to keep initrd
around is ROM and there are better ways of doing "initromfs"

2002-11-04 07:07:59

by Rob Landley

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Wednesday 30 October 2002 09:55, Dave Cinege wrote:

> But not from userland. Tar is used en masse, cpio isn't.

Red hat uses cpio all over the place. RPM is cpio based, and the drivers in a
Red Hat boot disk or driver disk are in a cpio file as well (and their cdrom
boot process uses the same code, so that's also cpio). This almost certainly
means Mandrake uses the same stuff, and between the two of them we are over
50% of both the Linux installed base, new sales, and new installs. (Take
your pick of what you want to measure.)

Yeah, cpio is a pain and change to use, but so is tar. You're just used to
it. To get the behavior you want creating a tarball, your option list is
probably something like "tar cvjfpC tarball.tbz dirname .". Hands up
everybody who thinks cvjfpC is intuitive? Yes you could instead do "cd
dirname; tar cvp * | bzip2 > tarball.tbz" if that strikes you as more
newbie-friendly. (This is assuming you know that that "v" goes to stderr
rather than standard out when it detects that stdout has been redirected, but
then you had to know to use "." rather than "*" for obvious reasons. :)

And of course this is assuming you're using gnu tar (which still doesn't
officially support bzip by the way, j support was a patch last I checked).
The older versions wanted a dash before the options list. (Try the version
of tar in busybox sometime...)

> It's the only reason to use tar over cpio...I feel it's a
> good one.

By that logic, people should stick with windows. :)

The objection is "people shouldn't have to learn a new tool when upgrading to
a new kernel". A tool that has been around since the 1970's, I'm might
add...

Rob

--
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad,
CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?

2002-11-04 07:33:27

by Jacek Pliszka

[permalink] [raw]

Subject: Help needed with IRQ on Ali chipset

Hi!

I am asking once more for help with IRQ setup for Cardbus controller on
ATI U1/Ali 1535+ chipset. This time with more exact information. This is
what I get:

lspci -v -s 00:0a.0
00:0a.0 CardBus bridge: O2 Micro, Inc.: Unknown device 6972
Subsystem: Hewlett-Packard Company: Unknown device 0024
Flags: bus master, slow devsel, latency 32, IRQ 5
Memory at 80000000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=02, subordinate=05, sec-latency=32
Memory window 0: 81000000-81100000
I/O window 0: 00003000-0000307f
I/O window 1: 00000000-00000003
16-bit legacy interface ports at 0001

Which is consistent with Windows IRQ 5

But dump_pirq gives:
Interrupt routing table found at address 0xfdf10:
Version 1.0, size 0x00d0
Interrupt router is device 00:07.0
PCI exclusive interrupt mask: 0x0000 []
Compatible router: vendor 0x10b9 device 0x1533
....(skipped)

Device 00:0a.0 (slot 0): CardBus bridge
INTA: link 0x06, irq mask 0x00a0 [5,7]

Device 00:12.0 (slot 0): Ethernet controller
INTA: link 0x02, irq mask 0x0880 [7,11]

Device 00:0c.0 (slot 0):
INTA: link 0x03, irq mask 0x0658 [3,4,6,9,10]

Interrupt router at 00:07.0: AcerLabs Aladdin M1533 PCI-to-ISA bridge
INT1 (link 1): irq 10
INT2 (link 2): irq 11
INT3 (link 3): unrouted
INT4 (link 4): unrouted
INT5 (link 5): unrouted
INT6 (link 6): irq 11
INT7 (link 7): irq 3
INT8 (link 8): irq 5
Serial IRQ: [enabled] [continuous] [frame=21] [pulse=12]

So INT6 instead of 5 gets 11 but it is not shown in lspci.

Could somebody, please, tell me what and where should be fixed
(I guess in pci-irq.c) to get it correct.

BR,

Jacek

2002-11-04 12:43:07

by Alan

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

On Mon, 2002-11-04 at 02:13, Rob Landley wrote:
> Yeah, cpio is a pain and change to use, but so is tar. You're just used to
> it. To get the behavior you want creating a tarball, your option list is
> probably something like "tar cvjfpC tarball.tbz dirname .". Hands up
> everybody who thinks cvjfpC is intuitive? Yes you could instead do "cd

The reason for using cpio is that while the cpio command was clearly
engineered to give "find" some competition the file format it uses is
actually quite sane, while the tar file format is a bit crufty, and the
standards compliant version of it has some irritating limitations

We only care about the file format for the purposes of an initrd

Alan

2002-11-04 22:46:39

by Werner Almesberger

[permalink] [raw]

Subject: Re: Abbott and Costello meet Crunch Time -- Penultimate 2.5 merge candidate list.

Rob Landley wrote:
> Yeah, cpio is a pain and change to use, but so is tar.

Somebody who strogly dislikes cpio could just write wrapper accepting
tar-style options. Or add a --cpio option to GNU tar, that switches
to using the cpio format. One could even try to auto-detect the
format when reading :-)

- Werner (hates cpio, but not enough)

--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/

2002-11-04 22:57:32