[LinuxBIOS] serial output

[Tyler Pohl]

Where is the code for serial output.  For example if i wanted to change
"Jumping to LinuxBios" to Jumping around" where would i find that code?

[Stefan Reinauer]

* Tyler Pohl <[e-mail]> [061208 09:04]:
> Where is the code for serial output.  For example if i wanted to change
> "Jumping to LinuxBios" to Jumping around" where would i find that code?

Depends on whether your port uses cache-as-ram:
./src/cpu/amd/car/copy_and_run.c: print_debug("Jumping to LinuxBIOS.\r\n");
./src/cpu/x86/car/copy_and_run.c: print_debug("Jumping to LinuxBIOS.\r\n");
./src/arch/i386/init/crt0.S.lb:str_pre_main: .string "Jumping to LinuxBIOS.\r\n"


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[Jon Dufresne]

I've found some of the debugging statements to be more unique than
other parts of the code, so it makes grepping for it easy. For
example, if I wanted to grep for that I would do

$ cd LinuxBIOSv2/
$ grep -r -n "Jumping to LinuxBIOS" src/

and it will give the line number and file you can find it in, then you
can change the statement and experiment. Keep in mind grep is case
sensitive and unless you pass the "-i" option.

Good luck!

On 12/8/06, Tyler Pohl <[e-mail]> wrote:
> Where is the code for serial output.  For example if i wanted to change
> "Jumping to LinuxBios" to Jumping around" where would i find that code?

[ron minnich]

Bear in mind that if you start  changing messages, and you have a
question, nobody will know what you are talking about!

thanks

ron

[Uwe Hermann]

Change 'ram' to 'RAM' in user-visible output.

Signed-off-by: Uwe Hermann <[e-mail]>
Acked-by: Uwe Hermann <[e-mail]>

---

On Fri, Dec 08, 2006 at 12:04:32AM -0800, Tyler Pohl wrote:
> Where is the code for serial output.  For example if i wanted to change
> "Jumping to LinuxBios" to Jumping around" where would i find that code?

Apropos... this has been nagging me for a while now, so I'll just fix it
once and for all: ram -> RAM.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

[LinuxBIOS] Signed-off-by versus Acked-by

[Carl-Daniel Hailfinger]

Hi,

Uwe Hermann wrote:
> Signed-off-by: Uwe Hermann <[e-mail]>
> Acked-by: Uwe Hermann <[e-mail]>

I think this defeats the purpose of the Acked-by tag. If
"Acked-by" means you agree with the patch and you need an
"Acked-by" from the same person who added the "Signed-off-by",
then "Signed-off-by" suddenly implies that you don't
necessarily agree with the patch. Which leads to the
question: Why did you sign it off when you don't agree
with it?
The Linux kernel developers either sign off a patch or
ack it, but not both at the same time. We can of course
differ from their habits, but the reasoning should be
sound.

Regards,
Carl-Daniel

[LinuxBIOS] Signed-off-by versus Acked-by

[Uwe Hermann]

On Sun, Dec 10, 2006 at 12:22:33AM +0100, Carl-Daniel Hailfinger wrote:
> > Signed-off-by: Uwe Hermann <[e-mail]>
> > Acked-by: Uwe Hermann <[e-mail]>

Whoa, sorry, I should not post patches late at night ;-) Of course this
should only have contained the Signed-off-by. My bad.
> The Linux kernel developers either sign off a patch or
> ack it, but not both at the same time. We can of course
> differ from their habits, but the reasoning should be
> sound.

No, that's fine, it was an error on my side.

We _do_ sometimes use sign-off+ack from the same person, but only
for very small/trivial patches (typos, cosmetic fixes etc) which are
committed right away.
Usually I would consider this to be one of them, but I wanted to post
the patch for review anyway, just in case something depends on the
exact output of a booting LinuxBIOS...


Cheers, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

[LinuxBIOS] Signed-off-by versus Acked-by

[Segher Boessenkool]

> > Signed-off-by: Uwe Hermann <[e-mail]>
> > Acked-by: Uwe Hermann <[e-mail]>
>
> I think this defeats the purpose of the Acked-by tag. If
> "Acked-by" means you agree with the patch and you need an
> "Acked-by" from the same person who added the "Signed-off-by",
> then "Signed-off-by" suddenly implies that you don't
> necessarily agree with the patch. Which leads to the
> question: Why did you sign it off when you don't agree
> with it?
> The Linux kernel developers either sign off a patch or
> ack it, but not both at the same time. We can of course
> differ from their habits, but the reasoning should be
> sound.

