mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ivan Gyurdiev <ivangurdiev@attbi.com>
To: LKML <linux-kernel@vger.kernel.org>, <fabbione@fabbione.net>
Subject: Re: linux 2.5.25 (different compilation errors)
Date: Fri, 5 Jul 2002 04:38:48 -0400	[thread overview]
Message-ID: <200207050438.48989.ivangurdiev@attbi.com> (raw)

Hmm. Haven't received this message. Reading it on LKML.
Please cc, I'm not subscribed.


> iforce-packets.c:252: `IFORCE_USB' undeclared (first use in this function)
> iforce-packets.c:252: (Each undeclared identifier is reported only once
> iforce-packets.c:252: for each function it appears in.)
> iforce-packets.c:282: `IFORCE_232' undeclared (first use in this function)
> iforce-packets.c:278: warning: unreachable code at beginning of switch
> statement

Well, obviously the construct


switch (iforce->bus)

case CONSTANT:

#ifdef CONSTANT
do stuff
#endif

will not work.

Why is all this #ifdef mess necessary.
Those are recognition constants.
How can you compare iforce->bus to IFORCE_USB or IFORCE_232
if those are only defined sometimes, based on config options...

Why not just...
#if defined(CONFIG_JOYSTICK_IFORCE_232)
#define IFORCE_232      1
#endif
#if defined(CONFIG_JOYSTICK_IFORCE_USB)
#define IFORCE_USB      2
#endif

drop the if statements and always define the constants.
The code will get much simpler IMHO.

===========================================

> zr36120.c:1497: unknown field `open' specified in initializer 
zr36120.c:1497: warning: initialization makes integer from pointer without a 
cast zr36120.c:1498: unknown field `close' specified in initializer 
zr36120.c:1498: warning: initialization from incompatible pointer type
>
> [SNIP]
>
> zr36120.c:1839: unknown field `minor' specified in initializer make[3]: *** 
[zr36120.o] Error 1

Here's what I found in the 2.4 videodev.h:
   /* old, obsolete interface -- dropped in 2.5.x, don't use it */
        int (*open)(struct video_device *, int mode);
        void (*close)(struct video_device *);
...
 /* new interface -- we will use file_operations directly
         * like soundcore does.
         * kernel_ioctl() will be called by video_generic_ioctl.
         * video_generic_ioctl() does the userspace copying of the
         * ioctl arguments */

============================================


             reply	other threads:[~2002-07-06  8:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-05  8:38 Ivan Gyurdiev [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-07-05  4:47 linux 2.5.25 Ivan Gyurdiev
2002-07-06  5:45 ` linux 2.5.25 (different compilation errors) Fabio Massimo Di Nitto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200207050438.48989.ivangurdiev@attbi.com \
    --to=ivangurdiev@attbi.com \
    --cc=fabbione@fabbione.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®