klibc - Sep 2004 - [PATCH] gen_init_cpio processes file from a file list

The patch makes gen_init_cpio generate the initramfs_data.cpio from a
file which contains a list of entries: file, dir, nod.  I swapped the
order of filename/location for the file arguments so that it would be
more uniform with the dir and nod tyes.

[thayne@torch linux-2.6.8]$ usr/gen_init_cpio --help
ERROR: unable to open '--help': No such file or directory

Usage:
        usr/gen_init_cpio <cpio_list>

<cpio_list> is a file containing newline separated entries that
describe the files to be included in the initramfs archive:

file <name> <location> <mode> <uid> <gid>
dir <name> <mode> <uid> <gid>
nod <name> <mode> <uid> <gid> <dev_type>
<maj> <min>

<name>      name of the file/dir/nod in the archive
<location>  location of the file in the current filesystem
<mode>      mode/permissions of the file
<uid>       user id (0=root)
<gid>       group id (0=root)
<dev_type>  device type (b=block, c=character)
<maj>       major number of nod
<min>       minor number of nod

example:
dir /dev 0755 0 0
nod /dev/console 0600 0 0 c 5 1
dir /root 0700 0 0
dir /sbin 0755 0 0
file /sbin/kinit /usr/src/klibc/kinit/kinit 0755 0 0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpio_list.patch
Type: text/x-patch
Size: 8770 bytes
Desc: 
Url :
http://www.zytor.com/pipermail/klibc/attachments/20040916/cfccbd87/cpio_list.bin

> @@ -1,3 +1,4 @@
> +#define _GNU_SOURCE
>  #include <stdio.h>
In general the executables in the kernel shall be able to compile on 
solaris, cygwin and Linux.

Will usage of _GNU_SOURCE prevent this?

I do not have cygwin on my Windoze box, and no Solaris around.

	Sam

On Thu, Sep 16, 2004 at 11:51:38PM +0200, Sam Ravnborg
wrote:
> > @@ -1,3 +1,4 @@
> > +#define _GNU_SOURCE
> >  #include <stdio.h>
> 
> In general the executables in the kernel shall be able to compile on 
> solaris, cygwin and Linux.
> 
> Will usage of _GNU_SOURCE prevent this?
I believe the reason _GNU_SOURCE is defined is that the code is using
the GNU "getline" function.  getline is non-standard and does not
appear to exist on Solaris 9.

Some other potential issues that gcc notices:

  - the patch introduces three sscanf calls that assume uid_t and
    gid_t are really "int".

  - if you compile on Linux with -std=c99 or -std=c89, the
    definitions of things like S_IFBLK and S_IFCHR get hidden.
    Setting _XOPEN_SOURCE will make them visible again.

                                                  -Dave Dodge

Dave Dodge wrote:
> 
> I believe the reason _GNU_SOURCE is defined is that the code is using
> the GNU "getline" function.  getline is non-standard and does not
> appear to exist on Solaris 9.
> 
Yes, use fgets() instead.

	-hpa