Signed-off-by means the patch passed through your hands
and you have the legal right to pass it on.  Acked-by
is just a comment saying who approved this going into
the SVN tree, it is completely separate; it should probably
be called Approved-by or something like that.  I don't
really see it having any real purpose, but maybe that's
just me :-)


Segher

[LinuxBIOS] Purpose of Acked-by

[Stefan Reinauer]

* Segher Boessenkool <[e-mail]> [061210 13:12]:
> Acked-by is just a comment saying who approved this going into the SVN
> tree, it is completely separate; it should probably be called
> Approved-by or something like that.  I don't really see it having any
> real purpose, but maybe that's just me :-)

In firmware development the risk of bricking your machine is very high,
even with small changes that might have a side effect that the original
author does not see or does not care about. We have had this case so
many times and I've been spending many days fixing the tree after
someone broke it like that and just stopped submitting patches after
that.

On the other hand, pointing fingers within a team is useless, it wont
make teamwork any better. Thus we agreed on using a "second set of eyes"
principle for all work, and expressing this by the Acked-by tag.

I understand that amongs developers such a principle of control is
observed distrustfully, or considered free of purpose, but in fact it is
not. Instead it is a mere method of keeping the tree in the best
possible state, and those who are sly dog enough to never break the tree
do it to stand solidly united with the others. 

While inventing Acked-by we also started enforcing it. Using a 2 eyes
principle without enforcing it makes absolutely no sense at all. 

Now the habit of Acking your own patches is a well-known workaround to
this 2 eyes principle. It is _supposed_ to look stupid so that people
normally dont do it, unless they fulfilled a couple of criteria
1) they waited for a review for an appropriate amount of time
2) they ran abuild
3) they are absolutely certain that the change is so trivial
   that it wont break anything
4) they are absolutely certain that the change is so trivial
   that noone would ever oppose.

If people start misusing this method, we might just remove them from the
list of committers.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[LinuxBIOS] Purpose of Acked-by

[Segher Boessenkool]

> > Acked-by is just a comment saying who approved this going into the  
> > SVN
> > tree, it is completely separate; it should probably be called
> > Approved-by or something like that.  I don't really see it having any
> > real purpose, but maybe that's just me :-)
>
> In firmware development the risk of bricking your machine is very  
> high,
> even with small changes that might have a side effect that the  
> original
> author does not see or does not care about. We have had this case so
> many times and I've been spending many days fixing the tree after
> someone broke it like that and just stopped submitting patches after
> that.
>
> On the other hand, pointing fingers within a team is useless, it wont
> make teamwork any better. Thus we agreed on using a "second set of  
> eyes"
> principle for all work, and expressing this by the Acked-by tag.

Oh, I fully understand why patches should be reviewed by
other people, and why someone "senior" should approve
patches before they are committed to the SVN tree.

I'm just challenging the usefulness of the Acked-by tag
in the commit message.
> I understand that amongs developers such a principle of control is
> observed distrustfully, or considered free of purpose, but in fact  
> it is
> not.

I don't disagree.
> Now the habit of Acking your own patches is a well-known workaround to
> this 2 eyes principle. It is _supposed_ to look stupid so that people
> normally dont do it, unless they fulfilled a couple of criteria
> 1) they waited for a review for an appropriate amount of time

This is failing recently in my observation.
> 2) they ran abuild

As soon as abuild works for everyone, this should be made
a requirement.  Even now already, we should encourage people
to say with their patch submissions "abuild ran with no new
failures" or similar.
> 3) they are absolutely certain that the change is so trivial
>    that it wont break anything

Yeah right :-)
> 4) they are absolutely certain that the change is so trivial
>    that noone would ever oppose.

Heh right :-)

There are a 5) and 6) also:

5) Emergency fixes.  Hopefully never needed and better discussed
widely before committing.  This should really just be treated as
an exception outside of the normal framework I guess.

6) Revert of one's own recent commits, if problems show up after
the fact.
> If people start misusing this method, we might just remove them  
> from the
> list of committers.

Of course.  Misuse is a separate problem :-)


Segher

[LinuxBIOS] Purpose of Acked-by

[Stefan Reinauer]

* Segher Boessenkool <[e-mail]> [061211 17:13]:
> Oh, I fully understand why patches should be reviewed by
> other people, and why someone "senior" should approve
> patches before they are committed to the SVN tree.
>
> I'm just challenging the usefulness of the Acked-by tag
> in the commit message.

Oh this is simple: The commit message is used as the interface to 
the subversion server. There is no other way of easily handling a
successful review on basis of commit hooks.

