> Chris Noe wrote:
> > Especially when that dependency is on an assembler which isn't even really
> > needed anymore because gas can do the same job today).
>
> BTW, LILO also uses as86. Guess why - because it needs to generate 16 bit
> x86 code and as86 was around anyway ... (and, as your experience with
> binutils suggests, actually the only choice, particularly in '92)
>
> I'm in no hurry to change LILO to use any other assembler syntax: there
> are ~2500 lines of assembler waiting for anybody attempting such a
> conversion to make a stupid typo which may then bite a few million
> people. Not a good idea. (*)
Well, I can't say that there won't be bugs (because everyone knows I'd be
lying) but I do know that I've already had every tester report that "it
boots"(tm). On top of that, I've done an instruction by instruction
disassembly of the compiled previous bootcode vs. the compiled gas
version. They are now identical, opcode for opcode (minus some prefixes
that as86 likes/gas doesn't, different encodings, etc). Doing that helped
me find at least 5 buglets caused by typos and at least 3 bugs in gas
itself. Now, mind you, that was more than a year ago, and those bugs in
gas were fixed in 2.9.1.0.7 (which is the *minimum* required by
Documentation/Changes for 2.2). So I'm confident that the patch is working
and free of brown paper bag bugs.
> Regarding as86 vs. NASM vs. gas: I don't see where NASM would fit. as86
> does the job today, it's deployed, and it's readily understood by most
> people who know Intel syntax. I can see some value in using gas for (at
> least approximative) uniformity.
And to me, nasm was a passing thought as well since: (a) I've already done
the work to go to gas. (b) The original motivation behind this work
was to remove a kernel build-time dependency on a program, not to add
another! (c) Making assembly usage in the kernel a bit more consistent
was another plus, and nasm would just keep more intel syntax in there.
> But forcing a mandatory binutils update upon people just for that seems
> vastly exaggerated. The story would be different if there are other
> benefits in upgrading binutils, e.g. known mis-compilation of kernels
> with older versions.
As I've explained above, the only mandatory update is listed in
Documentation/Changes for 2.2 and as such everyone who is running 2.2
right now should be using binutils 2.9.1.0.7 or above it (note: Well,
semi-true; it also says 2.8.1.0.23 is good, which has quite a few
buglets which are exposed by my patch. With 2.3/2.4 that version *should*
be dropped, because it does have known issues which are fixed only in
2.9).
> The fact that in Linux, we are not enslaved by backwards-compatibility
> in the way other products are, does not mean that we need to break it
> at every opportunity just to prove our independence.
Agreed.
And it was my mistake to even (passingly) mention the possibility of
updating Documentation/Changes to use the latest and greatest binutils.
That was a hope of mine, since it does have quite an advantage over the
older versions, but backwards compatibility takes precedence, esp. when
dealing with something that would cause *everyone* to have to upgrade.
Chris Noe
(stiker@northlink.com)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/