Re: [ros-dev] rbuild and HALs module optimization

[Aleksey Bragin]

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

[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...

[art yerkes]

On Fri, 21 Sep 2007 19:48:24 +0200
David Hinz <post.center(a)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.
-- 
"Ask Bill why the string in function 9 is terminated by a dollar sign. Ask him,
because he can't answer. Only I know that".
- Gary Kildall