Re: [systemd-devel] Creating executable device nodes in /dev?

On Wed, Dec 9, 2020 at 11:22 AM Topi Miettinen wrote: > > On 9.12.2020 17.14, Andy Lutomirski wrote: > > > Maybe also malware which can escape all means of detection, enforced by > the CPU? Though I don't know if any malware scanners for Linux work can > check for fileless

Re: [systemd-devel] Creating executable device nodes in /dev?

> On Dec 9, 2020, at 12:58 AM, Topi Miettinen wrote: > > On 9.12.2020 2.42, Jarkko Sakkinen wrote: >>> On Wed, Dec 09, 2020 at 02:15:28AM +0200, Jarkko Sakkinen wrote: >>> On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote: >>> As a further argument, I just did this on a

Re: [systemd-devel] Creating executable device nodes in /dev?

> On Dec 8, 2020, at 12:45 PM, Topi Miettinen wrote: > > On 8.12.2020 20.07, Andy Lutomirski wrote: >>> On Thu, Nov 19, 2020 at 10:05 AM Topi Miettinen wrote: >>> >>> On 19.11.2020 18.32, Zbigniew Jędrzejewski-Szmek wrote: >>>> On Thu, Nov 19,

Re: [systemd-devel] Creating executable device nodes in /dev?

On Thu, Nov 19, 2020 at 10:05 AM Topi Miettinen wrote: > > On 19.11.2020 18.32, Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Nov 19, 2020 at 08:17:08AM -0800, Andy Lutomirski wrote: > >> Hi udev people- > >> > >> The upcoming Linux SGX driver has a devi

[systemd-devel] Creating executable device nodes in /dev?

Hi udev people- The upcoming Linux SGX driver has a device node /dev/sgx. User code opens it, does various setup things, mmaps it, and needs to be able to create PROT_EXEC mappings. This gets quite awkward if /dev is mounted noexec. Can udev arrange to make a device node executable on distros

Re: [systemd-devel] kdbus refactoring?

On Mon, Nov 9, 2015 at 9:07 AM, Greg KH <gre...@linuxfoundation.org> wrote: > On Mon, Nov 09, 2015 at 05:02:45PM +, Måns Rullgård wrote: >> Andy Lutomirski <l...@amacapital.net> writes: >> >> > On Sun, Nov 8, 2015 at 3:30 PM, Greg KH <gre...@linuxfoun

Re: [systemd-devel] kdbus refactoring?

On Sun, Nov 8, 2015 at 3:30 PM, Greg KH wrote: > On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote: >> On Sun, Nov 8, 2015 at 10:35 PM, Greg KH wrote: >> > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote:

[systemd-devel] Add ambient capability support to execution environment config?

For non-root services, getting Capabilities= and CapabilityBoundingSet= to do anything useful is rather tricky. Would it make sense to add AmbientCapabilities= to set ambient (and, implicitly, inheritable) capabilities, which will be available in Linux 4.3? Alternatively, there could be a

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

On Apr 20, 2015 7:57 AM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 17.04.15 09:14, Andy Lutomirski (l...@amacapital.net) wrote: My point here is that there's no real shortage of downsides to this scheme, and there still appears to be little to no benefit. Well, let's turn

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

On Apr 20, 2015 9:07 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 20.04.15 08:51, Andy Lutomirski (l...@amacapital.net) wrote: I will grant you that they aren't particularly expressive, and I will grant you that one day there might be better concepts. But that's

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

On Apr 20, 2015 8:22 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 20.04.15 08:08, Andy Lutomirski (l...@amacapital.net) wrote: On Apr 20, 2015 7:57 AM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 17.04.15 09:14, Andy Lutomirski (l...@amacapital.net) wrote

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

On Apr 17, 2015 4:53 AM, Djalal Harouni tix...@opendz.org wrote: Hi Andy, On Thu, Apr 16, 2015 at 12:30:28PM -0700, Andy Lutomirski wrote: On Thu, Apr 16, 2015 at 11:23 AM, Lennart Poettering lenn...@poettering.net wrote: [...] AFAICT this piece of kdbus code serves to enable a rather

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

