mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Gabriel Paubert <paubert@iram.es>
To: "H. Wiese" <7.e.Q@syncro-community.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: IP Layer on VME-Bus
Date: Wed, 3 Nov 2004 17:13:04 +0100	[thread overview]
Message-ID: <20041103161304.GB8075@iram.es> (raw)
In-Reply-To: <33093.192.35.17.30.1099489553.squirrel@config.hostunreachable.de>

On Wed, Nov 03, 2004 at 02:45:53PM +0100, H. Wiese wrote:
> Hello,
> 
> we develop a driver which enables us to use an ip layer on top of the vme-bus
> technology. Now we got some problems with coding the driver. We already have
> an old version of this driver (called "dpn") which works well but has no use
> for us anymore since we upgraded our system from kernel 2.2.14 to 2.6.7. So
> now we have to create a new driver.
> 
> The old driver established the ip layer by accessing the dual port ram of
> the VME bus, which is based on a Tundra Universe II Chipset. This enables
> us to transfer data, ping etc. between active VME-modules using the
> VME-bus. Very useful.

Which Universe driver did you use? 

There are several floating around, mine among them. I plan to port 
it to 2.6, time permitting but I'm a bit worried by the size of the 
kernel these days. I have to run diskless systems with 16MB of RAM, 
my 2.2 kernels are about 800kB while the 2.6 kernels on my Mac are 
in the 5MB or more range. Even after removing USB, ext3 and a few 
other things, the 2.6.x kernel will be at least twice the size of 
the 2.2 series it seems.

With my Universe driver or anything derived from it, the thing to 
watch out for is the PCI memory space allocation, 2.2 simply did 
not have the support (it mostly used the thing as the BIOS/firmware
had configures it) and the Universe is a PCI mmio space hog with
base registers outside the standard PCI header space (there are 
valid reasons for both of these characteristics). 

> Well, the problem we will surely run into is: will the driver work as fine as
> the old one if we only recreate the initialization functions working with the
> new kernel function set (e.g. wait_event_interruptible instead of
> interruptible_sleep_on etc.), copy the essential functions from the old
> driver
> to the new one and alter them a little to work with the new kernel functions?

I'm already using wait_event_ and friends in my 2.2 drivers,
you should select a better example ;-)

	Regards,
	Gabriel

      parent reply	other threads:[~2004-11-03 16:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-03 13:45 H. Wiese
2004-11-03 14:48 ` linux-os
2004-11-03 16:13 ` Gabriel Paubert [this message]

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=20041103161304.GB8075@iram.es \
    --to=paubert@iram.es \
    --cc=7.e.Q@syncro-community.de \
    --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®