similar to: [PATCH] gen_init_cpio processes file from a file list

(Apologies to klibc@zytor.com for the re-send) This patch makes gen_init_cpio generate the initramfs_data.cpio from a file which contains a list of entries: file, dir, nod. I swapped the order of filename/location for the file arguments so that it would be more uniform with the dir and nod tyes. [thayne@torch linux-2.6.8]$ usr/gen_init_cpio --help ERROR: unable to open '--help': No such

hpa notified me in private mail that we have an issue that when building initramfs - if the content changes (say kinit) then the initramfs will not be rebuild. The solution I have come up with is to let make check all the files included in the initramfs and rebuild it if any files are newer than the initramfs and also rebuild if arguments changes (root_uid). In same process the usr/Kbuild file

This fix has been implemented in preparation for the upcoming klibc merge in -mm. But as it fixes a real (but rare I hope) bug in vanilla kernel it will be added to my pending 2.6.17 kbuild queue. I've done quite some changes to the gen_initramfs script and being shell programming newbie review by more experienced shell hackers would be appreciated. I did a git mv

Last patch for now. This gets gen_init_cpio into a state where it can pick up a "kinit" binary from usr and stuff it into the cpio archive as /sbin/init. This is obviously a crock, but it suffices for testing until something sane is done about integrating klibc into the kernel tree. The patch also adds a bit of instrumentation to initramfs.c, to try to help flush out bug 740.

I've googled to try and find discussion of this topic but didn't see any results particularly interesting... Is there any particular reason the kernel has gen_init_cpio instead of just using cpio itself? I'm working on some changes that would involve just cpio-ing the entire usr/root subtree as the initramfs image (instead of gen_init_cpio having to know ahead of time what files to

Harcoding default content of initramfs in the gen_initramfs_list.sh script seems ackward. Move it to a file named: usr/initramfs.default This also fixes a small bug when no arguments was passed to CONFIG_INITRAMFS_SOURCE (-d was passed twice to the script) Idea and bug report from: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> ---

Harcoding default content of initramfs in the gen_initramfs_list.sh script seems ackward. Move it to a file named: usr/initramfs.default This also fixes a small bug when no arguments was passed to CONFIG_INITRAMFS_SOURCE (-d was passed twice to the script) Idea and bug report from: "H. Peter Anvin" <hpa at zytor.com> Signed-off-by: Sam Ravnborg <sam at ravnborg.org>

Generate dependencies almost like done by fixdep in the kernel. This teaches make to rebuild cpio image when content has changed. Also restructured usr/Kbuild a little so we better utilise parallel makes (dash, gzip, utils and kinit are now build in parallel). Signed-off-by: Sam Ravnborg <sam@ravnborg.org> --- patch is on top of hpa's linux tree, so path differ if applied to the klibc

rhbz#720568 Signed-off-by: Joey Boggs <jboggs at redhat.com> --- scripts/ovirt-config-setup.py | 41 +++++++++++++++++------------------------ 1 files changed, 17 insertions(+), 24 deletions(-) diff --git a/scripts/ovirt-config-setup.py b/scripts/ovirt-config-setup.py index 4bd46d5..bddf6aa 100755 --- a/scripts/ovirt-config-setup.py +++ b/scripts/ovirt-config-setup.py @@ -774,6 +774,7

On Thu, 23 May 2019, Michael Mueller wrote: > static struct ccw_device * io_subchannel_allocate_dev(struct subchannel *sch) > { > struct ccw_device *cdev; > + struct gen_pool *dma_pool; > > cdev = kzalloc(sizeof(*cdev), GFP_KERNEL); > - if (cdev) { > - cdev->private = kzalloc(sizeof(struct ccw_device_private), > - GFP_KERNEL | GFP_DMA); > - if

Fix usr/Kbuild so it utilise the new gen_initramfs.sh script which will rebuild initramfs when the content has changed. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> --- usr/Kbuild | 74 +++++++++++++++++++---------------------------------------------- 1 file changed, 22 insertions(+), 52 deletions(-) This patch shall not be applied until my kbuild.git tree is merged upstream. Or it

Hello, I noticed a bug in Xen-4.1-3, which is also still present in xen+git. I know that the Python xend is deprecated, but I''m stuck with xen-4.1 until xen is usable with libvirt, so my patch might still be helpful for others. This is a follow-up to <http://lists.xen.org/archives/html/xen-users/2012-11/msg00069.html>, which still keeps me busy. /xen/xend/server/SrvDomain.py

Hi, Suppose I have a vector: > names.select [1] "Idd13" "Idd14" "Idd8.12" "Idd7" automatically generated by some selection criteria. Now, if I have a data frame with many variables, of which the variables in "names.select" are also variables from the data frame. e.g. > all.df[1:5,] Mouse Idd5 Idd6.19.20 Idd13 Idd14 Idd8.12

Hi Bryan and other klibc people. I have taken a stamp on the Makefiles for klibc, this is what I came up with. 1) No longer recompile on every invocation 2) Correct checking on dependencies 3) Simpler makefile syntax (almost all over the place) I compile-time tested it only. Two open issues: a) Do we realy use .a files for initramfs. I renemed that to the executable. b) I renamed

https://bugzilla.samba.org/show_bug.cgi?id=2758 Summary: "File exists" error using options -b and --backup-dir with device files. Product: rsync Version: 2.6.4 Platform: All OS/Version: AIX Status: NEW Severity: normal Priority: P3 Component: core AssignedTo:

Hyper-V drivers have supported two device abstractions. This patch implements a single device abstraction. This simplifies the code and avoids duplication of state. Signed-off-by: K. Y. Srinivasan <kys at microsoft.com> Signed-off-by: Haiyang Zhang <haiyangz at microsoft.com> Signed-off-by: Hank Janssen <hjanssen at microsoft.com> --- drivers/staging/hv/blkvsc.c | 17

Hyper-V drivers have supported two device abstractions. This patch implements a single device abstraction. This simplifies the code and avoids duplication of state. Signed-off-by: K. Y. Srinivasan <kys at microsoft.com> Signed-off-by: Haiyang Zhang <haiyangz at microsoft.com> Signed-off-by: Hank Janssen <hjanssen at microsoft.com> --- drivers/staging/hv/blkvsc.c | 17

As virtio-ccw devices are channel devices, we need to use the dma area for any communication with the hypervisor. This patch addresses the most basic stuff (mostly what is required for virtio-ccw), and does take care of QDIO or any devices. An interesting side effect is that virtio structures are now going to get allocated in 31 bit addressable storage. Signed-off-by: Halil Pasic <pasic at

From: Halil Pasic <pasic at linux.ibm.com> As virtio-ccw devices are channel devices, we need to use the dma area for any communication with the hypervisor. It handles neither QDIO in the common code, nor any device type specific stuff (like channel programs constructed by the DASD driver). An interesting side effect is that virtio structures are now going to get allocated in 31 bit

From: Halil Pasic <pasic at linux.ibm.com> As virtio-ccw devices are channel devices, we need to use the dma area for any communication with the hypervisor. It handles neither QDIO in the common code, nor any device type specific stuff (like channel programs constructed by the DASD driver). An interesting side effect is that virtio structures are now going to get allocated in 31 bit