On the same topic, I have not found any change in free memory reported before
and after the ioctl call. Though umount /initrd does free around 2 MB.
Amit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On the same topic, I have not found any change in free memory reported before
and after the ioctl call. Though umount /initrd does free around 2 MB.
Amit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Hi,
After testing with patch-2.4.2-ac28, the df commands works fine on a dir
mounted as ramfs. Also, it recognizes the limits set, etc.
Thanks to David Gibson, Alan and others for making this available.
Regards
Amit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Hi,
After testing with patch-2.4.2-ac28, the df commands works fine on a dir
mounted as ramfs. Also, it recognizes the limits set, etc.
Thanks to David Gibson, Alan and others for making this available.
Regards
Amit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>(none):/mnt/ramfs/root# df -h /mnt/ramfs/
>FilesystemSize Used Avail Use% Mounted on
>ramfs0 0 0 - /mnt/ramfs
I am not sure, how related this is, but we have / on ramfs and using rpm
to install(-iUvh) fails with the mesages, need 12K on /
Amit
-
(none):/mnt/ramfs/root# df -h /mnt/ramfs/
FilesystemSize Used Avail Use% Mounted on
ramfs0 0 0 - /mnt/ramfs
I am not sure, how related this is, but we have / on ramfs and using rpm
to install(-iUvh) fails with the mesages, need 12K on /
Amit
-
To
Werner Almesberger wrote:
> Easy solution: don't run linuxrc, run something else instead. E.g.
> putting the following into the kernel's command line should do th
> trick:
> init=/your_script root=/dev/ram
>
> (With your_script being the original version, without real-root-dev)
This works.
Werner Almesberger wrote:
Easy solution: don't run linuxrc, run something else instead. E.g.
putting the following into the kernel's command line should do th
trick:
init=/your_script root=/dev/ram
(With your_script being the original version, without real-root-dev)
This works. And in a
Hi,
We(my team) had some questions regarding booting from initrd and using
/linuxrc. It will help someone(David, Werner,...) can give their
thoughts on this.
To put it in brief, since running sbin/init from /linuxrc as resulting
in init not having PID 1 and thereby not doing some
Hi,
We(my team) had some questions regarding booting from initrd and using
/linuxrc. It will help someone(David, Werner,...) can give their
thoughts on this.
To put it in brief, since running sbin/init from /linuxrc as resulting
in init not having PID 1 and thereby not doing some
> I don't know why the comparision is made though, they are used for two
> completely different things... ramfs is for temporary file storage, cramfs
> is for immutable files stored on flash. Each by itself is quite optimal
> for what it's designed for, isn't it ?
Exactly. My mistake earlier to
Hi David,
I did consider CRAMFS and JFFS2 when it was announced on the mtd list.
Conserving flash over system ram is more relevant. Our reasons are below:
RAMFS v/s CRAMFS
1. RAMFS is just more stable in terms of less complexity, less bugs reported
over the time, etc.
2. RAMFS is a fairly
Werner Almesberger wrote:
> Amit D Chaudhary wrote:
>> But other information in the
>> initrd.txt mentions otherwise, hence the query here.
>
>
> Hmm, sounds like a bug. Where did you find this ?
I quote from the version in linux-2.4.2-ac22
"
Now, the initrd ca
Werner Almesberger wrote:
Amit D Chaudhary wrote:
But other information in the
initrd.txt mentions otherwise, hence the query here.
Hmm, sounds like a bug. Where did you find this ?
I quote from the version in linux-2.4.2-ac22
"
Now, the initrd can be unmounted and the memory allo
Hi David,
I did consider CRAMFS and JFFS2 when it was announced on the mtd list.
Conserving flash over system ram is more relevant. Our reasons are below:
RAMFS v/s CRAMFS
1. RAMFS is just more stable in terms of less complexity, less bugs reported
over the time, etc.
2. RAMFS is a fairly
I don't know why the comparision is made though, they are used for two
completely different things... ramfs is for temporary file storage, cramfs
is for immutable files stored on flash. Each by itself is quite optimal
for what it's designed for, isn't it ?
Exactly. My mistake earlier to
the ramfs limits for now, will do soon.
Thanks
Amit
Werner Almesberger wrote:
> Amit D Chaudhary wrote:
>
>> what does redirecting stdin\stdout\stderr to dev/console achieve? I thought
>> since the root is now the "new" root, dev/console will be used automati
Hi,
Thanks for the response. PSB,
Werner Almesberger wrote:
> Amit D Chaudhary wrote:
>
> No, you would continue using the file descriptors which are already
> open, i.e. on /dev/console on the old root.
So, makes sense. And the child process that follow will use now the new fd
Hi,
I have a initrd working, a /linuxrc on it that runs and executes. My question
for the commands after pivot_root which works like a charm, thanks to initrd.txt,
what does redirecting stdin\stdout\stderr to dev/console achieve? I thought
since the root is now the "new" root, dev/console
Hi,
I have a initrd working, a /linuxrc on it that runs and executes. My question
for the commands after pivot_root which works like a charm, thanks to initrd.txt,
what does redirecting stdin\stdout\stderr to dev/console achieve? I thought
since the root is now the "new" root, dev/console
Hi,
Thanks for the response. PSB,
Werner Almesberger wrote:
Amit D Chaudhary wrote:
No, you would continue using the file descriptors which are already
open, i.e. on /dev/console on the old root.
So, makes sense. And the child process that follow will use now the new fd's.
Also, why
the ramfs limits for now, will do soon.
Thanks
Amit
Werner Almesberger wrote:
Amit D Chaudhary wrote:
what does redirecting stdin\stdout\stderr to dev/console achieve? I thought
since the root is now the "new" root, dev/console will be used automatically?
No, you would cont
Hi Arnaldo,
Thanks every much for the pointer. Yes, with 2.4.2-ac5 the problem is gone.
Also, there was another similar problem with lilo stalling that is gone too.
Regards
Amit
Arnaldo Carvalho de Melo wrote:
> Em Tue, Feb 27, 2001 at 06:25:08PM -0800, Amit D Chaudhary escreveu:
>
&
Hi Arnaldo,
Thanks every much for the pointer. Yes, with 2.4.2-ac5 the problem is gone.
Also, there was another similar problem with lilo stalling that is gone too.
Regards
Amit
Arnaldo Carvalho de Melo wrote:
Em Tue, Feb 27, 2001 at 06:25:08PM -0800, Amit D Chaudhary escreveu:
I am
Hi,
I am hoping someone knows more about this case. I have a intel pc
running linux 2.4 and the last command below hangs and the statements as
they are printed. Even kill -9 does not get it to terminate.
#touch img.test
#dd if=/dev/zero of=img.test bs=1k count=2000
2000+0 records in
2000+0
Hi,
I am hoping someone knows more about this case. I have a intel pc
running linux 2.4 and the last command below hangs and the statements as
they are printed. Even kill -9 does not get it to terminate.
#touch img.test
#dd if=/dev/zero of=img.test bs=1k count=2000
2000+0 records in
2000+0
why not
#include
Amit
"Heusden, Folkert van" wrote:
>
> I need to include (in a driver) a header-file from arch//subdir. I
> could, of course,
> do something like #include "../../arch/i386/{etc}" with a couple of #ifdef's
> to get things
> working for each environment. I guess that's now
why not
#include arch/i386/etc.h
Amit
"Heusden, Folkert van" wrote:
I need to include (in a driver) a header-file from arch/arch/subdir. I
could, of course,
do something like #include "../../arch/i386/{etc}" with a couple of #ifdef's
to get things
working for each environment. I guess
Sorry, I might not been clear enough, I meant the files are of size 0 in
the following file and also it's valinux mirror,
ftp://ftp.kernel.org/pub/linux/kernel/v2.2/linux-2.2.17.tar.gz
I did not patch the sources, I was just extracting the tar file.
Alan or someone who looks in the sources,
Hi,
When trying to create a patch with linux 2.2.17 sources, I found the
following files to be of size 0 in linux-2.2.17.tar.gz.
linux/include/linux/dasd.h
linux/include/linux/coda_opstats.h
Since the file is the most latest in the kernel/v2.2 directory, thought
should point this out.
Amit
Hi,
When trying to create a patch with linux 2.2.17 sources, I found the
following files to be of size 0 in linux-2.2.17.tar.gz.
linux/include/linux/dasd.h
linux/include/linux/coda_opstats.h
Since the file is the most latest in the kernel/v2.2 directory, thought
should point this out.
Amit
31 matches
Mail list logo
