All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Albert Cahalan <albert@users.sourceforge.net>
Cc: Albert Cahalan <albert@users.sourceforge.net>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] /proc/bus/pci* changes
Date: Mon, 14 Jul 2003 10:38:13 -0700	[thread overview]
Message-ID: <20030714173812.GA24142@kroah.com> (raw)
In-Reply-To: <1058161200.749.1454.camel@cube>

On Mon, Jul 14, 2003 at 01:40:01AM -0400, Albert Cahalan wrote:
> 
> The directory structure may well be finished,
> at least until it is time to remove the old
> interfaces. (in a few years I guess)
> 
> What's missing is the ability to pass cache-control
> info through the mmap() interface. This is useful
> for non-PCI purposes as well. Some thought will be
> required, as there is a set of commonly useful
> settings among all the arch-specific features.

Why would userspace want to do this?  Any examples?

> > And are you prepared to patch all of
> > the userspace programs that currently rely on the existing interface
> > (like XFree86 for one)?
> 
> The existing interface STILL WORKS. Apps can
> transition over time, in part or in whole.
> ("in part" meaning to use the old hacks on
> the new pathname, gaining PCI domain support)
> 
> It's important to get the new interface in
> ASAP, so that all the obscure (in-house, etc.)
> user-space drivers can start to transition.
> The X server is less of a worry, because it
> is a very active project.
> 
> > Also, I don't think you are handling the pci domain space in your patch,
> > or am I just missing it?
> 
> You missed it: third paragraph, first email
> 
> Example:
> You have two devices with the same bus
> number (5), device number (4), and function
> number (2). One is in domain 0, and the
> other is in domain 42. You get:
> 
> pci0/bus5/dev4/fn2/config-space
> pci42/bus5/dev4/fn2/config-space
> 
> Depending on what pci_name_bus does with
> the conflict, you'll get one or two symlinks
> from the old name(s). You'll also get some
> correctly-sized files to represent the
> resources. For example:
> 
> pci0/bus5/dev4/fn2/bar0
> pci0/bus5/dev4/fn2/bar1
> pci0/bus5/dev4/fn2/bar2
> pci42/bus5/dev4/fn2/bar0

Any reason for not using the same sysfs naming scheme to keep things
universal?

> Here's an attachment:

Which can't be quoted :(

Anyway, I really don't like the huge array you are declaring if we have
pci domains.  And I really don't want to apply this until someone shows
me a real use for it.  Maybe we should add mmap functions to sysfs?  :)

thanks,

greg k-h

      reply	other threads:[~2003-07-14 17:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-14  3:51 [PATCH] /proc/bus/pci* changes Albert Cahalan
2003-07-14  4:53 ` Greg KH
2003-07-14  5:40   ` Albert Cahalan
2003-07-14 17:38     ` Greg KH [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=20030714173812.GA24142@kroah.com \
    --to=greg@kroah.com \
    --cc=albert@users.sourceforge.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 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.