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?
* Tyler Pohl tylerapohl@gmail.com [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"
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 tylerapohl@gmail.com 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?
-- linuxbios mailing list linuxbios@linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios
Bear in mind that if you start changing messages, and you have a question, nobody will know what you are talking about!
thanks
ron
Change 'ram' to 'RAM' in user-visible output.
Signed-off-by: Uwe Hermann uwe@hermann-uwe.de Acked-by: Uwe Hermann uwe@hermann-uwe.de
---
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.
Hi,
Uwe Hermann wrote:
Signed-off-by: Uwe Hermann uwe@hermann-uwe.de Acked-by: Uwe Hermann uwe@hermann-uwe.de
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
On Sun, Dec 10, 2006 at 12:22:33AM +0100, Carl-Daniel Hailfinger wrote:
Signed-off-by: Uwe Hermann uwe@hermann-uwe.de Acked-by: Uwe Hermann uwe@hermann-uwe.de
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.
Signed-off-by: Uwe Hermann uwe@hermann-uwe.de Acked-by: Uwe Hermann uwe@hermann-uwe.de
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
* Segher Boessenkool segher@kernel.crashing.org [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
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
- they waited for a review for an appropriate amount of time
This is failing recently in my observation.
- 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.
- they are absolutely certain that the change is so trivial that it wont break anything
Yeah right :-)
- 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
* Segher Boessenkool segher@kernel.crashing.org [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.
- 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?
- Revert of one's own recent commits, if problems show up after
the fact.
Ack.
Stefan
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?
- 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
* Segher Boessenkool segher@kernel.crashing.org [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.
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
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
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 segher@kernel.crashing.org 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
-- linuxbios mailing list linuxbios@linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios
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.
- 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
-
Carl-Daniel Hailfinger -
Jon Dufresne -
ron minnich -
Segher Boessenkool -
Stefan Reinauer -
Tyler Pohl -
Uwe Hermann