In-Reply-To: <[EMAIL PROTECTED]>
> Linux-kernel is a very high volume mailing list, and proper use of
> email threading is *vital* to read it: you immediately get all
> references to previous messages, and it makes it easy to skip threads
> you're not interested in
Does manually adding the repl
On Sun, Aug 28, 2005 at 12:41:08AM +0100, Alistair John Strachan wrote:
> On Saturday 27 August 2005 22:28, Chris Wedgwood wrote:
> > On Sat, Aug 27, 2005 at 08:19:18AM +, Kent Robotti wrote:
> > > I know that experience dosen't come from packing the kernel source,
> > > or the zillion other ta
On Saturday 27 August 2005 07:41 pm, Alistair John Strachan wrote:
> No offence Chris, but not everybody under 25 is an asshole.
Get real. We have two things colliding here:
1) People in the FOSS community often are assholes
2) People under 25 often are assholes
... ergo, people in the FOSS commu
On Saturday 27 August 2005 22:28, Chris Wedgwood wrote:
> On Sat, Aug 27, 2005 at 08:19:18AM +, Kent Robotti wrote:
> > I know that experience dosen't come from packing the kernel source,
> > or the zillion other tar archives on the internet.
>
> Are you deliberately trying to be annoying? Le
On Sat, Aug 27, 2005 at 10:45:55PM +, Kent Robotti wrote:
> Why don't you do some research on manners?
It was (an obvious) troll. Don't take it so seriously. Besides, deep
deep down I really am a terrible person.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
On Saturday 27 August 2005 06:45 pm, Kent Robotti wrote:
> Are you satisfied ass?
... said the troll.
--
Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED]
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be running around in darkened rooms, munching magic
On Sat, Aug 27, 2005 at 10:45:55PM +, Kent Robotti wrote:
> On Sat, Aug 27, 2005 at 02:28:17PM -0700, Chris Wedgwood wrote:
> > How about you do a little research on some things for a bit? The
> > initramfs code is done the way it is for a good reason. cpio is used
> > over tar for another go
On Sat, Aug 27, 2005 at 02:28:17PM -0700, Chris Wedgwood wrote:
> How about you do a little research on some things for a bit? The
> initramfs code is done the way it is for a good reason. cpio is used
> over tar for another good reason.
Why don't you do some research on manners?
> You are mos
On Sat, 2005-08-27 at 14:28 -0700, Chris Wedgwood wrote:
> - you're very interesting in real-time patches. linux should
> clearly have all real-time stuff merged. second to your interest
> in realtime is probably something like selinux
Please don't lump the -rt kernel people in with the
On Sat, Aug 27, 2005 at 08:19:18AM +, Kent Robotti wrote:
> I know that experience dosen't come from packing the kernel source,
> or the zillion other tar archives on the internet.
Are you deliberately trying to be annoying? Let me guess:
- your under 25 years of age, probably in high sc
On Fri Aug 26 2005 - 05:33:43 EST, Erik Mouw wrote:
> I prefer tar because I have more experience with it, and it works.
>> The kernel people prefer cpio because they have experience with it, it
>> doesn't need too much code, and it works.
I know that experience dosen't come from pa
On Sat, Aug 27, 2005 at 03:21:27AM +, Kent Robotti wrote:
> The purpose of the patch is to overmount ramfs/rootfs with tmpfs before
> the compressed cpio archive is unpacked and /init is run.
yes and no
there are people who want the overmount even without cpio
decompression
> But, it's only
On Fri, Aug 26, 2005 at 05:40:45PM -0700, Chris Wedgwood wrote:
> On Fri, Aug 26, 2005 at 09:12:31PM +, Kent Robotti wrote:
>
> > Ideally, I don't know why you would want to overmount unless the
> > kernel detects an initramfs.
>
> because the rootfs doesn't work the way you think it does. t
On Fri, Aug 26, 2005 at 01:22:26PM -0700, Chris Wedgwood wrote:
> On Fri, Aug 26, 2005 at 08:08:51PM +, Kent Robotti wrote:
>
> > Overmount_rootfs shouldn't take place until you know for sure the
> > kernel detects an initramfs.
>
> Actually, it was a deliberate decision to *always* overmount
On Fri, Aug 26, 2005 at 08:08:51PM +, Kent Robotti wrote:
> Overmount_rootfs shouldn't take place until you know for sure the
> kernel detects an initramfs.
Actually, it was a deliberate decision to *always* overmount after
some discussion with people.
It's not a clean solution and the overa
On Fri, Aug 26, 2005 at 12:06:47PM -0700, Chris Wedgwood wrote:
> On Thu, Aug 25, 2005 at 09:39:15PM -0400, [EMAIL PROTECTED] wrote:
>
> > Wouldn't it be better to put overmount_rootfs in initramfs.c
> > and call it only if there's a initramfs?
>
> I don't see what or how that helps. Yes we can
On Thu, Aug 25, 2005 at 08:05:32PM +0100, Alan Jenkins wrote:
> I'm curious as to why the kernel has to include the decoder - why
> you can't just run a self-extracting executable in an empty
> initramfs (with a preset capacity if needs be).
You could do tht right now if you wished.
We just supp
On Thu, Aug 25, 2005 at 11:38:49AM -0400, [EMAIL PROTECTED] wrote:
> What if you have a root.cpio.gz that requires 200MB to hold, but you
> only have 300MB of memory?
then it won't work with nay of the schemes you've suggested
> 50% of total memory wouldn't hold it, but 90% etc. would (tmpfs_siz
On Thu, Aug 25, 2005 at 09:39:15PM -0400, [EMAIL PROTECTED] wrote:
> Wouldn't it be better to put overmount_rootfs in initramfs.c
> and call it only if there's a initramfs?
I don't see what or how that helps. Yes we can shuffle some code
about but the real problem still exists.
That is is that
Erik Mouw <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 25, 2005 at 02:15:13PM -0400, [EMAIL PROTECTED] wrote:
>> For one, if you do "dd if=/dev/zero of=foo" on a ramfs the system
>> will lock up.
>
> "Doctor, it hurts when I do this!" "Well, then don't do that."
> You found a nice case of "Unix, rope
[EMAIL PROTECTED] wrote:
>>On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote:
>>I don't know, because tar is probably more widely used and
>>consequently people are more familiar with how to use it.
>>>As I said before, the cpio format is cleaner/easier to parse in t
On Thu, Aug 25, 2005 at 08:05:32PM +0100, Alan Jenkins wrote:
> > On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] wrote:
> > > Right, but it would be nice to have that option if initramfs
> > > using tmpfs becomes part of the kernel.
> >
> > But it's not needed so why add bloat?
>
On Thu, Aug 25, 2005 at 02:15:13PM -0400, [EMAIL PROTECTED] wrote:
>
>>Could you please please pretty please get an RFC compliant mailer that
>>generates "In-Reply-To" and preferable even "References" headers?
>>Right
>>now every mail you write starts a new thread instead of refer
>I'm not subscribed, so sorry if this doesn't fall into the original
>thread. I'm curious as to why the kernel has to include the decoder -
>why you can't just run a self-extracting executable in an empty
>initramfs (with a preset capacity if needs be).
The kernel already includes gunz
This is in reference to Chris Wedgwood's patch.
Wouldn't it be better to put overmount_rootfs in initramfs.c
and call it only if there's a initramfs?
printk(KERN_INFO "checking if image is initramfs...");
err = unpack_to_rootfs((char *)initrd_start,
>I'm not subscribed to the list and I use lynx and a small mda
>called msmtp, so I know it's awkward (perhaps mostly for me).
>>People seem to be CCing you, can't you reply to the message you
>>receive that way? That's how everyone else who doesn't subscribe
>>gets along...
>>
> On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] wrote:
> > Right, but it would be nice to have that option if initramfs
> > using tmpfs becomes part of the kernel.
>
> But it's not needed so why add bloat?
I'm not subscribed, so sorry if this doesn't fall into the original
threa
On Thu, 2005-08-25 at 14:15 -0400, [EMAIL PROTECTED] wrote:
>>Could you please please pretty please get an RFC compliant mailer that
>>generates "In-Reply-To" and preferable even "References" headers?
>>Right
>>now every mail you write starts a new thread instead of referencing to
>On Thu, Aug 25, 2005 at 11:38:49AM -0400, [EMAIL PROTECTED] wrote:
>What if you have a root.cpio.gz that requires 200MB to hold, but you
>only have 300MB of memory?
>
>50% of total memory wouldn't hold it, but 90% etc. would
>(tmpfs_size=90%).
>>tmpfs will not help you here.
>Could you please please pretty please get an RFC compliant mailer that
>generates "In-Reply-To" and preferable even "References" headers?
>Right
>now every mail you write starts a new thread instead of referencing to
>the previous one. See http://lkml.org/lkml/2005/8/25/180/ to se
On Thu, Aug 25, 2005 at 11:38:49AM -0400, [EMAIL PROTECTED] wrote:
> What if you have a root.cpio.gz that requires 200MB to hold, but you
> only have 300MB of memory?
>
> 50% of total memory wouldn't hold it, but 90% etc. would (tmpfs_size=90%).
tmpfs will not help you here. Yes, it can be swappe
Could you please please pretty please get an RFC compliant mailer that
generates "In-Reply-To" and preferable even "References" headers? Right
now every mail you write starts a new thread instead of referencing to
the previous one. See http://lkml.org/lkml/2005/8/25/180/ to see what I
mean.
On Thu
>Right, but it would be nice to have that option if initramfs
>using tmpfs becomes part of the kernel.
>>But it's not needed so why add bloat?
A 'tmpfs_size' option seems to just make sense given the fact that
the mount program has a 'size' option for tmpfs.
It makes sense if tmpfs beco
>On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote:
>I don't know, because tar is probably more widely used and
>consequently people are more familiar with how to use it.
>>As I said before, the cpio format is cleaner/easier to parse in the
>>kernel. Everyone has cpi
On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote:
> I don't know, because tar is probably more widely used and
> consequently people are more familiar with how to use it.
As I said before, the cpio format is cleaner/easier to parse in the
kernel. Everyone has cpio probably so us
On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] wrote:
> Right, but it would be nice to have that option if initramfs
> using tmpfs becomes part of the kernel.
But it's not needed so why add bloat?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
>Also, tar should be an option instead of cpio for the archiver,
>because tar is more widely used.
>>pretty much everyone will have cpio and it's format is much
>>simpler/cleaner to deal with
>>if we want vastly more complex early-userspace semantics i think we
>>need to carefully
>It uses 50% of total memory for tmpfs, but it would be nice to have
>an option (tmpfs_size=90% etc.) that you could pass to the kernel.
>>that's just because of the tmpfs default; you can remount to change
>>that if it's not suitable once your up and running in your
>>init-scripts
On Tue, Aug 23, 2005 at 05:16:05PM -0400, [EMAIL PROTECTED] wrote:
> Also, tar should be an option instead of cpio for the archiver,
> because tar is more widely used.
pretty much everyone will have cpio and it's format is much
simpler/cleaner to deal with
if we want vastly more complex early-us
On Wed, Aug 24, 2005 at 06:41:26PM -0400, [EMAIL PROTECTED] wrote:
> I tried it with kernel 2.6.13-rc5 and it seems to work.
it should yes
> It uses 50% of total memory for tmpfs, but it would be nice to have
> an option (tmpfs_size=90% etc.) that you could pass to the kernel.
that's just becau
>>On Wed, Aug 24, 2005 at 04:52:37PM -0400, Wakko Warner wrote:
>>Care to send me the patch?
>Heh. Not really as I don't really know if people should be using it
>in it's current state --- the shmem init is very very hacky and I have
>other changes I've not had a chance to do.
>A
On Wed, Aug 24, 2005 at 04:52:37PM -0400, Wakko Warner wrote:
> Care to send me the patch?
Heh. Not really as I don't really know if people should be using it
in it's current state --- the shmem init is very very hacky and I have
other changes I've not had a chance to do.
Anyhow, here is an old
Chris Wedgwood wrote:
> I have a path for initramfs to use tmpfs. It's sorta hacky so I never
> submitted it and solves a niche problem for embedded people.
>
> Ultimately we might one day still want to change how we initialize the
> early userspace (Al suggesting a reasomably nice way to move th
>I have a path for initramfs to use tmpfs. It's sorta hacky so I never
>submitted it and solves a niche problem for embedded people.
>Ultimately we might one day still want to change how we initialize the
>early userspace (Al suggesting a reasomably nice way to move the
>decompresso
On Tue, Aug 23, 2005 at 06:05:47PM -0400, [EMAIL PROTECTED] wrote:
> I was just making a suggestion to whoever it may concern, because I
> think it would extend the usefullness of initramfs.
I have a path for initramfs to use tmpfs. It's sorta hacky so I never
submitted it and solves a niche pro
>> Why doesn't initramfs use tmpfs instead of ramfs, because
>> tmpfs is more robust?
>>
>> I know tmpfs is larger, but at least it should be an option.
>>
>> Also, tar should be an option instead of cpio for the archiver,
>> because tar is more widely used.
>You forgot to
On Tue, Aug 23, 2005 at 05:16:05PM -0400, [EMAIL PROTECTED] wrote:
> Why doesn't initramfs use tmpfs instead of ramfs, because
> tmpfs is more robust?
>
> I know tmpfs is larger, but at least it should be an option.
>
> Also, tar should be an option instead of cpio for the archiver,
> because tar
Why doesn't initramfs use tmpfs instead of ramfs, because
tmpfs is more robust?
I know tmpfs is larger, but at least it should be an option.
Also, tar should be an option instead of cpio for the archiver,
because tar is more widely used.
-
To unsubscribe from this list: send the line "unsubscr
48 matches
Mail list logo