The whole magic behind these rules is that they're _automatically
enforced.
> As soon as abuild works for everyone, this should be made
> a requirement.  Even now already, we should encourage people
> to say with their patch submissions "abuild ran with no new
> failures" or similar.

abuild runs great. I have not seen any bug reports in a whole 
while. And I am sure no developer is overstrained by running a 
bash shell script. Having people explicitly state they ran abuild 
could do some of the trick.
> 5) Emergency fixes.  Hopefully never needed and better discussed
> widely before committing.  This should really just be treated as
> an exception outside of the normal framework I guess.

This is a hot topic. What would qualify as such an emergency?
> 6) Revert of one's own recent commits, if problems show up after
> the fact.

Ack. 



Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[LinuxBIOS] Purpose of Acked-by

[Segher Boessenkool]

> > I'm just challenging the usefulness of the Acked-by tag
> > in the commit message.
>
> Oh this is simple: The commit message is used as the interface to
> the subversion server. There is no other way of easily handling a
> successful review on basis of commit hooks.

Ah okay, got it.
> > As soon as abuild works for everyone, this should be made
> > a requirement.  Even now already, we should encourage people
> > to say with their patch submissions "abuild ran with no new
> > failures" or similar.
>
> abuild runs great. I have not seen any bug reports in a whole
> while.

It won't do crossbuilds still no?
> > 5) Emergency fixes.  Hopefully never needed and better discussed
> > widely before committing.  This should really just be treated as
> > an exception outside of the normal framework I guess.
>
> This is a hot topic. What would qualify as such an emergency?

Dunno.  Something exceptional.  A high-profile security
issue or a "brick everything!" bug or something.  Something
insanely important to fix _right now_.

There's no need to have any protocol for this, or document
it in the check-in rules; just as long as the automated
tools don't stand in the way in such a case all is fine :-)


Segher

[LinuxBIOS] Purpose of Acked-by

[Stefan Reinauer]

* Segher Boessenkool <[e-mail]> [061211 18:07]:
> > abuild runs great. I have not seen any bug reports in a whole
> > while.
>
> It won't do crossbuilds still no?

It did from the very first day. You need an appropriate cross compiler
installed and in your path though. 

S.
-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[LinuxBIOS] Purpose of Acked-by

[Segher Boessenkool]

> > > abuild runs great. I have not seen any bug reports in a whole
> > > while.
> >
> > It won't do crossbuilds still no?
>
> It did from the very first day.

Heh, not for me ;-)
> You need an appropriate cross compiler
> installed and in your path though.

I'll try it out again, I have *many* (100 or so) cross-compilers
in my path, maybe it gets confused a bit :-)


Segher

[Segher Boessenkool]

On 10-dec-2006, at 0:01, Uwe Hermann wrote:
> Change 'ram' to 'RAM' in user-visible output.

As an aside...  For any and all patches, please start a
new mail thread, with [PATCH] in the title -- this ensures
people will actually see the patch, and it makes life a
whole lot easier for scripts listening to the mailing list
(patch trackers, etc.)


Segher

[Jon Dufresne]

I'm a little confused then. Are patches supposed to be submitted via
trac or the mailing list?


Jon

On 12/10/06, Segher Boessenkool <[e-mail]> wrote:
> On 10-dec-2006, at 0:01, Uwe Hermann wrote:
> > Change 'ram' to 'RAM' in user-visible output.
>
> As an aside...  For any and all patches, please start a
> new mail thread, with [PATCH] in the title -- this ensures
> people will actually see the patch, and it makes life a
> whole lot easier for scripts listening to the mailing list
> (patch trackers, etc.)
>
> Segher

[Uwe Hermann]

On Sun, Dec 10, 2006 at 09:54:04AM -0500, Jon Dufresne wrote:
> I'm a little confused then. Are patches supposed to be submitted via
> trac or the mailing list?

Do as you see fit, we don't want to force any method on people. We
_recommend_ to use Trac, but currently it has two bugs which really make
it hard to work with Trac properly:

 * You cannot attach patches ;-)
   http://trac.edgewall.org/ticket/4311

 * The notification emails sent by Trac to the mailing list don't
   contain the patches.
   http://trac.edgewall.org/ticket/2259

When those are fixed, working with Trac (either via web or via email
interface) should be convenient enough for all/most people.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

[Segher Boessenkool]

> * The notification emails sent by Trac to the mailing list don't
>    contain the patches.
>    http://trac.edgewall.org/ticket/2259

Until this is fixed, it is nice to send the patches you put
in Trac to the ML separately, for discussion.  Please note
the ticket number too then :-)


Segher