Moving from .uu.o -> .o in the kernel

[Warner Losh]

Greetings,

In preparations for bringing a new vendor driver in, I realized that one of
the promises of svn was that one could store .o files in the repo. We never
did that, preferring to stick with the old CVS trick of storing the .o
files as .o.uu files and converting them as part of the build process.

Well, now that we've moved to git, it's time to retool. I've taken the
liberty of converting two of the hpt* drivers. These drivers are on the
edge of relevance, it is true. However, I'm not here to talk about that
today. I'm also not here to talk about whether or not this is evil. I'm not
changing any defaults, they still won't be in GENERIC and they still won't
be built as modules if you have sourceless turned on. So if you want to
talk about those topics, get your own thread :)

My proposal is to simplify. I propose that we remove the .uu files and just
commit the .o files and adjust the build to simplify it. It turns out that
our config(8) knows that when there's a .o in the kernel files* file, just
to copy that .o file over when the driver is in the tree.

I've done hptnr and hpt27xx rather arbitrarily to get the hang of this and
have uploaded the diffs to phabricator for review. I plan on doing the rest
of these files this way.

https://reviews.freebsd.org/D29632
https://reviews.freebsd.org/D29634

Comments?

Warner

[Mark Murray]

Greetings,

Post by Warner Losh
My proposal is to simplify. I propose that we remove the .uu files and just
commit the .o files and adjust the build to simplify it. It turns out that
our config(8) knows that when there's a .o in the kernel files* file, just
to copy that .o file over when the driver is in the tree.

Go for it. This is an obvious removal of technical debt.

M
--
Mark R V Murray

[Bjoern A. Zeeb]

On 8 Apr 2021, at 5:26, Warner Losh wrote:

Hi,

Post by Warner Losh
In preparations for bringing a new vendor driver in, I realized that one of
the promises of svn was that one could store .o files in the repo. We never
did that, preferring to stick with the old CVS trick of storing the .o
files as .o.uu files and converting them as part of the build process.

..

Post by Warner Losh
My proposal is to simplify. I propose that we remove the .uu files and just
commit the .o files and adjust the build to simplify it. It turns out that
our config(8) knows that when there's a .o in the kernel files* file, just
to copy that .o file over when the driver is in the tree.

and we’ve done similar things for, e.g., firmware files storing the
binary
rather than the uuencoded versions in the tree. I am all for the
simplification!


I am a bit concerned with .o files in random places in the source tree
though as
they may show up and various tooling people have might clean them up.
I’d suggested to keep it in mind and go ahead and do a few and see if
it becomes
a practical issue rather than just a theoretical one before taking any
actions ..


/bz

[Michael Gmelin]

On Thu, 08 Apr 2021 13:15:38 +0000

Post by Bjoern A. Zeeb
Hi,

Post by Warner Losh
In preparations for bringing a new vendor driver in, I realized that one of
the promises of svn was that one could store .o files in the repo. We never
did that, preferring to stick with the old CVS trick of storing the
.o files as .o.uu files and converting them as part of the build
process.

..

Post by Warner Losh
My proposal is to simplify. I propose that we remove the .uu files and just
commit the .o files and adjust the build to simplify it. It turns out that
our config(8) knows that when there's a .o in the kernel files* file, just
to copy that .o file over when the driver is in the tree.

and we’ve done similar things for, e.g., firmware files storing the
binary
rather than the uuencoded versions in the tree. I am all for the
simplification!
I am a bit concerned with .o files in random places in the source
tree though as
they may show up and various tooling people have might clean them up.
I’d suggested to keep it in mind and go ahead and do a few and see if
it becomes
a practical issue rather than just a theoretical one before taking
any actions ..

Personally, I would prefer to use a custom extension (like .obj, .srco,
.bin, ...) as finger memory will produce things like
`find . -name \*.o -delete' (and tooling, like Bjoern said, might
bite us as well).

If you still decide to use the .o extension, I would make sure to
- keep *.o in the top-level .gitignore file to avoid checking in
objects by accident.
- explicitly make exemptions where needed.

So, e.g., .gitignore would contain *.o, while
sys/contrib/dev/mwl/.gitignore would contain

!mwlboot.fw.o
!mw88W8363.fw.o

to explicitly just exclude the files in question from being ignored.

Best,
Michael

Post by Bjoern A. Zeeb
/bz
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to

[Warner Losh]

On Thu, Apr 8, 2021 at 7:15 AM Bjoern A. Zeeb <

Post by Bjoern A. Zeeb
Hi,

Post by Warner Losh
In preparations for bringing a new vendor driver in, I realized that one of
the promises of svn was that one could store .o files in the repo. We never
did that, preferring to stick with the old CVS trick of storing the .o
files as .o.uu files and converting them as part of the build process.

..

Post by Warner Losh
My proposal is to simplify. I propose that we remove the .uu files and just
commit the .o files and adjust the build to simplify it. It turns out that
our config(8) knows that when there's a .o in the kernel files* file, just
to copy that .o file over when the driver is in the tree.

and we’ve done similar things for, e.g., firmware files storing the
binary
rather than the uuencoded versions in the tree. I am all for the
simplification!
I am a bit concerned with .o files in random places in the source tree
though as
they may show up and various tooling people have might clean them up.
I’d suggested to keep it in mind and go ahead and do a few and see if
it becomes
a practical issue rather than just a theoretical one before taking any
actions ..

I'm about to push the changes to the tree based on the discussions in this
thread.

In the end, I adopted this view: I'm going to create the .o files and if
there's a lot of
grief that results, I'll name them something else. My reasoning is that
there's a
benefit from naming them .o since config has a built in rule to copy them
(it's
only built-in rule) so we'd simplify things where otherwise we'd need to add
a cp rule in a number of places for a currently ill defined benefit of not
breaking other people's tooling. I suspect that the number of places that
break
will be low to non-existent in practice. Should that turn out not to be the
case, I'll revisit. I'll also monitor all the usual channels for breakage
complaints.

I'm not doing all the .uu files at this time. Just the .o.uu files. I'll
look to the other
ones as time requires it.

I do not plan on merging this to 12.x, but will to 13.x.

Warner