similar to: hotplug for klibc utils

Hi folks, attached you can find a tiny patch for klibc-0.198 to get rid of the symbolic link pointing to the kernel sources, and to get rid of some obsolete rebuilds during incremental. Feel free to include it. Regards Harri -------------- next part -------------- diff -ur old/klibc-0.198/MCONFIG klibc-0.198/MCONFIG --- old/klibc-0.198/MCONFIG 2004-10-14 06:32:24.000000000 +0200 +++

this implements a ln(1) with -f and -s support. diff -p -purN klibc-0.112/utils/Makefile klibc-0.112.utils/utils/Makefile --- klibc-0.112/utils/Makefile 2004-02-21 23:49:26.000000000 +0100 +++ klibc-0.112.utils/utils/Makefile 2004-02-22 01:23:17.000000000 +0100 @@ -6,7 +6,7 @@ MAKEDEPS = -Wp,-MD,.$(subst /,-,$*). CFLAGS = $(MAKEDEPS) $(OPTFLAGS) $(REQFLAGS) -W -Wall LIBS =

'rm -rf /' for klibc Doesnt comply to the standard, but does the job. http://www.opengroup.org/onlinepubs/009695399/utilities/rm.html diff -p -purN klibc-0.172/utils/Makefile klibc-0.172.rm/utils/Makefile --- klibc-0.172/utils/Makefile 2004-08-14 00:24:20.000000000 +0200 +++ klibc-0.172.rm/utils/Makefile 2004-09-05 20:11:14.109062216 +0200 @@ -6,7 +6,7 @@ MAKEDEPS = -Wp,-MD,.$(subst

This adds make install support, either static or shared, default is static to avoid dependency mess. Index: MCONFIG =================================================================== --- MCONFIG (revision 1009) +++ MCONFIG (working copy) @@ -45,6 +45,19 @@ CRTSHARED = $(KLIBOBJ)/interp.o LIBSHARED = $(KLIBOBJ)/libc.so +INSTALL = /usr/bin/install + +# offset during make install +DESTDIR = +

Dear Stanislav, thanks for your patch. The problem with your "recommended" pkgconfigdir is that in many cases, it does not work. Namely, when ${prefix} is not one of the standard places such as /usr. As I understand it, the whole point of a tool like pkgconfig is to allow other software to automatically detect the install location of NUT, especially when that location is not one of

On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will at kernel.org> wrote: > > In preparation for allowing architectures to define their own > implementation of the 'READ_ONCE()' macro, move the generic > '{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h' > and into a new 'rwonce.h' header under 'asm-generic'. Adding

On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will at kernel.org> wrote: > > In preparation for allowing architectures to define their own > implementation of the 'READ_ONCE()' macro, move the generic > '{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h' > and into a new 'rwonce.h' header under 'asm-generic'. Adding

It has been observed that binaries contents are depending on the order of linked objects. This order is caused by GNU make's wildcard function and the position of sources on filesystem. This change tries to prevent this kind of randomness. Also consider building using -j1 flag to make it even more reproductible. Change-Id: Ie8eee7f336e6f1fa2863c4150d967afd15519f1d Bug:

On Mon, Nov 11, 2019 at 9:10 AM Christian Borntraeger <borntraeger at de.ibm.com> wrote: > On 08.11.19 20:57, Arnd Bergmann wrote: > > On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will at kernel.org> wrote: > >> > >> In preparation for allowing architectures to define their own > >> implementation of the 'READ_ONCE()' macro, move the generic

On 08.11.19 20:57, Arnd Bergmann wrote: > On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will at kernel.org> wrote: >> >> In preparation for allowing architectures to define their own >> implementation of the 'READ_ONCE()' macro, move the generic >> '{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h' >> and into a new

Hello ext3-users, I tested ext3 on a Linux for S/390 with several stress and benchmark test tests and faced a kernel bug message. The console showed the following output: Message from syslogd@boeaet34 at Fri Aug 3 11:34:16 2001 ... boeaet34 kernel: Assertion failure in journal_forget() at transaction.c:1184: "! jh->b_committed_data" I tried the Patch from

