Re: [systemd-devel] Designing a scheduler interface
Hi Daniel, Thanks for getting in touch. On Thu, Jan 13, 2011 at 5:29 PM, Daniel Poelzleithner poe...@poelzi.org wrote: What is currently unknown on the other hand is the current active X window in use. This could be done by connecting tho X and reacting to events there, but I think a cleaner approach would be that the window manager signals the running optimisation daemon that a given program is of user importance. May it be that the program has focus or is visible on the screen. I would like to have a standard dbus interface for this. Would ConsoleKit not know which is the currently active session on a given seat? Another problem I expect are clashes between systems that try to control similar kernel subsystems. systemd at least uses cgroups in some parts. We need to define some interface between init and the scheduling daemon if one is running. Elsewise some expected behaviour won't work. When init signals the optimizer the importance of services, this could be taken into account for the decision he makes. A cgroup hierarchy is associated with particular subsystems, and you can have many cgroup hierarchies. As long as the init daemon is not using the same subsystem as you, you can simply control it using an entirely separate hierarchy, though it would be up to you to move tasks into and out of your own. If there were overlap, some care would be required, because the init daemon may be using the cgroup for supervision purposes - removing a task from the group could mean the init daemon believes the service is no longer running. One obvious solution here is to move tasks into sub-groups with differing parameters and expect the init daemon to clean up when empty (as it's in its own hierarchy). Assuming the above, I don't see any real need for a complex interaction between them - the interface is the existing kernel interfaces. Unless I've wildly missed the point ;-) Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] use /run instead of /dev/.run
Ludwig Nussel wrote: mount --bind /var/run /mnt mount /var mount -M /mnt /var/run This doesn't work. It means there is a period during boot where /var/run suddenly vanishes (when mount the separate /var). You have to do: mount DEV_OF_VAR /mnt mount --bind /var/run /mnt/run mount -M /mnt /var We do this in Ubuntu. But I would certainly support a new /run to replace all the previous incarnations; viz. /lib/init/rw, /dev/.initramfs, /dev/.run, /var/run /var/lock; with one true location that's always writable during boot. Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle and init
There is, of course, one use for settle; I like to have a monitor running during boot that creates /var/log/udev - settle is as good a command as any to kill monitor when it's done. On Thu, Mar 31, 2011 at 11:35 AM, Kay Sievers kay.siev...@vrfy.org wrote: Hey, the underlying problem described below, is in no way specific to systemd, it applies to all modern systems and services, existing ones, or ones not even developed. The udev systemd service files for udev do no longer pull-in the barrier 'udevadm settle'. The udev coldplug run is executed fully asynchronously in the background along with many other services, and no other service will be blocked by default, waiting for udev to populate /dev. That means: non-hotplug-aware services are likely to break. Services which assume a static /dev, rely on scanning /dev and finding all devices at a certain point in time, are required to explicitly pull-in udev-settle.service to paper-over their inability to cope with a dynamic system. It will block the broken service until udev's coldplug run has finished and /dev is populated with all devices known at that time. It's 2011 and services should cope with hotplug, devices coming and going at any time, and a constantly changing and re-configuring environment. No service which wants survive the next years of Linux evolution should depend on the udev-settle.service barrier though, please fix your stuff, or the reality might go on without you. :) There is libudev, which connects your service to meaningful event for news devices, device changes, and allows you to enumerate all currently existing devices. Subscribing to events before enumeration is started will make sure not to miss anything, and to propagate later changes into the service. All that even works from python, java, mono, javascript, ... programs, so there is no excuse anymore to continue to do any of the much-too-simple things we all did in the past. Just stop making assumptions like: booting has finished or all devices are there -- that never really was in the past, and it will never be true in the future. Thanks, Kay -- To unsubscribe from this list: send the line unsubscribe linux-hotplug in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] device units rely on udev rules?
Another question I wasn't able to find an answer to in the documentation I've read so far. The use of device units seems to very much rely on udevd running on the system, and not only that, udev rules having been parsed for the device and a systemd tag set in the udevdb. udev obviously starts after systemd, and systemd starts after the kernel. This means there are a large number of devices already known to the kernel at the point that systemd starts, especially if you build the drivers into the kernel for those devices. It's possible to get going straight away with those devices. But relying on udevd tagging them means you end up waiting around for udevd to start, and worse! since udevd doesn't apply rules to existing devices on startup, you have to wait around for udevadm trigger to be run. Given that devtmpfs means the device nodes are already available, and systemd will be merging the ACL handling from CK/udev into itself, why does systemd rely on udev coldplugging in this way? All that's left for udevd to do at this point is device groups (which should go really away on any modern distro) and symlinks. There are probably many systems out there (hi!) that care so little about symlinks that they're happy for udevd to be started non-critically in the boot, and consider the udevadm trigger run a necessity that's probably the last thing to run. What are the long term plans here? Do you envision this staying the way it is? Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Parallel startup with sockets and without killing the machine?
On Tue, May 10, 2011 at 7:41 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I'm not following all the user-session discussion, but AFAIU this management will be done by the same code, but not same process (it's not PID1). PAM (or another entity that has a role in the login/logout) will talk to systemd (PID1) and ask for a new service to be started to handle this user-session. This will still be the same code, but of course on the user context and not handle things like actual reboot/halt of the machine, mounting system filesystems. But again, I'm not following it closely and I might be wrong here. That's a shame. Having it as a separate process would mean the user session would be started all at once in one go at the end of the boot, rather than with the rest of the boot :-( Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] device units rely on udev rules?
On Mon, May 9, 2011 at 12:43 PM, Lennart Poettering lenn...@poettering.netwrote: This means there are a large number of devices already known to the kernel at the point that systemd starts, especially if you build the drivers into the kernel for those devices. It's possible to get going straight away with those devices. But relying on udevd tagging them means you end up waiting around for udevd to start, and worse! since udevd doesn't apply rules to existing devices on startup, you have to wait around for udevadm trigger to be run. That's actually dead fast, and systemd picks up those devices as they show up. The trigger can hence finish after we already preceeded booting. In fact, with the new netlink actviation in newest udev and systemd we can start the trigger at the same time as udev itself. We cannot really mount file systems before their block devices have shown up and have been probed, and we exactly wait for that, and no longer. To do fsck/mount we need udev to have run for that device, there's no realistic way around that. It isn't dead fast enough. The problem is that when you run udevadm trigger, it doesn't immediately spawn 700 processes to handle the events. So you end up with situations where input devices aren't available to X because the system is too busy probing for filesystems, or loading sound card drivers. And we really *can* mount file systems before their block devices have been probed (they show up as soon as the driver's loaded). Actually the probing code is exactly the kind of code I would want to delay; filesystems can be mounted by GPT ids which doesn't require the expensive block device probing. To my mind, we would want the filesystem mounted as soon as the kernel event arrives, whether or not udevd is running and whether or not udevadm trigger has been run. udev isn't just about symlinks. It's about perms and primarily about meta data, and a lot of other stuff too. perms are increasingly irrelevant due to ACLs, which your plans are moving to systemd, no? Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Communicating need
On Mon, May 16, 2011 at 2:23 PM, Lennart Poettering lenn...@poettering.netwrote: Our entire userspace bootup takes 1s here on an older X300. I think nobody expects that the mouse reacts any quicker than that. Your older X300 is probably rather more powerful than a single-core Atom CPU. But as mentioned elsewhere: if this really is a problem we could modify udev trigger to sort the devices according to some user specific rules before triggering them. That way we can ensure that input gets triggered before network, or whatever else you want to express. But again, I'd really like to see this profiled before look into this. Right now if userspace booting takes 1s this should be more then sufficiently good for desktop machines, include ChromeOS machines. It depends what you mean by userspace booting. We are able to start the entire system, X server and Chromium browser in about 2.2s It takes about 5-6s for udev to run input_id on the keyboard + touchpad, and thus for them to be available to X. Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Communicating need
On Mon, May 16, 2011 at 2:46 PM, Lennart Poettering lenn...@poettering.netwrote: It takes about 5-6s for udev to run input_id on the keyboard + touchpad, and thus for them to be available to X. How come this takes so long? Does this actually delay X? Nromally X should be fine without kbd/mouse and then be able to make use of it the moment it becomes available? Well, X is sitting there with a nice screen that the user can't use because the keyboard and touchpad don't work yet ... so no, it doesn't delay X, it delays the user experience ;-) Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
