David, what does a kernel-dev have to do with rbuild? Also, recent massive commits to the rbuild itself, and to various .rbuild files hardly prove your "rbuild is an umaintained piece of ... stuff" theory. It's, by the least measure, offensive to Herve's (and there were a few different patches submitted by various authors submitted) work he's been doing with rbuild.
Or what is a "maintained rbuild", by your definition? How more should it be maintained? Note: not improved (we have a number of improvements pending to be implemented in it), but *maintained*.
Another thing is completely wrong and counter-productive: irc is a wrong place for such question, since not all devs are there all the time.
Now, back to the actual question. The biggest difference between ntoskrnl and HAL is that the first is as machine-independent as possible (still including some dependent code, but it's conditionally included), while the latter is actually very hardware dependent, so it does not make sense to unite x86 and PowerPC HALs, because they are going to contain just simply different source code.
With the best regards, Aleksey Bragin.
On Sep 21, 2007, at 8:11 PM, David Hinz wrote:
Marc Piulachs schrieb:
Does anyone agree with me on this? Maybe I’m missing something here but I would like to improve it.
I don't think you will have much luck getting an answer, as afaik rbuild is currently more or less unmaintained and our kernel-dev left the project.
Maybe arty or hpoussin do have an oppinion regarding your question, but they seem to be rather busy most of the time...
Have you tried asking on irc? Most devs hang out there...
Greets,
David Hinz
Aleksey Bragin schrieb:
David, what does a kernel-dev have to do with rbuild?
I just guessed that as HAL is very near to the kernel, it would be maintained by a kernel-dev, who could answer in detail, why we have certain different hals (I'm referring to differenciating between x86-generic, x86-xbox etc., not between x86 and PPC).
Also, recent massive commits to the rbuild itself, and to various .rbuild files hardly prove your "rbuild is an umaintained piece of ... stuff" theory. It's, by the least measure, offensive to Herve's (and there were a few different patches submitted by various authors submitted) work he's been doing with rbuild.
I surely noticed him working there, that's why I said he might have an oppinion on that matter.
Or what is a "maintained rbuild", by your definition? How more should it be maintained? Note: not improved (we have a number of improvements pending to be implemented in it), but *maintained*.
Well for me, a maintainer is the one who cares about that piece of code, integrates patches, implements features, cleans up and so on and can be contacted regarding that piece of code, even if he isn't currently working on it. As I stated above I noticed Herve working in there, but it didn't look like he was the new maintainer, more like he was doing some stuff that just had to be done to keep rbuild working (I don't want to disregard that work, I know that it was quite a lot he did in there recently). But good to know rbuild has a maintainer.
Another thing is completely wrong and counter-productive: irc is a wrong place for such question, since not all devs are there all the time.
I didn't want to keep him from posting here, but I know devs tend to have way to less time, so you sometimes have to make them aware of something.
Sorry for mixing up just about everything in my first mail...
On Fri, 21 Sep 2007 19:48:24 +0200 David Hinz post.center@gmail.com wrote:
Aleksey Bragin schrieb:
David, what does a kernel-dev have to do with rbuild?
I just guessed that as HAL is very near to the kernel, it would be maintained by a kernel-dev, who could answer in detail, why we have certain different hals (I'm referring to differenciating between x86-generic, x86-xbox etc., not between x86 and PPC).
Also, recent massive commits to the rbuild itself, and to various .rbuild files hardly prove your "rbuild is an umaintained piece of ... stuff" theory. It's, by the least measure, offensive to Herve's (and there were a few different patches submitted by various authors submitted) work he's been doing with rbuild.
I surely noticed him working there, that's why I said he might have an oppinion on that matter.
Or what is a "maintained rbuild", by your definition? How more should it be maintained? Note: not improved (we have a number of improvements pending to be implemented in it), but *maintained*.
Well for me, a maintainer is the one who cares about that piece of code, integrates patches, implements features, cleans up and so on and can be contacted regarding that piece of code, even if he isn't currently working on it. As I stated above I noticed Herve working in there, but it didn't look like he was the new maintainer, more like he was doing some stuff that just had to be done to keep rbuild working (I don't want to disregard that work, I know that it was quite a lot he did in there recently). But good to know rbuild has a maintainer.
Another thing is completely wrong and counter-productive: irc is a wrong place for such question, since not all devs are there all the time.
I didn't want to keep him from posting here, but I know devs tend to have way to less time, so you sometimes have to make them aware of something.
Sorry for mixing up just about everything in my first mail...
Sorry, I've been somewhat taken up while this email thread was going.
Here's what I want to see in rbuild:
1) Remove platform specific settings where possible from rbuild and place them in named variables, and park the variables in the .rbuild files per architecture.
This just means moving things like string linkerParameters = ssprintf ( "-Wl,--subsystem,console -W l,--entry,%s -Wl,--image-base,%s -Wl,--file-alignment,0x1000 -Wl,--section-align ment,0x1000 -shared", module.GetEntryPoint(true). c_str (), module.baseaddress.c_str () );
Into variables like:
<property name="default_WIN32OCX_LINK">-Wl,--subsystem,console ...</property>
And make them overridable so that:
<!-- need this on elf platforms --> <property name="HHCTRL_LINK">-Wl,-z,defs ... $(HHCTRL_ADDLINK)</property>
Supporting entities for common things like variables that will be expanded with target names would be good too.
Like this: <!-- force the linker to include the entry point --> <property name="HHCTRL_ADDLINK">-Wl,-U,&entryPoint;</property>
Where &entryPoint; is expanded to the entry point set for the current target.
2) Reduce the number of targets by turning them into a smaller number of configurable meta-targets and creating the final targets using xml input.
An example target definition would be something like this:
<defineTarget target="ntoskrnl" base="targetModuleRules" for="mingw"> <add stage="linker">-Wl,-T,$(&module;_MODULEBASE)/ntoskrnl_$(ARCH).lnk</add> <add stage="linker">-Wl,--subsystem,native -Wl,--entry,&entryPoint;</add> <add stage="linker">-Wl,-nostartfiles</add> <!-- ... more ... --> <outline> <!-- would expand to the same thing as GenerateCommands compilation parts --> <perform>compile</perform> <perform>link</perform> <perform>postlink</perform> </defineTarget>
Then you can use <module type="ntoskrnl">...</module> in your rbuild input and you can even make these conditional on architecture in the build rules.
-
Aleksey Bragin -
art yerkes -
David Hinz