At 3:26 AM -0400 2001-07-08, Alexander Viro wrote:
>On Sat, 7 Jul 2001, Jamie Lokier wrote:
>
>> Daniel Phillips wrote:
>> > > Reading a tarball is the distillation of what you describe into
>> > > efficient form :)
>> >
>> > /me downloads tar file definition
>> >
>> > Um, gnu tar or posix
On Sat, 7 Jul 2001, Jamie Lokier wrote:
> Daniel Phillips wrote:
> > > Reading a tarball is the distillation of what you describe into
> > > efficient form :)
> >
> > /me downloads tar file definition
> >
> > Um, gnu tar or posix tar? or some new, improved tar?
>
> I suggest cpio, which is
On Sat, 7 Jul 2001, Jamie Lokier wrote:
Daniel Phillips wrote:
Reading a tarball is the distillation of what you describe into
efficient form :)
/me downloads tar file definition
Um, gnu tar or posix tar? or some new, improved tar?
I suggest cpio, which is more compact and
At 3:26 AM -0400 2001-07-08, Alexander Viro wrote:
On Sat, 7 Jul 2001, Jamie Lokier wrote:
Daniel Phillips wrote:
Reading a tarball is the distillation of what you describe into
efficient form :)
/me downloads tar file definition
Um, gnu tar or posix tar? or some new,
[EMAIL PROTECTED] wrote:
> >> Would it be possible to use a cramfs image in vmlinux (i.e. real
> >> filesystem image, not an in-kernel-structures fs like ramfs), and map
> >> it directly from the kernel image (it would have to be suitably aligned,
> >> of course)?
>
> > Yes that would work, and
Mike Touloumtzis wrote:
> > Yes that would work, and it would work on machines with less RAM too.
> > You would want to remove the cramfs filesystem code when you're done though.
>
> Some of the files in the boot time FS would need to
> be kept around, such as the ACPI code, right?
Perhaps.
On Sat, Jul 07, 2001 at 11:53:29PM +0200, Jamie Lokier wrote:
> Mike Touloumtzis wrote:
> >
> > Would it be possible to use a cramfs image in vmlinux (i.e. real
> > filesystem image, not an in-kernel-structures fs like ramfs), and map
> > it directly from the kernel image (it would have to be
In article <[EMAIL PROTECTED]> you wrote:
>> Would it be possible to use a cramfs image in vmlinux (i.e. real
>> filesystem image, not an in-kernel-structures fs like ramfs), and map
>> it directly from the kernel image (it would have to be suitably aligned,
>> of course)?
> Yes that would work,
Mike Touloumtzis wrote:
> > > Doesn't the approach "treat a chunk of data built into bzImage as
> > > populated ramfs" look cleaner? No need to fiddle with tar format,
> > > no copying data from place to place.
> >
> > So tell me, how do you populate ramfs without a format which tells you
> >
Jamie Lokier writes:
> (tar has a silly pad-to-multiple-of-512-byte per file rule, which is
> inappropriate for this).
If you remember that 'tar' means "tape archiver", and that at the time
it was written the standard tape block size was 512 bytes, the rule
isn't silly at all, although it may
On Sat, Jul 07, 2001 at 07:34:38AM -0400, Jeff Garzik wrote:
> Eugene Crosser wrote:
> >
> > Doesn't the approach "treat a chunk of data built into bzImage as
> > populated ramfs" look cleaner? No need to fiddle with tar format,
> > no copying data from place to place.
>
> So tell me, how do
Daniel Phillips wrote:
> > Reading a tarball is the distillation of what you describe into
> > efficient form :)
>
> /me downloads tar file definition
>
> Um, gnu tar or posix tar? or some new, improved tar?
I suggest cpio, which is more compact and in some ways more standard.
(tar has a silly
On Saturday 07 July 2001 15:50, Jeff Garzik wrote:
> Eugene Crosser wrote:
> > In article
> > <[EMAIL PROTECTED]>,
> >
> > Alexander Viro <[EMAIL PROTECTED]> writes:
> > >> Doesn't the approach "treat a chunk of data built into bzImage
> > >> as populated ramfs" look cleaner? No need to
Eugene Crosser wrote:
>
> In article <[EMAIL PROTECTED]>,
> Alexander Viro <[EMAIL PROTECTED]> writes:
>
> >> Doesn't the approach "treat a chunk of data built into bzImage as
> >> populated ramfs" look cleaner? No need to fiddle with tar format,
> >> no copying data from place to
In article <[EMAIL PROTECTED]>,
Alexander Viro <[EMAIL PROTECTED]> writes:
>> Doesn't the approach "treat a chunk of data built into bzImage as
>> populated ramfs" look cleaner? No need to fiddle with tar format,
>> no copying data from place to place.
>
> What the hell _is_ "populated
Eugene Crosser wrote:
>
> In article <[EMAIL PROTECTED]>,
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > I don't like the current initrd very much myself, I have to admit. I'm not
> > going to accept a "you have to have a ramdisk" approach - I think the
> > ramdisks are really
On 7 Jul 2001, Eugene Crosser wrote:
> Doesn't the approach "treat a chunk of data built into bzImage as
> populated ramfs" look cleaner? No need to fiddle with tar format,
> no copying data from place to place.
What the hell _is_ "populated ramfs"? The thing doesn't live in array
of blocks.
In article <[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]> writes:
> I don't like the current initrd very much myself, I have to admit. I'm not
> going to accept a "you have to have a ramdisk" approach - I think the
> ramdisks are really broken.
>
> But I've seen a "populate
In article [EMAIL PROTECTED],
Linus Torvalds [EMAIL PROTECTED] writes:
I don't like the current initrd very much myself, I have to admit. I'm not
going to accept a you have to have a ramdisk approach - I think the
ramdisks are really broken.
But I've seen a populate ramfs from a
On 7 Jul 2001, Eugene Crosser wrote:
Doesn't the approach treat a chunk of data built into bzImage as
populated ramfs look cleaner? No need to fiddle with tar format,
no copying data from place to place.
What the hell _is_ populated ramfs? The thing doesn't live in array
of blocks. Its
Eugene Crosser wrote:
In article [EMAIL PROTECTED],
Linus Torvalds [EMAIL PROTECTED] writes:
I don't like the current initrd very much myself, I have to admit. I'm not
going to accept a you have to have a ramdisk approach - I think the
ramdisks are really broken.
But I've
In article [EMAIL PROTECTED],
Alexander Viro [EMAIL PROTECTED] writes:
Doesn't the approach treat a chunk of data built into bzImage as
populated ramfs look cleaner? No need to fiddle with tar format,
no copying data from place to place.
What the hell _is_ populated ramfs? The
Eugene Crosser wrote:
In article [EMAIL PROTECTED],
Alexander Viro [EMAIL PROTECTED] writes:
Doesn't the approach treat a chunk of data built into bzImage as
populated ramfs look cleaner? No need to fiddle with tar format,
no copying data from place to place.
What the
On Saturday 07 July 2001 15:50, Jeff Garzik wrote:
Eugene Crosser wrote:
In article
[EMAIL PROTECTED],
Alexander Viro [EMAIL PROTECTED] writes:
Doesn't the approach treat a chunk of data built into bzImage
as populated ramfs look cleaner? No need to fiddle with tar
Daniel Phillips wrote:
Reading a tarball is the distillation of what you describe into
efficient form :)
/me downloads tar file definition
Um, gnu tar or posix tar? or some new, improved tar?
I suggest cpio, which is more compact and in some ways more standard.
(tar has a silly
On Sat, Jul 07, 2001 at 07:34:38AM -0400, Jeff Garzik wrote:
Eugene Crosser wrote:
Doesn't the approach treat a chunk of data built into bzImage as
populated ramfs look cleaner? No need to fiddle with tar format,
no copying data from place to place.
So tell me, how do you populate
Jamie Lokier writes:
(tar has a silly pad-to-multiple-of-512-byte per file rule, which is
inappropriate for this).
If you remember that 'tar' means tape archiver, and that at the time
it was written the standard tape block size was 512 bytes, the rule
isn't silly at all, although it may be
Mike Touloumtzis wrote:
Doesn't the approach treat a chunk of data built into bzImage as
populated ramfs look cleaner? No need to fiddle with tar format,
no copying data from place to place.
So tell me, how do you populate ramfs without a format which tells you
what path and
In article [EMAIL PROTECTED] you wrote:
Would it be possible to use a cramfs image in vmlinux (i.e. real
filesystem image, not an in-kernel-structures fs like ramfs), and map
it directly from the kernel image (it would have to be suitably aligned,
of course)?
Yes that would work, and it
On Sat, Jul 07, 2001 at 11:53:29PM +0200, Jamie Lokier wrote:
Mike Touloumtzis wrote:
Would it be possible to use a cramfs image in vmlinux (i.e. real
filesystem image, not an in-kernel-structures fs like ramfs), and map
it directly from the kernel image (it would have to be suitably
[EMAIL PROTECTED] wrote:
Would it be possible to use a cramfs image in vmlinux (i.e. real
filesystem image, not an in-kernel-structures fs like ramfs), and map
it directly from the kernel image (it would have to be suitably aligned,
of course)?
Yes that would work, and it would work
Mike Touloumtzis wrote:
Yes that would work, and it would work on machines with less RAM too.
You would want to remove the cramfs filesystem code when you're done though.
Some of the files in the boot time FS would need to
be kept around, such as the ACPI code, right?
Perhaps. They
On Friday 06 July 2001 13:16, Alan Cox wrote:
> > I am convinced. I misunderstood, thinking there was a big change just
> > for
> > ACPI which I and many others don't use. Thanks for clearing things up.
>
> It solves a few long standing arguments too - we can slap .config in it
> ending the
> I am convinced. I misunderstood, thinking there was a big change just
> for
> ACPI which I and many others don't use. Thanks for clearing things up.
It solves a few long standing arguments too - we can slap .config in it
ending the long standing /proc/config argument without using any ram
Linus Torvalds wrote:
> You would never even know the difference. You'd do a "make bzImage", and
> the default filesystem would just be embedded into the image. By default
> it probably doesn't need to do much - although things like the BIOS DPMI
> scan etc would surely be good to get rid of.
>
>
>Nope.
>
>I do not want to maintain two interfaces. If we make user space the way to
>do these things, then we will do pretty much most of the driver setup etc
>in user space. We'd have to: we'd enter user space before drivers have had
>a chance to initialize, exactly because "features like
Nope.
I do not want to maintain two interfaces. If we make user space the way to
do these things, then we will do pretty much most of the driver setup etc
in user space. We'd have to: we'd enter user space before drivers have had
a chance to initialize, exactly because features like these can
Linus Torvalds wrote:
You would never even know the difference. You'd do a make bzImage, and
the default filesystem would just be embedded into the image. By default
it probably doesn't need to do much - although things like the BIOS DPMI
scan etc would surely be good to get rid of.
Why
I am convinced. I misunderstood, thinking there was a big change just
for
ACPI which I and many others don't use. Thanks for clearing things up.
It solves a few long standing arguments too - we can slap .config in it
ending the long standing /proc/config argument without using any ram
On Friday 06 July 2001 13:16, Alan Cox wrote:
I am convinced. I misunderstood, thinking there was a big change just
for
ACPI which I and many others don't use. Thanks for clearing things up.
It solves a few long standing arguments too - we can slap .config in it
ending the long
Jeff writes:
> I've always thought it would be neat to do:
>
> cat bzImage initrd.tar.gz > vmlinuz
> rdev --i-have-a-tarball-piggyback vmlinuz
>
> Linking into the image is easy for hackers, but why not make it
> scriptable and super-easy for end users? x86 already has the rdev
>
On Thu, 5 Jul 2001, Helge Hafting wrote:
>
> I am fine with "You have to use initrd (or similiar) _if_ you want this
> feature."
Nope.
I do not want to maintain two interfaces. If we make user space the way to
do these things, then we will do pretty much most of the driver setup etc
in user
On Thu, 5 Jul 2001, Helge Hafting wrote:
> Linus Torvalds wrote:
> [...]
> > We migth want to just make initrd a built-in thing in the kernel,
> > something that you simply cannot avoid. A lot of these things (ie dhcp for
> > NFS root etc) are right now done in kernel space, simply because we
> But please don't make initrd mandatory for those of us who don't
> need ACPI, don't need dhcp before mounting disks and so on.
>
> I hope the "fs-less" kernel image still will be possible for those
> of us who have a simple setup.
If we can do that kind of early boot user space then stuff
Helge Hafting wrote:
> I am fine with "You have to use initrd (or similiar) _if_ you want this
> feature."
> But please don't make initrd mandatory for those of us who don't
> need ACPI, don't need dhcp before mounting disks and so on.
I've always thought it would be neat to do:
cat
Linus Torvalds wrote:
[...]
> We migth want to just make initrd a built-in thing in the kernel,
> something that you simply cannot avoid. A lot of these things (ie dhcp for
> NFS root etc) are right now done in kernel space, simply because we don't
> want to depend on initrd, and people want to
Linus Torvalds wrote:
[...]
We migth want to just make initrd a built-in thing in the kernel,
something that you simply cannot avoid. A lot of these things (ie dhcp for
NFS root etc) are right now done in kernel space, simply because we don't
want to depend on initrd, and people want to use
Helge Hafting wrote:
I am fine with You have to use initrd (or similiar) _if_ you want this
feature.
But please don't make initrd mandatory for those of us who don't
need ACPI, don't need dhcp before mounting disks and so on.
I've always thought it would be neat to do:
cat bzImage
On Thu, 5 Jul 2001, Helge Hafting wrote:
Linus Torvalds wrote:
[...]
We migth want to just make initrd a built-in thing in the kernel,
something that you simply cannot avoid. A lot of these things (ie dhcp for
NFS root etc) are right now done in kernel space, simply because we don't
On Thu, 5 Jul 2001, Helge Hafting wrote:
I am fine with You have to use initrd (or similiar) _if_ you want this
feature.
Nope.
I do not want to maintain two interfaces. If we make user space the way to
do these things, then we will do pretty much most of the driver setup etc
in user space.
But please don't make initrd mandatory for those of us who don't
need ACPI, don't need dhcp before mounting disks and so on.
I hope the fs-less kernel image still will be possible for those
of us who have a simple setup.
If we can do that kind of early boot user space then stuff like
On Wed, 4 Jul 2001, Alan Cox wrote:
>
> > I argued this at the very beginning, but there was a very strong
> > view that you needed to run most of the code before you had a user
> > space to run it in. I've not followed things closely enough to
>
> That bit is clearly untrue.
It's untrue only
> I argued this at the very beginning, but there was a very strong
> view that you needed to run most of the code before you had a user
> space to run it in. I've not followed things closely enough to
That bit is clearly untrue.
> My feeling has been that ACPI has violated the minimum
> From: Alan Cox [SMTP:[EMAIL PROTECTED]]
>
> The goal isnt a technical nit, its to avoid loading 300Kbytes of crud
> (which
> should mostly be in user space anyway) on the 99.9% of machines where we
> dont
> need it.
[DJW:]
I argued this at the very beginning, but there was a very strong
From: Alan Cox [SMTP:[EMAIL PROTECTED]]
The goal isnt a technical nit, its to avoid loading 300Kbytes of crud
(which
should mostly be in user space anyway) on the 99.9% of machines where we
dont
need it.
[DJW:]
I argued this at the very beginning, but there was a very strong
view that
I argued this at the very beginning, but there was a very strong
view that you needed to run most of the code before you had a user
space to run it in. I've not followed things closely enough to
That bit is clearly untrue.
My feeling has been that ACPI has violated the minimum privilege
On Wed, 4 Jul 2001, Alan Cox wrote:
I argued this at the very beginning, but there was a very strong
view that you needed to run most of the code before you had a user
space to run it in. I've not followed things closely enough to
That bit is clearly untrue.
It's untrue only in the
57 matches
Mail list logo