On Apr 17, 2015 5:42 AM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 16/04/15 15:52, Andy Lutomirski wrote: (I really think this dichotomy needs to be removed, *especially* since it looks like code already exists to try to use both metadata sources. This seems like it's just

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

On Apr 17, 2015 6:05 AM, Cristian Rodríguez crrodrig...@opensuse.org wrote: On Fri, Apr 17, 2015 at 7:51 AM, Lennart Poettering lenn...@poettering.net wrote: Groups *suck* as authentication scheme. If you add one group for each privilege you want, then you'll have a huge number of groups,

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

On Thu, Apr 16, 2015 at 3:23 AM, Tom Gundersen t...@jklm.no wrote: Hi Andy, On Thu, Apr 16, 2015 at 2:55 AM, Andy Lutomirski l...@amacapital.net wrote: Yesterday, I discovered SD_BUS_VTABLE_CAPABILITY. Are there any examples in which it does anything? Please note that you need to be using

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

On Thu, Apr 16, 2015 at 8:59 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 16.04.15 07:52, Andy Lutomirski (l...@amacapital.net) wrote: I'm looking at sd_bus_query_sender_privilege, which does: r = sd_bus_query_sender_creds(call, SD_BUS_CREDS_UID|SD_BUS_CREDS_EUID

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

On Thu, Apr 16, 2015 at 9:43 AM, Tom Gundersen t...@jklm.no wrote: On Thu, Apr 16, 2015 at 4:52 PM, Andy Lutomirski l...@amacapital.net wrote: Unshare your user namespace, set things up right, and systemd or any other server will see you as having all capabilities. You've fixed that in kdbus

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

On Thu, Apr 16, 2015 at 10:43 AM, Tom Gundersen t...@jklm.no wrote: On Thu, Apr 16, 2015 at 5:57 PM, Andy Lutomirski l...@amacapital.net wrote: We have several uses of this, see my mail to Jiri regarding CAP_SYS_BOOT for instance: https://lkml.org/lkml/2015/4/16/219 I read that, but I

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

On Thu, Apr 16, 2015 at 10:30 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 16.04.15 09:53, Andy Lutomirski (l...@amacapital.net) wrote: It's a noop, unless people OR in SD_BUS_CREDS_AUGMENT into the flags of creds they want. Doing this basically voids your warranty: it means

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

On Thu, Apr 16, 2015 at 11:23 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 16.04.15 10:52, Andy Lutomirski (l...@amacapital.net) wrote: It would be very helpful if you could go into details on why you think more care is needed here than for other things. Is there anything

[systemd-devel] SD_BUS_VTABLE_CAPABILITY

Hi all- Yesterday, I discovered SD_BUS_VTABLE_CAPABILITY. Are there any examples in which it does anything? If so, I don't suppose any of you could give me an example of: $ cp `which dbus-send` . $ sudo setcap all=eip dbus-send $ dbus-send [not sure what goes here] that passes an

Re: [systemd-devel] systemd-vconsole-setup fails very slowly

On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski l...@amacapital.net wrote: On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 21.01.15 19:15, Andy Lutomirski (l...@amacapital.net) wrote: Hi all- When running virtme (a simple vm gadget) on Fedora 21

Re: [systemd-devel] systemd-vconsole-setup fails very slowly

On Wed, Apr 1, 2015 at 12:32 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Apr 1, 2015 at 8:56 PM, Andy Lutomirski l...@amacapital.net wrote: On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski l...@amacapital.net wrote: On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering lenn...@poettering.net

Re: [systemd-devel] systemd-vconsole-setup fails very slowly

On Wed, Apr 1, 2015 at 2:36 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Apr 1, 2015 at 11:19 PM, Andy Lutomirski l...@amacapital.net wrote: On Wed, Apr 1, 2015 at 1:53 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Apr 1, 2015 at 10:45 PM, Andy Lutomirski l...@amacapital.net wrote: On Apr 1

Re: [systemd-devel] systemd-vconsole-setup fails very slowly

On Wed, Apr 1, 2015 at 2:47 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Apr 1, 2015 at 11:38 PM, Andy Lutomirski l...@amacapital.net wrote: On Wed, Apr 1, 2015 at 2:36 PM, Kay Sievers k...@vrfy.org wrote: They should only get created when something accesses the corresponding tty. deallocvt(1

Re: [systemd-devel] systemd-vconsole-setup fails very slowly

On Wed, Apr 1, 2015 at 1:53 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Apr 1, 2015 at 10:45 PM, Andy Lutomirski l...@amacapital.net wrote: On Apr 1, 2015 12:56 PM, Kay Sievers k...@vrfy.org wrote: Do you have an idea why the VM does not accept the custom font? If that is something obvious

Re: [systemd-devel] systemd-vconsole-setup fails very slowly

On Apr 1, 2015 12:56 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Apr 1, 2015 at 9:36 PM, Andy Lutomirski l...@amacapital.net wrote: On Wed, Apr 1, 2015 at 12:32 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Apr 1, 2015 at 8:56 PM, Andy Lutomirski l...@amacapital.net wrote: On Thu, Jan

Re: [systemd-devel] systemd-vconsole-setup fails very slowly

On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 21.01.15 19:15, Andy Lutomirski (l...@amacapital.net) wrote: Hi all- When running virtme (a simple vm gadget) on Fedora 21, the slowest part of bootup by far appears to be systemd-vconsole-setup

[systemd-devel] systemd-vconsole-setup fails very slowly

Hi all- When running virtme (a simple vm gadget) on Fedora 21, the slowest part of bootup by far appears to be systemd-vconsole-setup: # time /usr/lib/systemd/systemd-vconsole-setup putfont: PIO_FONT trying ... ... setfont: putfont: 512,8x16: failed: -1 putfont: PIO_FONT:

Re: [systemd-devel] Supporting U2F over HID on Linux?

On Tue, Dec 9, 2014 at 12:46 PM, Andy Lutomirski l...@amacapital.net wrote: On Mon, Nov 3, 2014 at 12:41 PM, Andy Lutomirski l...@amacapital.net wrote: On Mon, Nov 3, 2014 at 12:21 PM, Jiri Kosina jkos...@suse.cz wrote: On Mon, 3 Nov 2014, David Herrmann wrote: Agreed, mostly. My only real

Re: [systemd-devel] Supporting U2F over HID on Linux?

On Mon, Nov 3, 2014 at 12:41 PM, Andy Lutomirski l...@amacapital.net wrote: On Mon, Nov 3, 2014 at 12:21 PM, Jiri Kosina jkos...@suse.cz wrote: On Mon, 3 Nov 2014, David Herrmann wrote: Agreed, mostly. My only real concern is that this could be annoying for the userspace developers who

Re: [systemd-devel] [RFC PATCH] proc, pidns: Add highpid

. The former prevents anyone from confusing highpid with regular pid, and the latter means that we don't need to worry about confusion between errors and valid highpids (e.g. -1 will never be a highpid). Implementing that will be only mildly annoying. --Andy On Sat, Nov 29, 2014 at 2:05 AM, Andy Lutomirski

Re: [systemd-devel] [RFC PATCH] proc, pidns: Add highpid

On Mon, Dec 1, 2014 at 8:39 AM, Konstantin Khlebnikov koc...@gmail.com wrote: On Mon, Dec 1, 2014 at 7:21 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 30, 2014 at 11:03 PM, Konstantin Khlebnikov koc...@gmail.com wrote: Hmm. What about per-task/thread UUID? exported via separate

Re: [systemd-devel] [RFC PATCH] proc, pidns: Add highpid

On Nov 30, 2014 9:45 AM, David Herrmann dh.herrm...@gmail.com wrote: Hi Andy On Sat, Nov 29, 2014 at 12:05 AM, Andy Lutomirski l...@amacapital.net wrote: Pid reuse is common, which means that it's difficult or impossible to read information about a pid from /proc without races

Re: [systemd-devel] [RFC PATCH] proc, pidns: Add highpid

On Nov 30, 2014 1:47 AM, Florian Weimer f...@deneb.enyo.de wrote: * Andy Lutomirski: The initial implementation is straightforward: highpid is simply a 64-bit counter. If a high-end system can fork every 3 ns (which would be amazing, given that just allocating a pid requires at atomic

Re: [systemd-devel] [RFC PATCH] proc, pidns: Add highpid

On Nov 28, 2014 9:24 PM, Greg KH g...@kroah.com wrote: On Fri, Nov 28, 2014 at 03:05:01PM -0800, Andy Lutomirski wrote: Pid reuse is common, which means that it's difficult or impossible to read information about a pid from /proc without races. This introduces a second number associated

[systemd-devel] [RFC PATCH] proc, pidns: Add highpid

stuff only works on 64-bit systems. If the approach looks good, I'll fix that somehow. Signed-off-by: Andy Lutomirski l...@amacapital.net --- If this goes in, there's plenty of room to add new interfaces to make this more useful. For example, we could add a fancier tgkill that adds and validates

Re: [systemd-devel] [RFC PATCH] proc, pidns: Add highpid

[Adding CRIU people. Whoops.] On Fri, Nov 28, 2014 at 3:05 PM, Andy Lutomirski l...@amacapital.net wrote: Pid reuse is common, which means that it's difficult or impossible to read information about a pid from /proc without races. This introduces a second number associated with each (task

Re: [systemd-devel] [PATCH] udev: Add hidraw_id and a rule file to invoke it

On Mon, Nov 3, 2014 at 5:32 AM, Tom Gundersen t...@jklm.no wrote: Hi Andy, On Tue, Oct 28, 2014 at 11:46 PM, Andy Lutomirski l...@amacapital.net wrote: So far, hidraw_id detects U2F tokens and sets: ID_U2F_TOKEN=1 ID_SECURITY_TOKEN=1 This causes the uaccess rules to apply to U2F devices

Re: [systemd-devel] Supporting U2F over HID on Linux?

On Mon, Nov 3, 2014 at 11:03 AM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski l...@amacapital.net wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices

Re: [systemd-devel] Supporting U2F over HID on Linux?

-- Andy Lutomirski AMA Capital Management, LLC ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Supporting U2F over HID on Linux?

I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something

Re: [systemd-devel] Supporting U2F over HID on Linux?

On Sun, Nov 2, 2014 at 12:42 PM, Jiri Kosina jkos...@suse.cz wrote: On Sun, 2 Nov 2014, Andy Lutomirski wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent

Re: [systemd-devel] Supporting U2F over HID on Linux?

On Sun, Nov 2, 2014 at 12:47 PM, Tom Gundersen t...@jklm.no wrote: Hi Andy, On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski l...@amacapital.net wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices

Re: [systemd-devel] Supporting U2F over HID on Linux?

to further extend the kernel API for U2F, the group will already be in place. Cheers, Benjamin -- Andy Lutomirski AMA Capital Management, LLC ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman

Re: [systemd-devel] Supporting U2F over HID on Linux?

On Sun, Nov 2, 2014 at 3:01 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 5:49 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 2:45 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 4:40 PM, Jiri Kosina

Re: [systemd-devel] Supporting U2F over HID on Linux?

On Sun, Nov 2, 2014 at 4:40 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 6:34 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 3:01 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 5:49 PM, Andy

Re: [systemd-devel] [PATCH] udev: Add hidraw_id and a rule file to invoke it

On Tue, Oct 28, 2014 at 3:46 PM, Andy Lutomirski l...@amacapital.net wrote: So far, hidraw_id detects U2F tokens and sets: ID_U2F_TOKEN=1 ID_SECURITY_TOKEN=1 This causes the uaccess rules to apply to U2F devices. This works for the Plug-up security key, too. --Andy --- I've never

Re: [systemd-devel] Writing a udev rule for U2F security tokens?

On Tue, Oct 28, 2014 at 1:40 AM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Oct 27, 2014 at 04:37:14PM -0700, Andy Lutomirski wrote: On Mon, Oct 27, 2014 at 4:32 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Oct 27, 2014 at 04:12:30PM -0700, Andy Lutomirski wrote: Hi- I'd

[systemd-devel] [PATCH] udev: Add hidraw_id and a rule file to invoke it

So far, hidraw_id detects U2F tokens and sets: ID_U2F_TOKEN=1 ID_SECURITY_TOKEN=1 This causes the uaccess rules to apply to U2F devices. --- I've never written any udev code before. Feedback welcome. If you think this doesn't belong in udev, I can try to find it another home. .gitignore

[systemd-devel] Writing a udev rule for U2F security tokens?

Hi- I'd like to write a generic udev rule for U2F security tokens and to possibly get it integrated into systemd / udev, but I'm not sure how to write it in the first place. U2F tokens are USB HID devices that have a usage page 0xF1D0 that contains usage 0x01. The rule should match any hidraw

Re: [systemd-devel] Writing a udev rule for U2F security tokens?

On Mon, Oct 27, 2014 at 4:32 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Oct 27, 2014 at 04:12:30PM -0700, Andy Lutomirski wrote: Hi- I'd like to write a generic udev rule for U2F security tokens and to possibly get it integrated into systemd / udev, but I'm not sure how to write

Re: [systemd-devel] [PATCH] udev: fail firmware loading immediately if no search path is defined

On Wed, Aug 7, 2013 at 12:52 AM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: Op 07-08-13 02:26, Andy Lutomirski schreef: On Tue, Aug 6, 2013 at 5:24 PM, Tom Gundersen t...@jklm.no wrote: On 6 Aug 2013 18:32, Bryan Kadzban br...@kadzban.is-a-geek.net wrote: On Tue, Aug 06, 2013 at 11:17

Re: [systemd-devel] [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it

On Tue, Aug 6, 2013 at 2:17 AM, Tom Gundersen t...@jklm.no wrote: On Tue, Aug 6, 2013 at 11:11 AM, Tom Gundersen t...@jklm.no wrote: On Tue, Aug 6, 2013 at 10:20 AM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: Op 05-08-13 18:29, Andy Lutomirski schreef: The systemd commit below can delay

Re: [systemd-devel] [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it

at 10:20 AM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: Op 05-08-13 18:29, Andy Lutomirski schreef: The systemd commit below can delay firmware loading by multiple minutes if CONFIG_FW_LOADER_USER_HELPER=y. Unfortunately no one noticed that the systemd-udev change would break new

Re: [systemd-devel] Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load)

On Mon, Aug 5, 2013 at 4:18 AM, Kay Sievers k...@vrfy.org wrote: On Fri, Aug 2, 2013 at 6:28 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Fri, Aug 02, 2013 at 09:04:44AM -0700, Andy Lutomirski wrote: CONFIG_FW_LOADER_USER_HELPER=y Do you need this? Unsetting this should help

[systemd-devel] [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it

The systemd commit below can delay firmware loading by multiple minutes if CONFIG_FW_LOADER_USER_HELPER=y. Unfortunately no one noticed that the systemd-udev change would break new kernels as well as old kernels. Since the kernel apparently can't count on reasonable userspace support, turn this

[systemd-devel] Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load)

[cc: linux-kernel, linux-hotplug, and systemd-devel. This is 3.11-rc3+] On Fri, Aug 2, 2013 at 12:38 AM, Johannes Berg johan...@sipsolutions.net wrote: On Thu, 2013-08-01 at 21:38 -0700, Andy Lutomirski wrote: At boot, I get: [ 12.537108] iwlwifi :03:00.0: irq 51 for MSI/MSI-X

Re: [systemd-devel] Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load)

On Fri, Aug 2, 2013 at 9:21 AM, Johannes Berg johan...@sipsolutions.net wrote: On Fri, 2013-08-02 at 09:04 -0700, Andy Lutomirski wrote: It wasn't exactly fixed and it's really more of a userspace problem - we probably request firmware version 8, and then it takes 30 seconds to time out

Re: [systemd-devel] [HEADSUP] cgroup changes

On Jun 25, 2013 2:43 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 24.06.13 17:09, Andy Lutomirski (l...@amacapital.net) wrote: On Mon, Jun 24, 2013 at 4:57 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 24.06.13 16:01, Andy Lutomirski (l...@amacapital.net

Re: [systemd-devel] [HEADSUP] cgroup changes

On 06/21/2013 10:36 AM, Lennart Poettering wrote: 2) This hierarchy becomes private property of systemd. systemd will set it up. Systemd will maintain it. Systemd will rearrange it. Other software that wants to make use of cgroups can do so only through systemd's APIs. This single-writer logic

Re: [systemd-devel] [HEADSUP] cgroup changes

On Mon, Jun 24, 2013 at 6:27 AM, Lennart Poettering lenn...@poettering.net wrote: On Sat, 22.06.13 15:19, Andy Lutomirski (l...@amacapital.net) wrote: 2. I manage services and tasks outside systemd (for one thing, I currently use Ubuntu, but even if I were on Fedora, I have a bunch of fine

Re: [systemd-devel] [HEADSUP] cgroup changes

On Mon, Jun 24, 2013 at 12:10 PM, Tejun Heo t...@kernel.org wrote: Hello, Andy. On Mon, Jun 24, 2013 at 11:49:05AM -0700, Andy Lutomirski wrote: I have an idea where it should be headed in the long term but am not sure about short-term solution. Given that the only sort wide-spread use

Re: [systemd-devel] [HEADSUP] cgroup changes

On Mon, Jun 24, 2013 at 12:37 PM, Tejun Heo t...@kernel.org wrote: Hello, On Mon, Jun 24, 2013 at 12:24:38PM -0700, Andy Lutomirski wrote: Because more things are becoming per cpu without the option of moving of per-cpu things on behalf of one cpu to another cpu. RCU is a nice exception

Re: [systemd-devel] [HEADSUP] cgroup changes

On Mon, Jun 24, 2013 at 4:19 PM, Tejun Heo t...@kernel.org wrote: Hello, On Mon, Jun 24, 2013 at 04:01:07PM -0700, Andy Lutomirski wrote: So what is cgroup for? That is, what's the goal for what the new API should be able to do? It is a for controlling and distributing resources

Re: [systemd-devel] [HEADSUP] cgroup changes

On Mon, Jun 24, 2013 at 4:37 PM, Tejun Heo t...@kernel.org wrote: Hello, Andy. On Mon, Jun 24, 2013 at 04:27:17PM -0700, Andy Lutomirski wrote: I guess what I'm trying to say here is that many systems will rather fundamentally use systemd. Admins of those systems should still have access

Re: [systemd-devel] [HEADSUP] cgroup changes

On Mon, Jun 24, 2013 at 4:40 PM, Tejun Heo t...@kernel.org wrote: Hello, On Mon, Jun 24, 2013 at 4:38 PM, Andy Lutomirski l...@amacapital.net wrote: Now I'm confused. I thought that support for multiple hierarchies was going away. Is it here to stay after all? It is going to be deprecated

Re: [systemd-devel] [HEADSUP] cgroup changes

On Mon, Jun 24, 2013 at 4:57 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 24.06.13 16:01, Andy Lutomirski (l...@amacapital.net) wrote: AFAICT the main reason that systemd uses cgroup is to efficiently track which service various processes came from and to send signals