> > by 'kernel virtual addresses' you do not mean the vmalloc() area
> > exclusively, correct?
>
> No, they should basically be __va(physical page address). The kiobuf
> tracks a table of "struct page *" to allow us to address memory beyond
> 4G too.
yep, that is what i ment - apparently my change went in with the original
highmem patchset.
basically only the 'user' portion of the highlevel kiobuf code is allowed
to access or deal with virtual addresses, drivers should only ever deal
with the 'page *' part, to get high memory case right.
> > Also, in my pagecache-in-highmem patches i've already got rid of the
> > notion of storing virtual addresses in kiobufs, now it's only a 'struct
> > page *' array instead of a virtual-address array. (will send it to you in
> > a minute so you can see what i mean and we can sync up)
>
> Wrong move. You need the VA in the kiobuf in order to be able to map
> things beyond the end of memory -- think of mapping a PCI video
> framebuffer in a machine with less than 4G of memory. You don't have a
> struct page * to point to those addresses.
[no, i didnt actually do it, ]
nevertheless i disagree a little bit with the current situation :) i
believe we should keep the kiobuf interface (towards lowlevel drivers)
'struct page *'-only, for simplicity. The PCI-to-PCI DMA case is
definitely worth worrying about, but we should rather extend the 'struct
page *' notion instead of putting in a dual interface. There are two
solutions i can think of: we could as well keep a separate mem_map for PCI
(and generic bus) areas, to control usage. This means page_to_physaddr()
type of conversion gets one more branch - no problem i think.
the other solution is to allow 'struct page *' to overflow above
mem_map[]. Drivers which get such addresses have either be careful to not
ever access contents directly (they should only use it to get the DMA
address right), or they have to kmap it. We can change kmap to
automatically map >=mem_map+max_mapnr pages to the correct _IO-space_
address.
> In order to be generic memory containers, kiobufs need both. There will
> be some things you can't do unless you have the right type of page, but
> the kiobuf should be able to contain any type.
yep - but there are other ways to achieve this goal, and storing
physical+virtual is incorrect anyway, what about different IO spaces on
certain architectures? _If_ we make it 'struct page *'-based, then we
should make 'struct page *' (and its conversion routines) generic, not the
other way around.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/