All of lore.kernel.org
 help / color / mirror / Atom feed
From: rgroner@rtd.com (Rob Groner)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Did PCI/IRQ allocation change significantly after 4.2 kernel?
Date: Tue, 29 Mar 2016 16:11:22 -0400	[thread overview]
Message-ID: <1459282282.2010.37.camel@rtd-VirtualBox> (raw)
In-Reply-To: <20160329192244.GA31666@kroah.com>

On Tue, 2016-03-29 at 12:22 -0700, Greg KH wrote:
> On Tue, Mar 29, 2016 at 12:18:40PM -0700, Greg KH wrote:
> > > That is encouraging and persuasive.  I will make submitting the driver
> > > one of my pet projects.  I need to put a new coat of paint on it before
> > > I submit it for consideration, though.  Do I post to this mailing list
> > > when I'm ready?  Or is there a more pertinent one?
> > 
> > I can take it "as-is" through the staging tree (drivers/staging/) which
> > lets the community start to clean it up now, if you don't have the
> > time to do the work now.  Then you can work within the kernel
> > development process to polish up the remaining issues before we merge it
> > out of the staging tree into the "real" portion of the kernel.
> > 
> > If you are interested in this, just let me know.
> 
> In looking at your driver closer, what exactly is it doing?  At first
> glance, it seems to be just a bunch of ioctls to directly access the
> memory in the card, is that correct?  If so, why not just use the UIO
> layer instead?  If not, what is the driver trying to do?
> 
> thanks,
> 
> greg k-h

Your first glance is probably correct.  The driver handles reads and
writes to registers via IOCTLs from the user library, as well as
interrupts and DMA.  There are probably two main reasons the driver is
structured like that: 1) All "new" drivers here are essentially tailored
versions of previous drivers that have been around for a while, so this
wasn't built-from-scratch new.  While it means that any poor design
decisions made early on are perpetuated, it also means to us that we
aren't re-inventing the wheel and we're mostly using a driver that has
proven to work for quite a while.  2) The library code for the board is
shared (internally) with our Windows driver package, and in some cases
DOS too.  Since Windows uses IOCTLs, we can essentially share the exact
same library files, and only the IOCTL call itself is OS-specific.

I know #1 is not a good reason and I'd be happy to work towards
re-writing the driver in a more correct way, but probably not if it
would cause us to have to split into a Linux and Windows library
versions.  Keeping the library common at this point has saved us a lot
of development time.

I absolutely appreciate the feedback on driver design...I've never
really received any and all I know about Linux drivers is what I read
online, read in LDD, and what was in the drivers that existed when I
came to work here.  Is the current form of the driver just "bad" or
"intolerably bad"?

Thanks!

Rob

  reply	other threads:[~2016-03-29 20:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-29 14:15 Did PCI/IRQ allocation change significantly after 4.2 kernel? Rob Groner
2016-03-29 14:42 ` Greg KH
2016-03-29 14:43   ` Greg KH
2016-03-29 15:27     ` Rob Groner
2016-03-29 15:43       ` Greg KH
2016-03-29 18:27         ` Rob Groner
2016-03-29 18:38           ` Greg KH
2016-03-29 19:11             ` Rob Groner
2016-03-29 19:18               ` Greg KH
2016-03-29 19:22                 ` Greg KH
2016-03-29 20:11                   ` Rob Groner [this message]
2016-03-30  0:57                     ` Greg KH
2016-03-30 15:51                       ` Rob Groner
2016-04-02 22:26                         ` Greg KH
2016-03-30 21:24                       ` Rob Groner
2016-03-30 21:52                         ` Greg KH

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=1459282282.2010.37.camel@rtd-VirtualBox \
    --to=rgroner@rtd.com \
    --cc=kernelnewbies@lists.kernelnewbies.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.