sparc cleanup

sparc cleanup

[Toomas Soome]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

hi!

There was a little discussion about SPARC cleanup in FOSDEM and the idea was that it should happen as one update.

I have created stub change which is dropping *directories* in uts tree and outside uts tree. Not yet including psm and stand trees.

Also not yet touching sources (#ifdef SPARC SPARCv9 BIGENDIAN and so on). I haven’t created issue yet for this, at this stage the goal is to get some idea about how possible is such an approach and how much should it include.

So feel free to comment on gerrit and propose updates etc:)

https://code.illumos.org/c/illumos-gate/+/3288


Thanks,
Toomas

[-- Attachment #2: Type: text/html, Size: 1048 bytes --]

Re: [developer] sparc cleanup

[Peter Tribble]

[-- Attachment #1: Type: text/plain, Size: 2542 bytes --]

On Mon, Feb 12, 2024 at 6:30 AM Toomas Soome via illumos-developer <
developer@lists.illumos.org> wrote:

> hi!
>
> There was a little discussion about SPARC cleanup in FOSDEM and the idea
> was that it should happen as one update.
>
> I have created stub change which is dropping *directories* in uts tree and
> outside uts tree. Not yet including psm and stand trees.
>
> Also not yet touching sources (#ifdef SPARC SPARCv9 BIGENDIAN and so on).
> I haven’t created issue yet for this, at this stage the goal is to get some
> idea about how possible is such an approach and how much should it include.
>
> So feel free to comment on gerrit and propose updates etc:)
>
> https://code.illumos.org/c/illumos-gate/+/3288
>

Well thanks for taking a look.

That's a big commit :-)

More than about 1 page in gerrit is likely to be unwieldy. So that's
probably too much in one go.

I think we should regard removal as a single logical operation, but it
doesn't need to be a
single commit. The thing is, that we don't need to have the sparc files in
a consistent
state - the gate won't build or work on sparc as it is - so we can remove
chunks in any order
that turns out to be convenient. (As someone building on sparc, I've picked
a past working
commit and am effectively picking subsequent changes that I want, so any
changes to the
gate won't affect me however the removal is implemented.)

An alternative approach would be to start by finding all the Makefile's
with sparc_SUBDIRS
present (I count 15) and for each one, create a change that removes those
subdirs from that
directory and removes sparc_SUBDIRS (and friends) from the Makefile. Each
change
then simply contains a set of removed files and a single Makefile change,
making it trivial
and uncontroversial to review, and in slightly more digestible chunks.

Doing uts is similar, only it's sparc_ARCHITECTURES not sparc_SUBDIRS

Removing all the sparc and sparcv9 subdirectories under cmd and lib could
be a single
commit, or maybe 2 - again the change is completely obvious.

And then simply look at the list of unref'ed files for remaining candidates.

Cleanup could take a while. It would probably require checking each one. We
obviously
need to keep those where endianness matters, and would have to check that
each guard
for sparc was actually meaning that and didn't mean something else that
happens to
work by accident.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

[-- Attachment #2: Type: text/html, Size: 3570 bytes --]

Re: [developer] sparc cleanup

[Richard Lowe]

This makes sense to me on the face of it -- if you fix cardbus using a
SPARC-specific PCI header -- and was something I was trying to work
out how to approach for shuffling my uts makefile rewrite wad along.

Re: [developer] sparc cleanup

[Toomas Soome]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]



> On 12. Feb 2024, at 22:44, Richard Lowe <richlowe@richlowe.net> wrote:
> 
> This makes sense to me on the face of it -- if you fix cardbus using a
> SPARC-specific PCI header -- and was something I was trying to work
> out how to approach for shuffling my uts makefile rewrite wad along.
> 

I did very simple approach.

rename from usr/src/uts/sun4u/sys/pci/pci_sc.h
rename to usr/src/uts/common/sys/pci/pci_sc.h
rename from usr/src/uts/sun4u/sys/pci/pci_types.h
rename to usr/src/uts/common/sys/pci/pci_types.h

and did copy structure definition from ebus.h to cardbus_cfg.c.

Probably those two headers would need some better handling, but for [temporary] solution, it does the trick…  

Anyhow, just drop sparc/sparcv9 is also not all, because we have few mixed bits in cmd/fm (eversholt and fabric-xlate), some sparc only commands, also cmd/picl (memcfg) and of course, sgs.

rgds,
toomas

[-- Attachment #2: Type: text/html, Size: 3382 bytes --]

Re: [developer] sparc cleanup

[Richard Lowe]

ld(1) being a cross-linker to a big endian platform has useful
results.  Don't delete that just yet, at least until we've thought
about it more.

Re: [developer] sparc cleanup

[Joshua M. Clulow]

On Mon, 12 Feb 2024 at 06:51, Peter Tribble <peter.tribble@gmail.com> wrote:
> On Mon, Feb 12, 2024 at 6:30 AM Toomas Soome via illumos-developer <developer@lists.illumos.org> wrote:
>> https://code.illumos.org/c/illumos-gate/+/3288
> That's a big commit :-)
>
> More than about 1 page in gerrit is likely to be unwieldy. So that's probably too much in one go.
>
> I think we should regard removal as a single logical operation, but it doesn't need to be a
> single commit. The thing is, that we don't need to have the sparc files in a consistent
> state - the gate won't build or work on sparc as it is - so we can remove chunks in any order
> that turns out to be convenient

I think making many tiny commits is probably not worth the futzing
around.  I would much rather we come up with a two-stage strategy:

    - a commit that moves things we want to preserve into proper places
      (should be much smaller, easy to review)

    - a commit that merely deletes everything that is left, after
      we've preserved the useful bits; this will have thousands
      of alterations, but they should be done as part of some
      bulk mechanical action (e.g., a series of "git rm -rf uts/sparc"
      sorts of commands) and we should review the action
      (which should just get put in the ticket) and then you
      can inspect the resultant large commit with "git" itself
      rather than trying to do a web review

I'd really rather avoid turning this into 15-25 bugs and commits and so on.

> And then simply look at the list of unref'ed files for remaining candidates.

Yes I think this is critical: we should be able to come up with a
reason that anything still unrefed at the end is unrefed; e.g., it's a
README or a tool we only build by hand as part of engineering work,
etc.

> Cleanup could take a while. It would probably require checking each one. We obviously
> need to keep those where endianness matters, and would have to check that each guard
> for sparc was actually meaning that and didn't mean something else that happens to
> work by accident.

Yes, and I think this should be a bit similar to the large deleting
commit where possible: using unifdef and other tools in a program,
where we can review the program as well as or instead of all of the
individual lines of change.  By way of example, when I was looking at
trying to get Xen deleted, I started with this:

    https://github.com/jclulow/illumos-gate/blob/xen-b-gone/hammer.sh


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org