Philippe Houdoin <philippe.houdoin@...> wrote:
> > I guess we should remove the B=3D5FMTR=3D5F flags anyway, and replace
> > them
> > with a platform independent way to specify the memory flags.
> > The driver shouldn't have to differentiate between Intel/PPC/
> > whatever
> > at this place.
> MTR CPUs *feature* can already be considered as cross-cpu,
> as the way you specify them is specific to each one (intel, amd,
> cyrix, can't
> tell for PowerPC but I guess it's same).
> Maybe we should *rename* these flags to sounds more x86-agnostic,
> that right.
That's what I planned.
> However, if we want to be binary compatible with these great but
> unfortunatly
> closed-source existant BeOS x86 graphic drivers, which all of them
> may call
> map=5Fphysical=5Fmemory() with a B=5FMTR=5FWC on the framebuffer card memory,
> we
> *should* honor these B=5FMTR=5F* flags value.
Actually, I think it's okay to find some nicer names for them - I think
MTR is a platform independent description, so I would just define
B=5FMTR=5FWRITE=5FCOMBINED to the same value B=5FMTR=5FWC was before.
That way, we will break source compatibility, which I am fine with in
this regard.
> > Why not=3F A CPU dependent kernel module is a nice way to implement
> > that
> > functionality, don't you think=3F
> I do. I was just pointing that we don't need to be binary compatible
> nor with
> this mtrr=5Fgen module api nor his sub-modules. But splitting into CPU
> specific
> kernel sub-module is the way to go, absolutly.
Okay, I got it now :-)
> BTW, nice job on the kernel these days!
Thanks, but don't expect me to keep that speed :)
(have I mentioned that I will go skiing next week=3F)
> PS: I'm sorry for missing admin meeting two weeks in a row, can't be
> there, and
> nothing to report (i'm not proud of this fact :-( ).
Right, you don't have to be proud of that, but you also don't have to
be sorry about it - if you don't find the time to do anything, then it
is just so; this is supposed to be a "fun" experience for everyone
(with a target in mind, of course), not a duty :-)
Adios...
Axel.

Thread view

RCS file: /cvsroot/open-beos/current/headers/os/drivers/
KernelExport.h,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- KernelExport.h 26 Oct 2002 16:13:30 -0000 1.3
+++ KernelExport.h 27 Jan 2003 13:48:39 -0000 1.4
[...]
+/* MTR attributes for mapping physical memory (Intel Architecture
only) */
+// ToDo: what have those to do here=3F
#define B=5FMTR=5FUC 0x10000000
#define B=5FMTR=5FWC 0x20000000
#define B=5FMTR=5FWT 0x30000000
@@ -179,82 +141,72 @@
#define B=5FMTR=5FWB 0x50000000
#define B=5FMTR=5FMASK 0xf0000000
These Memory Type Range flags are there because it's up to
map=5Fphysical=5Fmemory() caller to
specify which kind of memory access optimization would be best on the *
physical* memory.
And as all other memory-related BeOS calls work on virtual address
space, these flags make
sense only for map=5Fphysical=5Fmemory(), hence this definition place in
KernelExport.h.
When a B=5FMTR=5F* flag is set, BeOS map=5Fphysical=5Fmemory() use the
/boot/beos/system/add-ons/kernel/cpu/mtrr=5Fgen kernel module API to
actually do the
intel/amd/cyrix MTR cpu command.
No need to do this MTR support the same exact BeOS way under OpenBeOS
kernel, however.
BTW, there is a BeNewsletter article called "Windows 95 Experience on
BeOS --
Or How to Hack on BeOS", talking about MTR support, with a sample
driver code:
http://be.befaqs.com/aboutbe/benewsletter/volume=5FII/Issue21.html
This sample code may be a good start to add/rewrite the MTR support for
OpenBeOS...
-Philippe
--
Fortune Cookie Says:
Indifference will be the downfall of mankind, but who cares?

"Philippe Houdoin" <philippe.houdoin@...> wrote:
> +/* MTR attributes for mapping physical memory (Intel Architecture
> only) */
> +// ToDo: what have those to do here=3F
> #define B=5FMTR=5FUC 0x10000000
> #define B=5FMTR=5FWC 0x20000000
> #define B=5FMTR=5FWT 0x30000000
> @@ -179,82 +141,72 @@
> #define B=5FMTR=5FWB 0x50000000
> #define B=5FMTR=5FMASK 0xf0000000
>
> These Memory Type Range flags are there because it's up to
> map=5Fphysical=5Fmemory() caller to
> specify which kind of memory access optimization would be best on the
> *
> physical* memory.
> And as all other memory-related BeOS calls work on virtual address
> space, these flags make
> sense only for map=5Fphysical=5Fmemory(), hence this definition place in
> KernelExport.h.
Oh, I did not realize this, thanks for the hint :-)
I guess we should remove the B=5FMTR=5F flags anyway, and replace them with
a platform independent way to specify the memory flags.
The driver shouldn't have to differentiate between Intel/PPC/whatever
at this place.
> When a B=5FMTR=5F* flag is set, BeOS map=5Fphysical=5Fmemory() use the
> /boot/beos/system/add-ons/kernel/cpu/mtrr=5Fgen kernel module API to
> actually do the
> intel/amd/cyrix MTR cpu command.
> No need to do this MTR support the same exact BeOS way under OpenBeOS
> kernel, however.
Why not=3F A CPU dependent kernel module is a nice way to implement that
functionality, don't you think=3F
> BTW, there is a BeNewsletter article called "Windows 95 Experience on
> BeOS --
> Or How to Hack on BeOS", talking about MTR support, with a sample
> driver code:
> http://be.befaqs.com/aboutbe/benewsletter/volume=5FII/Issue21.html
> This sample code may be a good start to add/rewrite the MTR support
> for
> OpenBeOS...
Thanks for the hint!
Adios...
Axel.

