Digging around in the core code
Posted 03-04-2009 at 06:09 PM by softwizz
Due to a combination of misconfiguration and a buggy bootprom/kernel interface, I just spent several days digging around in the 2.6.18.8 kernel bring-up code, looking for why my nominated RFS device was being ignored.
On the journey I noticed several things that may be worthy of comment (or on the other hand, maybe all of the following is well-trodden territory for the guys on here - judge for yourselves).
There is a macro __setup() which is used to link bootargs to the functions which process them. This is used to specify "root=" as such a linked bootarg. Ain't it a hoot, then, that the parsing code which processes the "root=/dev/xxxx" bootarg from the commandline, drops the '=' before comparing the 'root' token with the list that includes 'root=' but no 'root'. So the test fails.
Maybe there are multiple places where these list comparisons are carried out, and maybe somewhere there is code which does a strncmp and finds the equality. But the functionality which this code self-documents, appears to set up a guaranteed parsing failure.
It would have been helpful if the author(s) of the mechanism(s) involved could have put in some comments indicating why this seemingly doomed-to-fail mechanism was implemented. And if the mechanism is in fact obsoleted, it should be removed. How does one put that viewpoint officially, though?
On the journey I noticed several things that may be worthy of comment (or on the other hand, maybe all of the following is well-trodden territory for the guys on here - judge for yourselves).
There is a macro __setup() which is used to link bootargs to the functions which process them. This is used to specify "root=" as such a linked bootarg. Ain't it a hoot, then, that the parsing code which processes the "root=/dev/xxxx" bootarg from the commandline, drops the '=' before comparing the 'root' token with the list that includes 'root=' but no 'root'. So the test fails.
Maybe there are multiple places where these list comparisons are carried out, and maybe somewhere there is code which does a strncmp and finds the equality. But the functionality which this code self-documents, appears to set up a guaranteed parsing failure.
It would have been helpful if the author(s) of the mechanism(s) involved could have put in some comments indicating why this seemingly doomed-to-fail mechanism was implemented. And if the mechanism is in fact obsoleted, it should be removed. How does one put that viewpoint officially, though?
Total Comments 0
