Hi
On Mon, Sep 15, 2014 at 4:22 PM, John Haxby wrote:
> I really appreciate proper explanations, thank you.
Quite simple: We want to avoid calling into udev and back into the
kernel if we there's a way to skip this step. That is, the default
should work without udev.
Reasons:
* We want init=/b
On 15/09/14 15:02, David Herrmann wrote:
> Hi
>
> On Mon, Sep 15, 2014 at 3:19 PM, John Haxby wrote:
>> On 12/09/14 16:03, Kay Sievers wrote:
>>> On Fri, Sep 12, 2014 at 3:04 PM, John Haxby wrote:
When I think of changing the
behaviour of any removable hardware, udev is automatically w
Hi
On Mon, Sep 15, 2014 at 3:19 PM, John Haxby wrote:
> On 12/09/14 16:03, Kay Sievers wrote:
>> On Fri, Sep 12, 2014 at 3:04 PM, John Haxby wrote:
>>> When I think of changing the
>>> behaviour of any removable hardware, udev is automatically where I look
>>> first. So if I'm missing something
On 12/09/14 16:03, Kay Sievers wrote:
> On Fri, Sep 12, 2014 at 3:04 PM, John Haxby wrote:
>> On 02/09/14 16:42, Kay Sievers wrote:
> Either the kernel has to provide a mechanism for the userspace to
> control onlining, or do it itself and provide a mechanism to prevent
> automatic onl
Hi
On Fri, Sep 12, 2014 at 5:48 PM, Todd Vierling wrote:
> What we do with those events is udev's rule configuration. Some of
> those actions do involve telling the kernel to do something in
> addition to the original event; see the two examples above (though
> these are not the only ones in comm
On Fri, Sep 12, 2014 at 11:03 AM, Kay Sievers wrote:
>> Here, the default
>> action is almost a trivial configuration... but not the only possible
>> desired configuration.
>>
>> Can I ask your reasoning for CPU hotplug behaviour not being the role of
>> udev to fulfill? If that's not the right pl
On Fri, Sep 12, 2014 at 3:04 PM, John Haxby wrote:
> On 02/09/14 16:42, Kay Sievers wrote:
>>> > Either the kernel has to provide a mechanism for the userspace to
>>> > control onlining, or do it itself and provide a mechanism to prevent
>>> > automatic onlining. I think that the first option is a
On 02/09/14 16:42, Kay Sievers wrote:
>> > Either the kernel has to provide a mechanism for the userspace to
>> > control onlining, or do it itself and provide a mechanism to prevent
>> > automatic onlining. I think that the first option is actually
>> > cleaner. So yeah, let's add the original rul
On 02/09/14 16:40, Kay Sievers wrote:
>>> >> But just in case someone thinks of any per-CPU onlining policy
>>> >> machinery now: We will not ship anything in that area in systemd/udev
>>> >> upstream. This stuff just belongs into the kernel, like it works for
>>> >> any other device.
>> >
>> > Do
On Tue, Sep 2, 2014 at 5:29 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Tue, Sep 02, 2014 at 10:27:37AM +0200, Kay Sievers wrote:
>> On Tue, Sep 2, 2014 at 10:01 AM, John Haxby wrote:
>> >
>> > On 2 Sep 2014, at 06:55, Kay Sievers wrote:
>> >
>> >> On Tue, Sep 2, 2014 at 5:22 AM, Zhenzhong Duan
On Tue, Sep 2, 2014 at 5:30 PM, John Haxby wrote:
> On 02/09/14 16:23, Kay Sievers wrote:
>> On Tue, Sep 2, 2014 at 5:11 PM, Colin Guthrie wrote:
>>>
>>> John Haxby wrote on 02/09/14 10:31:
Col, forgive my ignorance, but cpuadd@$name.service seems to imply that
you'd have one file or sy
On 02/09/14 16:23, Kay Sievers wrote:
> On Tue, Sep 2, 2014 at 5:11 PM, Colin Guthrie wrote:
>>
>> John Haxby wrote on 02/09/14 10:31:
>>> Col, forgive my ignorance, but cpuadd@$name.service seems to imply that
>>> you'd have one file or symlink per CPU. That's going to be unwieldy
>>> when you h
On Tue, Sep 02, 2014 at 10:27:37AM +0200, Kay Sievers wrote:
> On Tue, Sep 2, 2014 at 10:01 AM, John Haxby wrote:
> >
> > On 2 Sep 2014, at 06:55, Kay Sievers wrote:
> >
> >> On Tue, Sep 2, 2014 at 5:22 AM, Zhenzhong Duan
> >> wrote:
> >>> Cpu doesn't get online automaticly after hotplug when we
On Tue, Sep 2, 2014 at 5:11 PM, Colin Guthrie wrote:
>
> John Haxby wrote on 02/09/14 10:31:
>> Col, forgive my ignorance, but cpuadd@$name.service seems to imply that
>> you'd have one file or symlink per CPU. That's going to be unwieldy
>> when you have hundreds of CPUs isn't it?
>
> Not quite.
John Haxby wrote on 02/09/14 10:31:
> Col, forgive my ignorance, but cpuadd@$name.service seems to imply that
> you'd have one file or symlink per CPU. That's going to be unwieldy
> when you have hundreds of CPUs isn't it?
Not quite. systemd units with an @ in them are a bit special. You have
on
On 02/09/14 09:42, Colin Guthrie wrote:
> Kay Sievers wrote on 02/09/14 09:27:
>> On Tue, Sep 2, 2014 at 10:01 AM, John Haxby wrote:
>>>
>>> On 2 Sep 2014, at 06:55, Kay Sievers wrote:
>>>
On Tue, Sep 2, 2014 at 5:22 AM, Zhenzhong Duan
wrote:
> Cpu doesn't get online automaticly af
On 2014-9-2 16:25, Kay Sievers wrote:
On Tue, Sep 2, 2014 at 8:12 AM, Zhenzhong Duan
wrote:
On 2014-9-2 13:55, Kay Sievers wrote:
On Tue, Sep 2, 2014 at 5:22 AM, Zhenzhong Duan
wrote:
Cpu doesn't get online automaticly after hotplug when we test guest cpu
add/remove in xen env.
I don't hav
Kay Sievers wrote on 02/09/14 09:27:
> On Tue, Sep 2, 2014 at 10:01 AM, John Haxby wrote:
>>
>> On 2 Sep 2014, at 06:55, Kay Sievers wrote:
>>
>>> On Tue, Sep 2, 2014 at 5:22 AM, Zhenzhong Duan
>>> wrote:
Cpu doesn't get online automaticly after hotplug when we test guest cpu
add/remov
On Tue, Sep 2, 2014 at 10:01 AM, John Haxby wrote:
>
> On 2 Sep 2014, at 06:55, Kay Sievers wrote:
>
>> On Tue, Sep 2, 2014 at 5:22 AM, Zhenzhong Duan
>> wrote:
>>> Cpu doesn't get online automaticly after hotplug when we test guest cpu
>>> add/remove in xen env.
>>>
>>> I don't have an baremeta
On Tue, Sep 2, 2014 at 8:12 AM, Zhenzhong Duan
wrote:
> On 2014-9-2 13:55, Kay Sievers wrote:
>>
>> On Tue, Sep 2, 2014 at 5:22 AM, Zhenzhong Duan
>> wrote:
>>>
>>> Cpu doesn't get online automaticly after hotplug when we test guest cpu
>>> add/remove in xen env.
>>>
>>> I don't have an baremetal
On 2 Sep 2014, at 06:55, Kay Sievers wrote:
> On Tue, Sep 2, 2014 at 5:22 AM, Zhenzhong Duan
> wrote:
>> Cpu doesn't get online automaticly after hotplug when we test guest cpu
>> add/remove in xen env.
>>
>> I don't have an baremetal env to test this, but I think it's same.
>>
>> The rule is
On 2014-9-2 13:55, Kay Sievers wrote:
On Tue, Sep 2, 2014 at 5:22 AM, Zhenzhong Duan
wrote:
Cpu doesn't get online automaticly after hotplug when we test guest cpu
add/remove in xen env.
I don't have an baremetal env to test this, but I think it's same.
The rule is missed in systemd but exist
On Tue, Sep 2, 2014 at 5:22 AM, Zhenzhong Duan
wrote:
> Cpu doesn't get online automaticly after hotplug when we test guest cpu
> add/remove in xen env.
>
> I don't have an baremetal env to test this, but I think it's same.
>
> The rule is missed in systemd but exist in legacy udev.
Udev is not a
Cpu doesn't get online automaticly after hotplug when we test guest cpu
add/remove in xen env.
I don't have an baremetal env to test this, but I think it's same.
The rule is missed in systemd but exist in legacy udev.
Signed-off-by: Zhenzhong Duan
---
rules/50-udev-default.rules |2 ++
1
24 matches
Mail list logo
