public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Hans J. Koch" <hjk@linutronix.de>
To: Greg KH <gregkh@suse.de>
Cc: "Hans J. Koch" <hjk@linutronix.de>,
	linux-kernel@vger.kernel.org, Mike Frysinger <vapier@gentoo.org>,
	John Ogness <jogness@linutronix.de>,
	Benedikt Spranger <b.spranger@linutronix.de>
Subject: Re: [PATCH RFC] UIO: Pass information about ioports to userspace
Date: Mon, 24 Nov 2008 11:19:15 +0100	[thread overview]
Message-ID: <20081124101914.GC3086@local> (raw)
In-Reply-To: <20081124014054.GA14143@suse.de>

On Sun, Nov 23, 2008 at 05:40:54PM -0800, Greg KH wrote:
> On Sun, Nov 23, 2008 at 01:14:20PM +0100, Hans J. Koch wrote:
> > Devices sometimes have memory where all or parts of it can not be mapped to
> > userspace. But it might still be possible to access this memory from
> > userspace by other means. An example are PCI cards that advertise not only
> > mappable memory but also ioport ranges. On x86 architectures, these can be
> > accessed with ioperm, iopl, inb, outb, and friends. Mike Frysinger (CCed)
> > reported a similar problem on Blackfin arch where it doesn't seem to be easy
> > to mmap non-cached memory but it can still be accessed from userspace.
> > 
> > This patch allows kernel drivers to pass information about such ports to
> > userspace. Similar to the existing mem[] array, it adds a port[] array to
> > struct uio_info. Each port range is described by start, size, and porttype.
> > 
> > If a driver fills in at least one such port range, the UIO core will simply
> > pass this information to userspace by creating a new directory "portio"
> > underneath /sys/class/uio/uioN/. Similar to the "mem" directory, it will
> > contain a subdirectory (portX) for each port range given.
> 
> This is good, but it would really be nice to provide a way for userspace
> to access individual ports without having to have access to all ports in
> the system.  Lots of times we don't want to give root privileges to some
> programs that only need to read and write simple data to a single
> device.

Yes, of course, that'd be nice. But it's very much arch dependent. For
example, these x86 ioports need special handling on x86, but you can simply
mmap them on powerpc. Port-like memory ranges on other archs might require
something completely different.
Yes, some generic port access layer would really be good, but I'm not sure
if the UIO core is the right place to implement it. Do you already have a
solution in mind?
Maybe we can look at that in a second step. ATM I just want to avoid these
situations where userspace needs ugly tricks to find out which ioports
belong to a certain card.

Thanks,
Hans

  reply	other threads:[~2008-11-24 10:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-23 12:14 [PATCH RFC] UIO: Pass information about ioports to userspace Hans J. Koch
2008-11-24  1:40 ` Greg KH
2008-11-24 10:19   ` Hans J. Koch [this message]
2008-11-25  4:11     ` Greg KH
2008-11-25 23:56       ` Hans J. Koch
2008-11-24  1:41 ` Greg KH
2008-11-24  9:04   ` Hans J. Koch
2008-12-06  1:23 ` [PATCH 1/2] UIO: Pass information about ioports to userspace (V2) Hans J. Koch
2008-12-06  1:25   ` [PATCH 2/2] UIO: Documentation for UIO ioport info handling Hans J. Koch
2008-12-22 19:03     ` Randy Dunlap

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=20081124101914.GC3086@local \
    --to=hjk@linutronix.de \
    --cc=b.spranger@linutronix.de \
    --cc=gregkh@suse.de \
    --cc=jogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vapier@gentoo.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