From: Martin Dalecki <dalecki@evision-ventures.com>
To: James Bottomley <James.Bottomley@steeleye.com>
Cc: Greg KH <greg@kroah.com>, Linus Torvalds <torvalds@transmeta.com>,
mochel@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [BK PATCH] PCI reorg fix
Date: Thu, 09 May 2002 22:51:32 +0200 [thread overview]
Message-ID: <3CDAE154.9080103@evision-ventures.com> (raw)
In-Reply-To: <200205092134.g49LYNo04387@localhost.localdomain>
Uz.ytkownik James Bottomley napisa?:
> dalecki@evision-ventures.com said:
>
>>If your are at it: I was always itching my had what
>>pci_alloc_inconsistent and pci_free_inconsistent is supposed to be?
>>Negating semantically the consistent attribute shows nicely that the
>>_consistent is a bad nomenclatures. Perhaps something more related to
>>the purpose of it would help. Like
>
>
>>ioalloc() and iofree()
>
>
>>Could be even abstracted from the bus implementation.
>
>
>>And of course much less typing...
>
>
> I'm all for less typing, but "consistent" memory has a definite meaning to
> some non-x86 architectures (and inconsistent also has a definite and
> semantically opposite meaning).
>
> The x86 is nice because it is fully coherent architecture: the CPUs snoop the
> I/O busses and do CPU cache invalidations for data transferred from an I/O
> device directly to memory and CPU cache flushes when a device reads directly
> from memory.
So what you are requesting is memmory which is suitable to be run
for IO. All you are talking about is io. I think ioalloc() and iofree()
fit it nice as names.
> If the CPU doesn't snoop I/O transfers, you have to manually invalidate or
> flush the necessary CPU cache lines. The pci_sync_... functions are for doing
...
> drivers simply choose not to bother with consistent memory at all because the
> cache manipulation operations are optimised away on fully consistent platforms.
>
> I'd like to say that this is totally unrelated to the bus type, but some
> architectures place MMUs on their busses which means that memory consistency
> (and even memory addressability) can indeed be bus specific depending on what
> the MMU actually does.
Thank you finally for explaining that the _consistant is about
well coherency and caches... This should have been put up in to the
documentation in question... becouse beleve me or not -
I know well about the "MESIs of the world", but I still wasn't
able to make any sense out of this _consistent term in first place.
And I still have the feeling that the nomenclature is bad.
What are you going to do if on some silly VLSI new slow CPU
invention at some time the need of doing pciIV_alloc_asynchronous() araises?
or pciXI_alloc_remote() or whatever? Are you going to request
all the driver writers to adjust to it again!?
(Something like this could for example just happen very urgently if Transmeta
decided to reveal native access to the hardware and tools in question I guess ;-).
prev parent reply other threads:[~2002-05-09 21:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-08 23:11 Problems with 2.5.14 PCI reorg and non-PCI architectures James Bottomley
2002-05-09 8:44 ` Greg KH
2002-05-09 13:00 ` James Bottomley
2002-05-09 15:23 ` Greg KH
2002-05-09 16:47 ` James Bottomley
2002-05-09 16:52 ` [BK PATCH] PCI reorg fix Greg KH
2002-05-09 18:06 ` Patrick Mochel
2002-05-09 17:15 ` Greg KH
2002-05-09 18:26 ` James Bottomley
2002-05-09 18:23 ` Kai Germaschewski
2002-05-09 18:26 ` Patrick Mochel
2002-05-09 18:46 ` Kai Germaschewski
2002-05-09 19:45 ` Martin Dalecki
2002-05-09 21:34 ` James Bottomley
2002-05-09 20:51 ` Martin Dalecki [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=3CDAE154.9080103@evision-ventures.com \
--to=dalecki@evision-ventures.com \
--cc=James.Bottomley@steeleye.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@osdl.org \
--cc=torvalds@transmeta.com \
/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