From: Tony Mantler <nicoya@apia.dhs.org>
To: Oliver Xymoron <oxymoron@waste.org>,
"David S. Miller" <davem@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
<linuxppc-dev@lists.linuxppc.org>, <linux-kernel@vger.kernel.org>
Subject: Re: The IO problem on multiple PCI busses
Date: Tue, 6 Mar 2001 20:07:33 -0600 [thread overview]
Message-ID: <v04003a06b6cb43b4f87c@[24.70.162.12]> (raw)
In-Reply-To: <Pine.LNX.4.30.0103061657570.19700-100000@waste.org>
In-Reply-To: <15008.17278.154154.210086@pizda.ninka.net>
At 5:01 PM -0600 3/6/2001, Oliver Xymoron wrote:
>On Fri, 2 Mar 2001, David S. Miller wrote:
>
>> > On PPC, we don't have an "IO" space neither, all we have is a range of
>> > memory addresses that will cause IO cycles to happen on the PCI bus.
>>
>> This is precisely what the "next MMAP is XXX space" ioctl I've
>> suggested is for. I think I've addressed this concern in my
>> proposal already. Look:
>>
>> fd = open("/proc/bus/pci/${BUS}/${DEV}", ...);
>> if (fd < 0)
>> return -errno;
>> err = ioctl(fd, PCI_MMAP_IO, 0);
>
>I know I'm coming in on this late, but wouldn't it be cleaner to have
>separate files for memory and io cycles, eg ${BUS}/${DEV}.(io|mem)?
>They're logically different so they might as well be embodied separately.
If I were designing this (and I'm not), I would do it as thus:
/proc/bus/pci/${BUS}/${DEV} is same as it always is
/proc/bus/pci/${BUS}/${DEV}.d/io.n for IO resources, where n is the number
of the IO resource
/proc/bus/pci/${BUS}/${DEV}.d/mem.n for Mem resouces, where n is...
/proc/bus/pci/${BUS}/${DEV}.d/ints for interrupts, which would block on
read when there are no interrupts pending, and after an interrupt is
triggered the data read would be some sort of information about the
interrupt.
And that should (in theory) be all you need for writing a basic userspace
PCI device driver. (You wouldn't really be able to set up DMA or such, but
at that point I think "put the damn driver in the kernel" would be an
appropriate utterance)
This is just off the top of my head, so no warranties expressed or implied
about the sanity of this kind of system.
Come to think of it, is /proc really the best place to put all this stuff?
It would be a pain to put it in /dev and mess with assigning majors and
minors and making sure all the special devices get created and stuff...
Makes me wish Linux had an /hw fs like on IRIX. (I suppose devfs is close,
but I don't personally like the idea of completely replacing /dev with an
automatic filesystem)
Anyways...
Cheers - Tony 'Nicoya' Mantler :)
--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada -- http://nicoya.feline.pp.se/
next prev parent reply other threads:[~2001-03-07 2:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-01 15:33 Benjamin Herrenschmidt
2001-03-01 15:41 ` Benjamin Herrenschmidt
2001-03-01 18:30 ` Alan Cox
2001-03-01 19:09 ` David S. Miller
2001-03-01 19:33 ` Dan Malek
2001-03-01 19:41 ` David S. Miller
2001-03-01 19:59 ` Dan Malek
2001-03-01 20:09 ` Benjamin Herrenschmidt
2001-03-01 20:22 ` David S. Miller
2001-03-01 20:27 ` David S. Miller
2001-03-02 11:25 ` Benjamin Herrenschmidt
2001-03-03 1:08 ` David S. Miller
2001-03-01 19:49 ` Benjamin Herrenschmidt
2001-03-01 20:21 ` David S. Miller
2001-03-01 22:26 ` Alan Cox
2001-03-02 11:20 ` Benjamin Herrenschmidt
2001-03-03 1:06 ` David S. Miller
2001-03-03 2:25 ` Benjamin Herrenschmidt
2001-03-03 11:01 ` Jeff Garzik
2001-03-03 17:28 ` Benjamin Herrenschmidt
2001-03-05 16:20 ` David Woodhouse
2001-03-06 23:01 ` Oliver Xymoron
2001-03-07 2:07 ` Tony Mantler [this message]
2001-03-05 23:21 ` Chris Wedgwood
2001-03-02 1:22 Grant Grundler
2001-03-02 2:19 ` David S. Miller
2001-03-02 17:46 ` Grant Grundler
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='v04003a06b6cb43b4f87c@[24.70.162.12]' \
--to=nicoya@apia.dhs.org \
--cc=benh@kernel.crashing.org \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=oxymoron@waste.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®