cvs commit: src/sys/boot/i386/boot2 boot1.S sio.S
src/sys/boot/i386/btx/btx btx.S src/sys/boot/i386/btx/btxldr
btxldr.S src/sys/boot/i386/libi386 amd64_tramp.S
ru at FreeBSD.org
Wed Apr 28 11:26:10 PDT 2004
On Wed, Apr 28, 2004 at 01:15:48PM -0400, John Baldwin wrote:
> On Wednesday 28 April 2004 11:23 am, Ruslan Ermilov wrote:
> > On Wed, Apr 28, 2004 at 11:06:13AM -0400, John Baldwin wrote:
> > > Well, that just killed any local diff's anyone had to the boot code for a
> > > trivial reason. as(1) worked just fine, I don't see why it's such a
> > > cardinal sin to use as(1) to compile asm files.
> > The problem is not with as(1) but with cpp(1) -- as explained in
> > the commit log our comments weren't strictly speaking comments
> > per se, yet you were the one who pointed this out once to me
> > when I switched from m4(1) preprocessed .s files to cpp(1)
> > preprocessed .S files.
> They were perfectly fine as(1) comments. :) Wanting to use cpp(1) rather than
> --defsym is a style change, but anyways.
Not quite. Please see below.
> > > Thanks for not even asking before hosing the history in cvs annotate:
> > The history is still here, ``cvs annotate -rX.Y'' still works.
> Yes, but cvs walking back through history to see when an actual change was
> originally made takes a bit longer when large scale style changes are made.
Harder, but still possible. I have to do it almost every day
when I look for history -- I even looking it in another VCSs,
like SCCS from SCRG. ;)
> I just think there needs to be a good reason to justify touching every line
> in a file for a non-code change, and --defsym vs. cpp(1) doesn't seem like a
> good reason, but I'm only one voice, so I'll just deal I guess.
Not that simple. They were already preprocessed by cpp(1).
--defsym vs. cpp(1) would be a style only of course, and I
wouldn't probably do it, but these files have conditionals
(#ifdef/#endif) which aren't possible with just --defsym.
Previosly we had to use m4(1), now we use cpp(1). For this
reason, up until now, boot0.s was preprocessed with --defsym,
it was enough. Now that boot0_512.s is the merged source with
conditionals, it's preprocessed with cpp(1), so the source
should obey cpp(1) comments rules (only C style comments),
otherwise comments like this will fail:
.asm code # this does not
# include anything
(Hint: the second line will barf.)
> > > > grep jhb /usr/src/MAINTAINERS
> > >
> > > cdboot jhb Pre-commit review requested.
> > > pxeboot jhb Pre-commit review requested.
> > > witness jhb Pre-commit review requested.
> > > sys/boot/i386/cdboot/Makefile:MAINTAINER= jhb at FreeBSD.org
> > > sys/boot/i386/pxeldr/Makefile:MAINTAINER= jhb at FreeBSD.org
> > I don't look into makefiles for MAINTAINER bits anymore, and
> > you'd better renaming "pxeboot" to "pxeldr" in src/MAINTAINERS.
> Those aren't in makefiles. I think you put them in src/MAINTAINERS when you
> removed them from the Makefiles w/o my permission.
No. I only removed them from makefiles because they were
already in src/MAINTAINERS:
: Working file: MAINTAINERS
: revision 1.6
: date: 2002/04/16 13:16:52; author: jhb; state: Exp; lines: +5 -0
: Specify my personal desired level of review for commits to several portions
: of the i386 bootstrap code and witness.
and also inspired by reading the following text from src/MAINTAINERS:
: Please also consider removing the lines from the files listed below and
: stating your preferences here instead.
Note that I didn't even remove the redundant two lines from
sys/boot/i386/cdboot/Makefile:MAINTAINER= jhb at FreeBSD.org
sys/boot/i386/pxeldr/Makefile:MAINTAINER= jhb at FreeBSD.org
Ah, now I see where they are coming from. ;-)
Sorry about that. Again, I have no problem backing out part of
the changes and reapplying them later, if that will be convenient
ru at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20040428/c73b6a4e/attachment.bin
More information about the cvs-src