Re: Linux 2.1.0 Compilation problem

george h byrkit (ghbyrkit@cris.com)
Tue, 01 Oct 1996 10:10:47 -0400

Erik B. Andersen wrote:
>
> I just picked up the brand new patch-2.0.21-2.1.0.gz and patched a clean
> version of 2.0.21 (I cheated, and renamed patch-2.0.21-2.1.0.gz to
> patch-2.0.22.gz and just used the patch-kernel script). Anyway, I compiled it
> the exact way I always compile a new kernel, everything that can be made into
> modules (at least stuff that I use) I make as modules, except for the ext2
> filesystem (I wouldn't want that as a module right now...) . The kernel built
> just fine. However, I got the following error compiling the umsdos module:
>
> make[2]: Entering directory `/usr/src/linux/fs/umsdos'
> gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strength-reduce -pipe -m486 -DCPU=486 -DMODULE -DMODVERSIONS -include /usr/src/linux/include/linux/modversions.h -c -o emd.o emd.c
> emd.c:31: conflicting types for `umsdos_file_read_kmem'
> /usr/src/linux/include/linux/umsdos_fs.p:26: previous declaration of `umsdos_file_read_kmem'
> emd.c:47: conflicting types for `umsdos_file_write_kmem'
> /usr/src/linux/include/linux/umsdos_fs.p:30: previous declaration of `umsdos_file_write_kmem'
> emd.c:68: conflicting types for `umsdos_emd_dir_write'
> /usr/src/linux/include/linux/umsdos_fs.p:34: previous declaration of `umsdos_emd_dir_write'
> emd.c:84: conflicting types for `umsdos_emd_dir_read'
> /usr/src/linux/include/linux/umsdos_fs.p:38: previous declaration of `umsdos_emd_dir_read'
> make[2]: *** [emd.o] Error 1
>
> A quick glance at the source code shows real differences between the type
> declarations in /usr/src/linux/fs/umsdos/emd.c and the declarations in
> /usr/src/linux/include/linux/umsdos_fs.p
>
> Assuming that the declarations introduced into umsdos_fs.p from the new patch
> are those that are intended to be in effect, a few changes to emd.c are then in
> order. The following patch allows it to compile with no warnings. I havn't yet
> tested if umsdos works with these changes...
> -Erik
>
> --
> Erik B. Andersen Web: http://www.et.byu.edu/~andersee/
> 2485 South State St. email: andersee@et.byu.edu
> Springville, Ut 84663 phone: (801) 489-1231
> --This message was written using 73% post-consumer electrons--
>
> [Patch Follows]
> --- /usr/src/linux/fs/umsdos/emd.c.orig Mon Sep 30 15:53:26 1996
> +++ /usr/src/linux/fs/umsdos/emd.c Mon Sep 30 16:30:00 1996
> @@ -23,11 +23,10 @@
> /*
> Read a file into kernel space memory
> */
> -int umsdos_file_read_kmem(
> - struct inode *inode,
> +long umsdos_file_read_kmem (struct inode *inode,
> struct file *filp,
> char *buf,
> - int count)
> + unsigned long count)
> {
> int ret;
> int old_fs = get_fs();
> @@ -39,11 +38,10 @@
> /*
> Write to a file from kernel space
> */
> -int umsdos_file_write_kmem(
> - struct inode *inode,
> +long umsdos_file_write_kmem (struct inode *inode,
> struct file *filp,
> const char *buf,
> - int count)
> + unsigned long count)
> {
> int ret;
> int old_fs = get_fs();
> @@ -60,11 +58,10 @@
>
> Return 0 if ok, a negative error code if not.
> */
> -int umsdos_emd_dir_write (
> - struct inode *emd_dir,
> +long umsdos_emd_dir_write (struct inode *emd_dir,
> struct file *filp,
> char *buf, /* buffer in kernel memory, not in user space */
> - int count)
> + unsigned long count)
> {
> int written;
> filp->f_flags = 0;
> @@ -76,18 +73,17 @@
> The block of data is NOT in user space.
> Return 0 if ok, -EIO if any error.
> */
> -int umsdos_emd_dir_read (
> - struct inode *emd_dir,
> +long umsdos_emd_dir_read (struct inode *emd_dir,
> struct file *filp,
> char *buf, /* buffer in kernel memory, not in user space */
> - int count)
> + unsigned long count)
> {
> - int ret = 0;
> + long int ret = 0;
> int sizeread;
> filp->f_flags = 0;
> sizeread = umsdos_file_read_kmem (emd_dir,filp,buf,count);
> if (sizeread != count){
> - printk ("UMSDOS: problem with EMD file. Can't read pos = %Ld (%d != %d)\n"
> + printk ("UMSDOS: problem with EMD file. Can't read pos = %Ld (%d != %ld)\n"
> ,filp->f_pos,sizeread,count);
> ret = -EIO;
> }

I think you have the right idea here, but didn't carry the concept far
enough. Don't the values used to generate a return value and hold
intermediate results need to be changed, too? umsdos_file_read_kmem
returns a long. You don't want to assign it to an int, even if on some
platforms they are the same.

I also found similar problems with linux/drivers/scsi/sg.c and st.c.
The definition of a 'file_operations' structure has changed, so that
read and write now return a 'long' instead of an 'int'. This occurs for
functions sg_read, sg_write, st_read, and st_write. Now, fortunately
these were only warnings...

Regards,
George Byrkit