> I guess we should remove the B=5FMTR=5F flags anyway, and replace them
> with a platform independent way to specify the memory flags.
> The driver shouldn't have to differentiate between Intel/PPC/whatever
> at this place.
MTR CPUs *feature* can already be considered as cross-cpu,
as the way you specify them is specific to each one (intel, amd, cyrix, can't
tell for PowerPC but I guess it's same).
Maybe we should *rename* these flags to sounds more x86-agnostic, that right.
However, if we want to be binary compatible with these great but unfortunatly
closed-source existant BeOS x86 graphic drivers, which all of them may call
map_physical_memory() with a B_MTR_WC on the framebuffer card memory, we
*should* honor these B_MTR_* flags value.
> > No need to do this MTR support the same exact BeOS way under OpenBeOS
> > kernel, however.
>
> Why not? A CPU dependent kernel module is a nice way to implement that
> functionality, don't you think?
I do. I was just pointing that we don't need to be binary compatible nor with
this mtrr_gen module api nor his sub-modules. But splitting into CPU specific
kernel sub-module is the way to go, absolutly.
BTW, nice job on the kernel these days!
PS: I'm sorry for missing admin meeting two weeks in a row, can't be there, and
nothing to report (i'm not proud of this fact :-( ).
-Philippe

Philippe Houdoin <philippe.houdoin@...> wrote:
> > I guess we should remove the B=3D5FMTR=3D5F flags anyway, and replace
> > them
> > with a platform independent way to specify the memory flags.
> > The driver shouldn't have to differentiate between Intel/PPC/
> > whatever
> > at this place.
> MTR CPUs *feature* can already be considered as cross-cpu,
> as the way you specify them is specific to each one (intel, amd,
> cyrix, can't
> tell for PowerPC but I guess it's same).
> Maybe we should *rename* these flags to sounds more x86-agnostic,
> that right.
That's what I planned.
> However, if we want to be binary compatible with these great but
> unfortunatly
> closed-source existant BeOS x86 graphic drivers, which all of them
> may call
> map=5Fphysical=5Fmemory() with a B=5FMTR=5FWC on the framebuffer card memory,
> we
> *should* honor these B=5FMTR=5F* flags value.
Actually, I think it's okay to find some nicer names for them - I think
MTR is a platform independent description, so I would just define
B=5FMTR=5FWRITE=5FCOMBINED to the same value B=5FMTR=5FWC was before.
That way, we will break source compatibility, which I am fine with in
this regard.
> > Why not=3F A CPU dependent kernel module is a nice way to implement
> > that
> > functionality, don't you think=3F
> I do. I was just pointing that we don't need to be binary compatible
> nor with
> this mtrr=5Fgen module api nor his sub-modules. But splitting into CPU
> specific
> kernel sub-module is the way to go, absolutly.
Okay, I got it now :-)
> BTW, nice job on the kernel these days!
Thanks, but don't expect me to keep that speed :)
(have I mentioned that I will go skiing next week=3F)
> PS: I'm sorry for missing admin meeting two weeks in a row, can't be
> there, and
> nothing to report (i'm not proud of this fact :-( ).
Right, you don't have to be proud of that, but you also don't have to
be sorry about it - if you don't find the time to do anything, then it
is just so; this is supposed to be a "fun" experience for everyone
(with a target in mind, of course), not a duty :-)
Adios...
Axel.

> Actually, I think it's okay to find some nicer names for them - I
> think
> MTR is a platform independent description, so I would just define
> B=5FMTR=5FWRITE=5FCOMBINED to the same value B=5FMTR=5FWC was before.
> That way, we will break source compatibility, which I am fine with in
> this regard.
Well, does it really worth it to break source compatibility just
to rename *=5FWC into WRITE=5FCOMBINED=3F
I guess coders who need to use these flags knows what B=5FMTR=5FWC & co
mean, no=3F
Okay, I'm kind of stepping back here. Breaking source compatibility
but keeping binary compatibility sounds weird and useless for me, that
all.
> Thanks, but don't expect me to keep that speed :)
> (have I mentioned that I will go skiing next week=3F)
Hey, I got my skiing week last month myself, so I understand.
Not that my own coding speed reach your, far from that even...
-Philippe
--
Fortune Cookie Says:
According to the latest official figures, 43% of all statistics are
totally worthless.

"Philippe Houdoin" <philippe.houdoin@...> wrote:
> Well, does it really worth it to break source compatibility just
> to rename *=5FWC into WRITE=5FCOMBINED=3F
> I guess coders who need to use these flags knows what B=5FMTR=5FWC & co
> mean, no=3F
At least I would have to think to much using those :-)
> Okay, I'm kind of stepping back here. Breaking source compatibility
> but keeping binary compatibility sounds weird and useless for me,
> that
> all.
Despite of Daniel's simple solution: breaking source compatibility in
that way is not a big deal, IMO.
Breaking source compatibility is almost never a big deal when you still
stay binary compatible - because that constrains the breaking to a
minimum, anyway.
If you have the source, it's no problem to (make those slight changes
to) update it; binary compatibility is a completely independent thing,
IMHO. It makes all those nice apps/drivers on BeBits still usable for
everyone.
Adios...
Axel.

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details