Hello, in the last weeks I evaluated ext3 on the IBM Mainframe S/390 and IBM zSeries. (32 bit, big endian, 64 bit big endian) Ext3 had to face high stress tests, low memory situations, spontaneous resets as well as hardware failure simulations. I tested file system integrity,log replay and stability with ordered and journal mode. All with 32 and 64 bit. I think ext3 has reached a very stable

On Tue, Jan 07, 2020 at 12:34:50PM +0100, Christian Borntraeger wrote: > > > On 07.01.20 10:39, Michael S. Tsirkin wrote: > > On Tue, Jan 07, 2020 at 09:59:16AM +0100, Christian Borntraeger wrote: > >> > >> > >> On 06.01.20 11:50, Michael S. Tsirkin wrote: > >>> On Wed, Dec 18, 2019 at 04:59:02PM +0100, Christian Borntraeger wrote: >

To make it more obvious where the files are supposed to end up move files so they reflect the directory structure in the kernel: mkdir scripts mv kernel/Kbuild.* scripts/ mkdir usr mv kernel/Kbuild usr rmdir kernel Furthermore: - updated cp-to-kernel to refelct new directory layout - teach cp-to-kernel to place gzip right under usr/ - Add '#' in front of comment in usr/Kbuild --- I

On 07.01.20 10:39, Michael S. Tsirkin wrote: > On Tue, Jan 07, 2020 at 09:59:16AM +0100, Christian Borntraeger wrote: >> >> >> On 06.01.20 11:50, Michael S. Tsirkin wrote: >>> On Wed, Dec 18, 2019 at 04:59:02PM +0100, Christian Borntraeger wrote: >>>> On 18.12.19 16:10, Michael S. Tsirkin wrote: >>>>> On Wed, Dec 18, 2019 at 03:43:43PM

On 07.01.20 10:39, Michael S. Tsirkin wrote: > On Tue, Jan 07, 2020 at 09:59:16AM +0100, Christian Borntraeger wrote: >> >> >> On 06.01.20 11:50, Michael S. Tsirkin wrote: >>> On Wed, Dec 18, 2019 at 04:59:02PM +0100, Christian Borntraeger wrote: >>>> On 18.12.19 16:10, Michael S. Tsirkin wrote: >>>>> On Wed, Dec 18, 2019 at 03:43:43PM

On 01.04.20 20:40, Eugenio Perez Martin wrote: > On Wed, Apr 1, 2020 at 9:19 AM Christian Borntraeger > <borntraeger at de.ibm.com> wrote: >> >> On 31.03.20 21:27, Eugenio P?rez wrote: >>> Vhost did not reset properly the batched descriptors on SET_VRING_BASE >>> event. Because of that, is possible to return an invalid descriptor to >>> the guest.

Hello ext3-developers, Just to summarize, I reported a kernel bug message with ext3 on S/390 in transaction.c. I was able to reproduce it with a ext3 on LVM and on MD. Tom Rini reported a similar problem on PPC. (both big endian). I have sent a backtrace and with jbd-debug set to 5 I was not able to reproduce the problem until now. On S/390 there are some more debug possibilities. I would

Hi, Please post any comments or questions if you get around to testing them. Your comments are very welcome! Best regards, -Gonglei > > >>> On 22.10.13 at 06:08, "Gonglei (Arei)" <arei.gonglei@huawei.com> > wrote: > > > Hi, guys. The new patch has been modified based on the principles you > > > suggested, thank you so much. > > >

Following patch improves integration with kbuild. With a future kernel (2.6.14-rc) it now has working support for 'make clean'. Included is an example of how to compile an early userspace program. I selected gzip as the most simple one for this - and left out all the links to different names (gunzip etc.) Before proceeding with this I need some inputs on what functionality is required by