On 2015-06-08 18:31:30, Gao, Liming wrote: > Jordan: > I don't get any feedback from others. You also say I can go ahead. > So, I add this change.
Ok. You are right. It is true that I said: "I don't like the idea of creating the .com for .nasmb sources, but if you insist that it is required, then you can go ahead." So, I guess you went ahead. Can you at least agree that the use of the .com extension is confusing in this case, since .com files are 16-bit DOS executables? I think the only reason they appeared in EDK/EDK II is because masm16 would only output a .com file. I don't think we need to make everything backward compatible. This is a new tool without the legacy masm baggage, so do we really need to go out of our way to bring the masm baggage along? Really, wouldn't it be reasonable for a platform to make a 1-line change to their .fdf file if for no other reason than to make it obvious that a big change just happened to their SEC phase? This project goes *way* out of it's way to try to be backward compatible. In my opinion, often too far. Ok. Rant complete. Thanks for your time, :) -Jordan > I add this support for compatibility. I want to update our core > module to use .nasmb, and platform can directly use the updated > core module without changes. Now, our most platforms use .com > postfix in their platform FDF Ffs Rule. With this patch, after we > update more core modules to use .nasmb instead .asm16, it will not > impact platforms. > > Thanks > Liming > -----Original Message----- > From: Justen, Jordan L > Sent: Tuesday, June 9, 2015 12:56 AM > To: Gao, Liming; edk2-devel@lists.sourceforge.net > Subject: RE: [edk2] [Patch] BaseTools: Update nasmb build rule > > On 2014-11-21 10:16:47, Jordan Justen wrote: > > On 2014-11-20 22:12:42, Gao, Liming wrote: > > > Jordan: > > > NASMB is replacement of ASM16. > > > > I see .nasmb as an alternative, but not a replacement. (.asm16 is > > still supported by EDK II.) > > > > I do hope that long term it replaces all uses of .asm16 though. :) > > > > > Now, ASM16 has been used in the > > > different modules. When the module owners do this conversion, they > > > expect it is compatible and doesn't impact platform, because > > > module owner can't predict how many platform will be impacted. So, > > > I think the compatibility is the important point to persuade the > > > module owners to do this conversion. > > > > I would rather see .bin be used in this case, because it makes more > > sense than .com. I guess .com was used because it was the output from > > link16? But, .com files are known as old dos based executables. It is > > a confusing use of the extension. > > I see you went ahead and committed this without further discussion. > > I also see that you converted an internal platform's fdf from being > able to accept either .bin or .com to only accept .com. So, > apparently you have real preference for using .com rather than .bin. > > Can you explain why you think .com makes better sense than .bin in > this context? > > http://en.wikipedia.org/wiki/COM_file > > -Jordan > > > If we copy the file like in your patch, then few platforms will > > actually change from using .com to .bin, but I think it would be an > > improvement for them to convert to using the .bin extension. > > > > Maybe another idea is to leave the .asm16 .inf in place, and create a > > new .inf with the .nasmb source. Then the platform will have to change > > both the .dsc and .fdf to make use of NASM. This will also leave the > > platform with the option to continue using MASM16/LINK16. > > > > I don't like the idea of creating the .com for .nasmb sources, but if > > you insist that it is required, then you can go ahead. I will not give > > my r-b for the change though. :) > > > > -Jordan > > > > > -----Original Message----- > > > From: Justen, Jordan L > > > Sent: Friday, November 21, 2014 12:58 PM > > > To: edk2-devel@lists.sourceforge.net; Gao, Liming > > > Subject: Re: [edk2] [Patch] BaseTools: Update nasmb build rule > > > > > > On 2014-11-18 23:49:45, Gao, Liming wrote: > > > > Nasmb can replace ASM16. Now, ASM16 output file is *.com. To be > > > > compatible with it, update nasmb build rule to output *.com file also. > > > > > > > > ASM16 output file is used by Platform FDF Rule section. With this > > > > patch, Platform FDF file will not be impacted after asm16 file is > > > > converted to nasmb file. > > > > > > Liming, > > > > > > I don't think we need this change. With a small change to the .fdf, .bin > > > can work as easily as .com. > > > > > > I think .com was a bad extension for this file, even when > > > masm16/link16 was being used. Maybe we should have copied from .com to > > > .bin before. > > > > > > -Jordan > > > > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > > > Signed-off-by: Liming Gao <liming....@intel.com> > > > > > > > > --- > > > > > > > > Index: build_rule.template > > > > > > > > ================================================================== > > > > = > > > > > > > > --- build_rule.template (revision 16400) > > > > > > > > +++ build_rule.template (working copy) > > > > > > > > @@ -491,8 +491,8 @@ > > > > > > > > "$(PP)" $(PP_FLAGS) $(INC) ${src} > > > > > ${d_path}(+)${s_base}.i > > > > > > > > Trim --source-code --convert-hex -o > > > > ${d_path}(+)${s_base}.iii $ {d_path}(+)${s_base}.i > > > > > > > > "$(NASM)" -I${s_path}(+) -l ${d_path}(+)${s_base}.lst > > > > $(NASMB_FLAGS) -o $dst ${d_path}(+)${s_base}.iii > > > > > > > > + $(CP) ${dst} $(OUTPUT_DIR)(+)${s_base}.com > > > > > > > > - > > > > > > > > [Microcode-File.USER_DEFINED, Microcode-File.Microcode] > > > > > > > > <InputFile> > > > > > > > > ?.txt, ?.TXT, ?.Txt, ?.mut, ?.inc > > > > > > > > --- > > > > > > > > > > > > > > > > Thanks > > > > > > > > Liming > > > > > > > > > > > > ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
