Received-SPF: pass (google.com: domain of linux-kernel+bounces-15278-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Wed, 3 Jan 2024 09:39:05 +0100
From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: Jonathan Corbet <corbet@lwn.net>,
	Christophe Lyon <christophe.lyon@linaro.org>,
	Randy Dunlap <rdunlap@infradead.org>, linux-kernel@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Greg Ungerer <gerg@linux-m68k.org>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 00/36] Remove UCLINUX from LTP
Message-ID: <20240103083905.GA1073466@pevik>
Reply-To: Petr Vorel <pvorel@suse.cz>
References: <20240103015240.1065284-1-pvorel@suse.cz>
 <ZZUTsDX8bKPimLgD@rei>
 <ZZUVCr2AZ6clmYIl@rei>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZZUVCr2AZ6clmYIl@rei>

Hi Cyril,

> Hi!
> > > UCLINUX is broken in LTP and nobody really cares. Actually I dare to
> > > say UCLINUX is dead. Therefore I prepared patchset to remove UCLINUX
> > > from LTP. We have been actively removing UCLINUX from LTP during rewrite
> > > tests to new LTP API. This removes the rest from the old tests (which
> > > will be sooner or later rewritten to new API).

> > > Because the patchset is quite big, I did not want to send it to mailing
> > > lists (but I can do it if you want).

> > I agree that this should be done, but I'm not sure if we want to get
> > this in before the January release. I guess that such change would be
> > safer to merge just after the release so that we have a few months to
> > actually catch possible problems.

> Looking at the actuall changes it does not look awfuly complex, so maybe
> we can try to merge it before the pre-release testing and hopefully
> things will not break badly.

Thanks for a quick look. Both ways would work for me, depends on you and others.
Obviously fewer rebasing is better :).

Kind regards,
Petr