No, no.....make the bad man stop.
>Anyway the point is a non-libc untar
>should be as easy from userspace as the kernel since the hard part is limiting
>your program to kernel syscalls. In fact, it probably easier from userspace.
Well that's the problem. We don't know the kernel syscalls to use.
Now I have managed to modify (by some miricle) the rd.c code, and figured out
how to open /dev/ram1 with a struct file etc. This is all raw file access. No
filesystem involved. Example:
//dc: get /dev/ram1 ready as outfile
out_inode.i_rdev = MKDEV(MAJOR_NR,1);
outfile.f_mode = 3; /* read/write */
outfile.f_inode = &out_inode;
//dc: write a byte
outfile.f_op->write(outfile.f_inode, &outfile, &c, 1);
etc, etc. The point I'm at now is the main tar.gz was uncompressed to /dev/ram1.
Now what I need to do is extract it to the root. (/dev/ram0 which is by now has
Minix on it)
Do I use the same scheme as this and just spec something different for
out_inode.i_rdev ? What do I spec?
And then next issue where do I find info on how to use the inode functions?
I can find the prototypes in fs.h but they are not commented as to what the values
should be.
Are we talking about something like this? (guessing at the function calls)
fs = get_fs();
set_fs(KERNEL_DS);
ROOT_DEV = MKDEV(MAJOR_NR,0);
out_inode.i_rdev = ROOT_DEV;
outfile.f_mode = 3; /* read/write */
outfile.f_inode = &out_inode;
outfile.f_inode->i_op->create(outfile.f_inode, tarInfo->header.name,
fsize, 0, &outfile.f_inode );
outfile.f_inode->i_op->mkdir(outfile.f_inode, tarInfo->header.name,
fsize, fmode);
set_fs(fs);
>Well some will argue there is no reason to add such things to the
>kernal when it can be done from userspace.
The point is cleanly getting to user space in the first place. The way I'm doing it
now uses a boot strap raw image that mounts the disk and looks for the main
tar.gz. Friggin ugly. Without the untar in the kernel I can never fully get rid of raw
images.
>I think your idea is very cool but it will meet with much resistance if
>you want it in the kernel proper. Good luck.
I don't know why, as gunzip (cramdisk) support is already in. The whole point I'm
doing this is for the linux router project, in which the entire root is in tar.gz
archives, that are expanded into the ramdisk at boot time. It runs out of ram, and
then when changes are made it's back-up to the disk. Dealing with rawimages is
ungodly. It's much easier to just make a tar.gz a plop it in. Once this is done I
expect the major ditributions to move to it quicky for their install/rescue disks.
-------------------------------------------------------------------------
http://www.psychosis.com/emc/ Elite MicroComputers 908-541-4214
http://www.psychosis.com/linux-router/ Linux Router Project