netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mirko Lindner <mlindner@syskonnect.de>
To: Christoph Hellwig <hch@infradead.org>,
	Stephen Hemminger <shemminger@osdl.org>
Cc: Jeff Garzik <jgarzik@pobox.com>,
	Mirko Lindner <demon@pro-linux.de>,
	netdev@oss.sgi.com, Ralph Roesler <rroesler@syskonnect.de>
Subject: Re: [PATCH] (4/25) sk98: change #define to typedef
Date: Tue, 16 Nov 2004 15:56:15 +0000	[thread overview]
Message-ID: <419A231F.4020104@syskonnect.de> (raw)

 > I don't think the driver is complex enough for all that os-common mess.
 > If you look at the BSD sk driver it's about a third of the size of the
 > Linux driver because it doesn't have all this mess.

Note that the kernel BSD sk driver was _not_ written by SysKonnect and 
only supports Genesis and Yukon1; linux supports Genesis (single and 
dual), Yukon1, Yukon Plus, Yukon EC, Yukon FE and Yukon2 (single and 
dual). The BSD sk driver supports substantially less functionality than 
the Linux driver. For example, there is no link failover capability in 
the sk driver; it has no power management; numerous chip changes and 
minor tweaks have not been added, since many problems have become 
apparent through our other supported platforms (some 15 operating 
systems) and have since been fixed in our common modules; sk has no 
wake-on-LAN and so on. The official SysKonnect BSD driver (yk) also uses 
the common modules and is not open source.

However, the real point is that the Linux driver (as indeed _all_ of our 
drivers) shares common code with all our supported platforms and this 
necessarily introduces some overhead. But it isn't excessive, and the 
benefits _far_ outweigh the drawbacks, namely, that we have a very wide 
range of systems sharing common code and thus the probability of finding 
and fixing bugs is very substantially higher than if we wrote a 
dedicated driver for each platform.

For instance the symbol SK_IOC mentioned in your mail:

 > -#define SK_IOC char __iomem *
 > +typedef void __iomem *SK_IOC;

is used in a large number of OS independent driver files (e.g. skvpd.c).
The -for instance- file skvpd.c used by our Linux driver is used
at the same time without any changes by all our other drivers running
on other operating systems (e.g. Solaris, Windows).

This is the reason why we need to redefine this symbol to the Linux
specific implementation (void __iomem).

Mirko

             reply	other threads:[~2004-11-16 15:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-16 15:56 Mirko Lindner [this message]
2004-11-16 17:12 ` [PATCH] (4/25) sk98: change #define to typedef Stephen Hemminger
2004-11-17 15:01 ` Christoph Hellwig
2004-11-19  0:23   ` Stephen Hemminger
     [not found] <20041115150910.0f3b8498@zqx3.pdx.osdl.net>
2004-11-15 23:22 ` Stephen Hemminger
2004-11-16  8:22   ` Christoph Hellwig

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=419A231F.4020104@syskonnect.de \
    --to=mlindner@syskonnect.de \
    --cc=demon@pro-linux.de \
    --cc=hch@infradead.org \
    --cc=jgarzik@pobox.com \
    --cc=netdev@oss.sgi.com \
    --cc=rroesler@syskonnect.de \
    --cc=shemminger@osdl.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;
as well as URLs for NNTP newsgroup(s).