Am 06.11.2015 um 20:31 schrieb Borislav Petkov:
> On Fri, Nov 06, 2015 at 02:22:42PM -0500, Josh Boyer wrote:
>> So this broke dracut. Dracut will look at the config file for the
>> INTEL or AMD early config options being set.
>
> Nothing outside the kernel should depend on Kconfig symbols.
>
Am 06.11.2015 um 20:31 schrieb Borislav Petkov:
> On Fri, Nov 06, 2015 at 02:22:42PM -0500, Josh Boyer wrote:
>> So this broke dracut. Dracut will look at the config file for the
>> INTEL or AMD early config options being set.
>
> Nothing outside the kernel should depend on Kconfig symbols.
>
On 17.09.2015 20:17, Richard Weinberger wrote:
> Am 17.09.2015 um 20:05 schrieb Drew DeVault:
>>> Better send a patch to dracut folks. :-)
>>> Major distros use it and if the feature is nice other initramfs
>>> implementations will adopt it too.
>>
>> dracut is the common one sure, but I'm still
On 17.09.2015 20:17, Richard Weinberger wrote:
> Am 17.09.2015 um 20:05 schrieb Drew DeVault:
>>> Better send a patch to dracut folks. :-)
>>> Major distros use it and if the feature is nice other initramfs
>>> implementations will adopt it too.
>>
>> dracut is the common one sure, but I'm still
On 29.04.2015 17:17, Austin S Hemmelgarn wrote:
> On 2015-04-29 11:07, Harald Hoyer wrote:
>> Most of the stuff does not work without udev and something like systemd.
>>
> That's funny, apparently the initramfs images I've been using for multiple
> months now on server system
On 29.04.2015 16:46, Austin S Hemmelgarn wrote:
> On 2015-04-29 10:11, Harald Hoyer wrote:
>> On 29.04.2015 16:04, Richard Weinberger wrote:
>>> Am 29.04.2015 um 16:01 schrieb Harald Hoyer:
>>>> On 29.04.2015 15:46, Richard Weinberger wrote:
>>>>>
On 29.04.2015 16:18, Richard Weinberger wrote:
> Am 29.04.2015 um 16:11 schrieb Harald Hoyer:
>>>> We don't handcraft the initramfs script for every our customers, therefore
>>>> we
>>>> have to generically support hotplug, persistent device names, p
On 29.04.2015 16:04, Richard Weinberger wrote:
> Am 29.04.2015 um 16:01 schrieb Harald Hoyer:
>> On 29.04.2015 15:46, Richard Weinberger wrote:
>>> Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
>>>> On 29.04.2015 15:33, Richard Weinberger wrote:
>>>>>
On 29.04.2015 15:46, Richard Weinberger wrote:
> Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
>> On 29.04.2015 15:33, Richard Weinberger wrote:
>>> It depends how you define "beginning". To me an initramfs is a *very*
>>> minimal
>>> tool t
On 29.04.2015 15:33, Richard Weinberger wrote:
> It depends how you define "beginning". To me an initramfs is a *very* minimal
> tool to prepare the rootfs and nothing more (no udev, no systemd, no
> "mini distro").
> If the initramfs fails to do its job it can print to the console like
> the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29.04.2015 01:12, John Stoffel wrote:
> LDAP is pretty damn generic, in that you can put pretty large objects into
> it, and pretty large OUs, etc. So why would it be a candidate for going
> into the kernel? And why is kdbus so important in the
On 29.04.2015 01:12, John Stoffel wrote:
>> "Havoc" == Havoc Pennington writes:
>
> Havoc> On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o wrote:
>>> I find dbus to be extremely hard to debug when my desktop starts doing
>>> things I don't want it to do. The fact that it might be flinging
On 29.04.2015 01:12, John Stoffel wrote:
Havoc == Havoc Pennington h...@pobox.com writes:
Havoc On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o ty...@mit.edu wrote:
I find dbus to be extremely hard to debug when my desktop starts doing
things I don't want it to do. The fact that it might be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29.04.2015 01:12, John Stoffel wrote:
LDAP is pretty damn generic, in that you can put pretty large objects into
it, and pretty large OUs, etc. So why would it be a candidate for going
into the kernel? And why is kdbus so important in the
On 29.04.2015 15:33, Richard Weinberger wrote:
It depends how you define beginning. To me an initramfs is a *very* minimal
tool to prepare the rootfs and nothing more (no udev, no systemd, no
mini distro).
If the initramfs fails to do its job it can print to the console like
the kernel does
On 29.04.2015 15:46, Richard Weinberger wrote:
Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
On 29.04.2015 15:33, Richard Weinberger wrote:
It depends how you define beginning. To me an initramfs is a *very*
minimal
tool to prepare the rootfs and nothing more (no udev, no systemd, no
mini
On 29.04.2015 16:04, Richard Weinberger wrote:
Am 29.04.2015 um 16:01 schrieb Harald Hoyer:
On 29.04.2015 15:46, Richard Weinberger wrote:
Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
On 29.04.2015 15:33, Richard Weinberger wrote:
It depends how you define beginning. To me an initramfs
On 29.04.2015 16:18, Richard Weinberger wrote:
Am 29.04.2015 um 16:11 schrieb Harald Hoyer:
We don't handcraft the initramfs script for every our customers, therefore
we
have to generically support hotplug, persistent device names, persistent
interface names, network connectivity
On 29.04.2015 17:17, Austin S Hemmelgarn wrote:
On 2015-04-29 11:07, Harald Hoyer wrote:
Most of the stuff does not work without udev and something like systemd.
That's funny, apparently the initramfs images I've been using for multiple
months now on server systems at work which don't have
On 29.04.2015 16:46, Austin S Hemmelgarn wrote:
On 2015-04-29 10:11, Harald Hoyer wrote:
On 29.04.2015 16:04, Richard Weinberger wrote:
Am 29.04.2015 um 16:01 schrieb Harald Hoyer:
On 29.04.2015 15:46, Richard Weinberger wrote:
Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
On 29.04.2015 15:33
Am 16.04.2015 um 14:15 schrieb Olaf Hering:
> On Thu, Apr 16, Tom Gundersen wrote:
>
>> to a shutdown PID 1 process and finally a transition back to
>> the initial ramdisk so that we can unmount the root file system even.
>
> Is that wishful thinking or actually implemented somewhere?
This is
Am 16.04.2015 um 14:15 schrieb Olaf Hering:
On Thu, Apr 16, Tom Gundersen wrote:
to a shutdown PID 1 process and finally a transition back to
the initial ramdisk so that we can unmount the root file system even.
Is that wishful thinking or actually implemented somewhere?
This is done on
On 21.11.2014 06:02, Greg Kroah-Hartman wrote:
> From: Daniel Mack
>
…
> +/**
> + * kdbus_bus_new() - create a kdbus_cmd_make from user-supplied data
> + * @domain: The domain to work on
> + * @make:Information as passed in by userspace
> + * @uid: The uid of the
On 21.11.2014 06:02, Greg Kroah-Hartman wrote:
> From: Daniel Mack
> …
> +
> +/**
> + * enum kdbus_make_flags - Flags for KDBUS_CMD_{BUS,EP,NS}_MAKE
> + * @KDBUS_MAKE_ACCESS_GROUP: Make the device node group-accessible
> + * @KDBUS_MAKE_ACCESS_WORLD: Make the device node world-accessible
> + */
On 21.11.2014 06:02, Greg Kroah-Hartman wrote:
> From: Daniel Mack
> …
> +5.4 Creating buses and endpoints
> +
> +
> +KDBUS_CMD_BUS_MAKE, and KDBUS_CMD_ENDPOINT_MAKE take a
> +struct kdbus_cmd_make argument.
> +
> +struct kdbus_cmd_make {
> + __u64 size;
> +
On 21.11.2014 06:02, Greg Kroah-Hartman wrote:
> From: Daniel Mack
>
> Add the logic to handle the following entities:
>
> Domain:
> A domain is an unamed object containing a number of buses. A
> domain is automatically created when an instance of kdbusfs
> is mounted, and destroyed when
On 21.11.2014 06:02, Greg Kroah-Hartman wrote:
From: Daniel Mack dan...@zonque.org
Add the logic to handle the following entities:
Domain:
A domain is an unamed object containing a number of buses. A
domain is automatically created when an instance of kdbusfs
is mounted, and
On 21.11.2014 06:02, Greg Kroah-Hartman wrote:
From: Daniel Mack dan...@zonque.org
…
+5.4 Creating buses and endpoints
+
+
+KDBUS_CMD_BUS_MAKE, and KDBUS_CMD_ENDPOINT_MAKE take a
+struct kdbus_cmd_make argument.
+
+struct kdbus_cmd_make {
+ __u64 size;
On 21.11.2014 06:02, Greg Kroah-Hartman wrote:
From: Daniel Mack dan...@zonque.org
…
+
+/**
+ * enum kdbus_make_flags - Flags for KDBUS_CMD_{BUS,EP,NS}_MAKE
+ * @KDBUS_MAKE_ACCESS_GROUP: Make the device node group-accessible
+ * @KDBUS_MAKE_ACCESS_WORLD: Make the device node
On 21.11.2014 06:02, Greg Kroah-Hartman wrote:
From: Daniel Mack dan...@zonque.org
…
+/**
+ * kdbus_bus_new() - create a kdbus_cmd_make from user-supplied data
+ * @domain: The domain to work on
+ * @make:Information as passed in by userspace
+ * @uid: The
On 25.08.2014 15:07, Matt Fleming wrote:
> On Mon, 25 Aug, at 01:55:32PM, har...@redhat.com wrote:
>> From: Harald Hoyer
>>
>> On my Lenovo T420s with 4GB memory, efi_high_alloc() was checking the
>> following memory regions:
>>
>> 0x0010 - 0
On 25.08.2014 12:34, Matt Fleming wrote:
> (Adding linux-efi to Cc)
>
> On Fri, 22 Aug, at 03:48:23PM, har...@redhat.com wrote:
>> From: Harald Hoyer
>>
>> On my Lenovo T420s with 4GB memory, efi_high_alloc() was checking the
>> following memory
On 25.08.2014 12:34, Matt Fleming wrote:
(Adding linux-efi to Cc)
On Fri, 22 Aug, at 03:48:23PM, har...@redhat.com wrote:
From: Harald Hoyer har...@redhat.com
On my Lenovo T420s with 4GB memory, efi_high_alloc() was checking the
following memory regions:
0x0010
On 25.08.2014 15:07, Matt Fleming wrote:
On Mon, 25 Aug, at 01:55:32PM, har...@redhat.com wrote:
From: Harald Hoyer har...@redhat.com
On my Lenovo T420s with 4GB memory, efi_high_alloc() was checking the
following memory regions:
0x0010 - 0x2000
0x2020
On 09.08.2014 16:23, Mantas Mikulėnas wrote:
> As of commit 4bf7111f5016 ("x86/efi: Support initrd loaded above 4G"),
> the kernel freezes at the earliest possible moment when trying to boot
> via UEFI on my Asus laptop. (It still boots via BIOS.)
>
> If I revert that commit on current master
On 09.08.2014 16:23, Mantas Mikulėnas wrote:
As of commit 4bf7111f5016 (x86/efi: Support initrd loaded above 4G),
the kernel freezes at the earliest possible moment when trying to boot
via UEFI on my Asus laptop. (It still boots via BIOS.)
If I revert that commit on current master
Vojtech Pavlik wrote:
Hi!
I've reimplemented the Lifebook touchscreen driver using libps2 and
input, to make it short and fitting into the kernel drivers.
Please comment on code and test for functionality!
PS.: The driver should register two input devices. It doesn't yet,
since that isn't very
Vojtech Pavlik wrote:
Hi!
I've reimplemented the Lifebook touchscreen driver using libps2 and
input, to make it short and fitting into the kernel drivers.
Please comment on code and test for functionality!
PS.: The driver should register two input devices. It doesn't yet,
since that isn't very
38 matches
Mail list logo
