Re: [systemd-devel] [PATCH v2] Detect page size runtime
2011/3/19 Jan Engelhardt : > On Saturday 2011-03-19 03:10, Lennart Poettering wrote: > >>On Fri, 18.03.11 03:44, fykc...@gmail.com (fykc...@gmail.com) wrote: >> >>> Hi all, >>> >>> Systemd hardcode page size as 4096(in macro.h), this is not always correct: >>> """ Some architectures support multiple machine types with diffenent >>> page sizes, and some machine types even support multiple page sizes >>> themselves. """ >>> >>> This patch tries to detect page size runtime by sysconf(_SC_PAGESIZE), >>> and uses 4096 as a failsafe value. Note we need memset vec to zero >>> before call mincore(src/readahead-collect.c, 129) -- if the pagesize >>> is not correct, we may randomly record wider range or more ranges to >>> readahead. >> >>Hmm, interesting. Which architecture are you using that has a page size >>!= 4K? > > sparc64 would, to name one. IA64, sparc64, powerpc, and mips, they can configure different page size(e.g. range from 4K - 32K) at kernel config time. Changes since v1: 1. Rename get_pagesize() to page_size(), fix C99 violation, and move PAGE_ALIGN and page_size() to util.h and util.c. 2. page_size() now use static tls variable , it will call sysconf only once for each thread. 3. Remove page size related stuff from readahead-*.c/h. Note: I still keep a warning of sysconf call failure in page_size(), this may help to indicate broken sysconf implementation on some platform. (IMHO, sysconf(_SC_PAGESIZE) should never fail.) Any idea? -- Regards, - cee1 0001-Detect-page-size-runtime.patch Description: Binary data ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Improve boot-time of systemd
2011/3/18 Kay Sievers : > On Fri, Mar 18, 2011 at 14:40, Gustavo Sverzut Barbieri > wrote: >> On Fri, Mar 18, 2011 at 10:52 AM, Andrey Borzenkov wrote: >>> On Fri, Mar 18, 2011 at 12:35 PM, fykc...@gmail.com >>> wrote: > 1. What can readahead affect boot-time? Sadly observed negative affect -- boot-time increases at least 1s. >>> >>> From subjective feelings (no real measurements) I confirm it. >> >> I noticed it as well, even with my Macbook Pro i7 with 8Gb RAM and >> 128SSD using btrfs. > > It's ~0.5 sec faster here with readahead on a SSD. Each time runs readahead-replay may cause readahead-collect to record more blocks to read ahead -- size of "/.readahead" never reduces. Also I found "/.readahead" recorded files like ".xession-errors" which is written only, thus should not be read ahead. Maybe adjust readahead-collect-done.timer to 5s will help. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Detect page size runtime
On Saturday 2011-03-19 03:10, Lennart Poettering wrote: >On Fri, 18.03.11 03:44, fykc...@gmail.com (fykc...@gmail.com) wrote: > >> Hi all, >> >> Systemd hardcode page size as 4096(in macro.h), this is not always correct: >> """ Some architectures support multiple machine types with diffenent >> page sizes, and some machine types even support multiple page sizes >> themselves. """ >> >> This patch tries to detect page size runtime by sysconf(_SC_PAGESIZE), >> and uses 4096 as a failsafe value. Note we need memset vec to zero >> before call mincore(src/readahead-collect.c, 129) -- if the pagesize >> is not correct, we may randomly record wider range or more ranges to >> readahead. > >Hmm, interesting. Which architecture are you using that has a page size >!= 4K? sparc64 would, to name one. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Detect page size runtime
On Fri, 18.03.11 03:44, fykc...@gmail.com (fykc...@gmail.com) wrote: > Hi all, > > Systemd hardcode page size as 4096(in macro.h), this is not always correct: > """ Some architectures support multiple machine types with diffenent > page sizes, and some machine types even support multiple page sizes > themselves. """ > > This patch tries to detect page size runtime by sysconf(_SC_PAGESIZE), > and uses 4096 as a failsafe value. Note we need memset vec to zero > before call mincore(src/readahead-collect.c, 129) -- if the pagesize > is not correct, we may randomly record wider range or more ranges to > readahead. Hmm, interesting. Which architecture are you using that has a page size != 4K? Please move the definition of ALIGN and page_size() and friends into util.[ch], rather the the .c files using them. "size_t get_pagesize();" is not a valid C99 function prototype. Please use "(void)" for an empty parameter list, not "()". I think it would be a really bad idea to warn each time sysconf(_SC_PAGESIZE) might fail. Also, I'd prefer not having two indirections here, so please cache the result in a function-internal static variable, so that we don't have to call sysconf() all the time. Use __tls on the variable, since clients might end up using threads and I'd prefer if we never have to think much about thread-safety of these calls if they cache stuff in static variables. Otherwise looks fine! Thanks, Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Improve boot-time of systemd
On Fri, Mar 18, 2011 at 14:40, Gustavo Sverzut Barbieri wrote: > On Fri, Mar 18, 2011 at 10:52 AM, Andrey Borzenkov wrote: >> On Fri, Mar 18, 2011 at 12:35 PM, fykc...@gmail.com >> wrote: >>> 1. What can readahead affect boot-time? >>> Sadly observed negative affect -- boot-time increases at least 1s. >> >> From subjective feelings (no real measurements) I confirm it. > > I noticed it as well, even with my Macbook Pro i7 with 8Gb RAM and > 128SSD using btrfs. It's ~0.5 sec faster here with readahead on a SSD. > But it could be improved yes. As you all said, maybe we should handle > udev hotplug in a more throttled way by postponing non-critical > devices and having everything else to be hotplug aware? That's not really possible, you can not really make such list, and you need to handle all parent devices from all 'interesting' devices anyway to expose them. The 'settle' service is only there for broken services. Originally it wasn't even pulled into the base target but was free-hanging with nobody getting blocked by it. Lennart pulled it in for a few broken things and selinux to work, and it ended up blocking the base target to be on the safe side for non-hotplug aware stuff. We might want to re-check if that's really what we want. Ideally, the entire 'settle' step would not even exist. I guess in your limited environments, you can just drop the entire thing and let the coldplug task run in the background. Services need to cope with uninitialized devices then, and filter them out when enumerating subsystems, and wait for the proper event from udev. That should all be pretty straight-forward if you don't need to support all the insanity in usual Linux distros. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Improve boot-time of systemd
On Fri, Mar 18, 2011 at 10:52 AM, Andrey Borzenkov wrote: > On Fri, Mar 18, 2011 at 12:35 PM, fykc...@gmail.com wrote: >> Hi all, >> >> We did a series boot-time tests of systemd, and found some interesting >> things: >> (Note the tests were performed on a laptop with a 4-core mips cpu, AMD >> RS780 chipset, 2GB Memory, rotate harddisk with ext4 filesystem, >> debian squeeze, Linux 2.6.36 with fanotify enabled, systemd-v20, only >> boot to console.) >> >> 1. What can readahead affect boot-time? >> Sadly observed negative affect -- boot-time increases at least 1s. > > From subjective feelings (no real measurements) I confirm it. I noticed it as well, even with my Macbook Pro i7 with 8Gb RAM and 128SSD using btrfs. >> With bootchart, I find more I/O at boot compared with no readahead, >> see attachment noreadahead-vs-readahead.png. >> Thoughts: Maybe we need only monitor files with read access, not all >> opend files? P.S. inotify seems enough for the job (with one more step >> to open each file). >> >> 2. udev-settle.service serializes the boot process, see attachment >> udev-settle.png. > > I have feeling that increased parallelism during boot (like starting > fsck/mount as soon as device becomes available) actually has negative > effect on consumer grade devices. My HDD in notebook simply is not > prepared for it ... ACK. Maybe we should add some intelligence to systemd's automatic unit-mount creation and serialize partition mounts of the same device? For traditional systems it's easy, just make all /dev/sda* depend on each other, but world is bit harder and multiple-device FS like btrfs or even DM will screw with that. Ideas? Maybe we could do it just based on /etc/fstab, sorting dependencies based on /dev/sda* and respective mountpoints. >> I tried to create a hotplug.target(which is activated after >> default.target), and made udev-settle reside at it, this rendered a >> unbootable system. systemd depends on udev at early time. >> Thoughts: devtmpfs is mounted, so all cold-plug jobs can be done >> without udev involved. >> IMHO, fast boot doesn't mean get all services ready in a short time, >> but means popup an UI as soon as possible. Windows seems do hotplug >> jobs after user log in. >> > > Mandriva uses so called "speedboot" with sysvint - where GUI is > started as soon as possible. It is handcrafted so that only several > device classes are coldplugged and then DM is launched effectively > from rc.sysinit already. > > Users did mention that boot under systemd actually feels slower then > using sysvinit. Well, I never tried other distro other than Gentoo on this Macbook and here it's kinda fast at 7s to be 100% ready with E17 (I have an autostart .desktop that writes to /dev/kmsg to measure it), "Startup finished in 2s 360ms 651us (kernel) + 1s 753ms 783us (userspace) = 4s 114ms 434us." But it could be improved yes. As you all said, maybe we should handle udev hotplug in a more throttled way by postponing non-critical devices and having everything else to be hotplug aware? AFAIK Xorg will handle nicely new input devices. ConnMan/NetworkManager will handle nicely network devices. Same for bluez. We could even just activate these services based on the presence of the devices, at least E17 will handle nicely daemons appearing later by means of DBus NameOwnerChanged. Ideas: 1. should we change ConnMan and NetworkManager to work as BlueZ an be able to be activated/shutdown by udev hotplug actions (but cooperative with systemd, bluetoothd is not AFAIR); 2. should we do (or have a way to) force a manual ordering to help Xorg/DM/WM by avoiding spawn of concurrent services? We know these have the higher priority, but it's a higher priority only during startup, later on they should all have the same priority... otherwise we could just do it by means of systemd's service settings. A hackish(?) solution would be to have a BootPriority=(True|False), set to False by default and True for services we care most. Lower priority services would be set to "background" priority in IO, CPU and others, then being reset to actual values when systemd is notified. Problem is we need to notify Systemd of that, as it's not a matter of just starting "gdm", but actually gdm being in a "usable" state (defined by gdm itself) or desktop being ready if users use autologin (like I do). This could also be stated as "system is idle for X seconds", which would be monitored by systemd itself and then no manual notification is required. As a last note, what piss me off is the fact that some things affect boot time but they should not, and it's not systemd's fault. For instance with both nvidia and intel on another PC I have around 1s slowdown when I'm using external monitors! Damn, 14% of my boot time because of that? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___
Re: [systemd-devel] systemd-logger and external syslog daemon
On Fri, Mar 18, 2011 at 14:30, Rainer Gerhards wrote: > On 03/18/2011 01:53 PM, Kay Sievers wrote: >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9d90c8d9cde929cbc575098e825d7c29d9f45054 > > That's what I understood and what I based my proposal on. In that case, > rsyslog can simply check if there is an additional priority. I just did some > quick PoC: > > http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=bb67fd7fbf99ce0ec01b347fad5d1d9d101bfa5d > > Looks like it works pretty well. So systemd could simply always write the > full priority and the syslogd would just need to check for the extra header. > If the syslogd is not capable of doing that, the message will look a bit > strange. But in that case, the priority is wrong in any case, and so chances > it will be properly routed are slim... Sounds all good to me. Thanks a lot for your help and cooperation, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-logger and external syslog daemon
On 03/18/2011 01:53 PM, Kay Sievers wrote: On Fri, Mar 18, 2011 at 08:19, Rainer Gerhards wrote: -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Thursday, March 17, 2011 10:38 PM To: Rainer Gerhards Cc: Michael Biebl; Andrey Borzenkov; systemd- de...@lists.freedesktop.org Subject: Re: [systemd-devel] systemd-logger and external syslog daemon On Thu, 17.03.11 08:38, Rainer Gerhards (rgerha...@hq.adiscon.com) wrote: You mean a new udev/dracut/systemd on an old kernel? The messages they print would look a bit weird if they are used together with log msg timestamping the way the kernel does it, since the kernel doesn't recognize the prefix. (See Kay's post about this). But besides these cosmetic issues nothing should really go wrong. (I wonder if we can find a nice way to detect whether the kernel is new enough for this, so that we could strip the facility automatically for older ones. Explcitily checking for kernel versions at runtime is evil though... I can't think of a good way though...) Wouldn't it work to check if there is a "" right at the start of the message? I think that it is actual user data would be extremely improbable, so this should be a good enough indication. That way, we could pull the PRI even without the kernel patch (but, granted, it is kind of an interface change...). Hmm? The question is how we can detect whether it is safe to write messages to kmsg with PRI values with more than 3 bits. 2.6.39 and above will be able to handle that properly, even if you enable per-line printk kernel timestamping. On 2.6.38 only 3-bit-PRI values will look good if you use printk kernel timestamping. Probably I misunderstood the answer to "what happens on a kernel without that patch if a full PRI is written?". I understood the answer was "the PRI is moved into the message". So "<123>msg" would actually become "<1> [TS]<123>Msg" From your answer I deduce this understanding is incorrect. So what will then happen on kernels without that patch if printk is provided a message "<123>MSg"? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9d90c8d9cde929cbc575098e825d7c29d9f45054 That's what I understood and what I based my proposal on. In that case, rsyslog can simply check if there is an additional priority. I just did some quick PoC: http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=bb67fd7fbf99ce0ec01b347fad5d1d9d101bfa5d Looks like it works pretty well. So systemd could simply always write the full priority and the syslogd would just need to check for the extra header. If the syslogd is not capable of doing that, the message will look a bit strange. But in that case, the priority is wrong in any case, and so chances it will be properly routed are slim... Rainer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-logger and external syslog daemon
On Fri, Mar 18, 2011 at 08:19, Rainer Gerhards wrote: >> -Original Message- >> From: Lennart Poettering [mailto:lenn...@poettering.net] >> Sent: Thursday, March 17, 2011 10:38 PM >> To: Rainer Gerhards >> Cc: Michael Biebl; Andrey Borzenkov; systemd- >> de...@lists.freedesktop.org >> Subject: Re: [systemd-devel] systemd-logger and external syslog daemon >> >> On Thu, 17.03.11 08:38, Rainer Gerhards (rgerha...@hq.adiscon.com) >> wrote: >> >> > > You mean a new udev/dracut/systemd on an old kernel? The messages >> they >> > > print would look a bit weird if they are used together with log msg >> > > timestamping the way the kernel does it, since the kernel doesn't >> > > recognize the prefix. (See Kay's post about this). But besides >> these >> > > cosmetic issues nothing should really go wrong. >> > > >> > > (I wonder if we can find a nice way to detect whether the kernel is >> new >> > > enough for this, so that we could strip the facility automatically >> for >> > > older ones. Explcitily checking for kernel versions at runtime is >> evil >> > > though... I can't think of a good way though...) >> > >> > Wouldn't it work to check if there is a "" right at the start of >> the >> > message? I think that it is actual user data would be extremely >> improbable, >> > so this should be a good enough indication. That way, we could pull >> the PRI >> > even without the kernel patch (but, granted, it is kind of an >> interface >> > change...). >> >> Hmm? >> >> The question is how we can detect whether it is safe to write messages >> to kmsg with PRI values with more than 3 bits. 2.6.39 and above will be >> able >> to handle that properly, even if you enable per-line printk kernel >> timestamping. On 2.6.38 only 3-bit-PRI values will look good if you use >> printk kernel timestamping. > > Probably I misunderstood the answer to "what happens on a kernel without that > patch if a full PRI is written?". I understood the answer was "the PRI is > moved into the message". > > So "<123>msg" > would actually become > "<1> [TS] <123>Msg" > > From your answer I deduce this understanding is incorrect. So what will then > happen on kernels without that patch if printk is provided a message > "<123>MSg"? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9d90c8d9cde929cbc575098e825d7c29d9f45054 Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Fri, 18 Mar 2011 14:11:47 +0300 Andrey Borzenkov wrote: > On Fri, Mar 18, 2011 at 8:31 AM, Mike Kazantsev wrote: > > > > That'd make all the systems with currently enabled services in > > network.target.wants misconfigured - network should fail on these > > unless something Requires= (or Wants=) network.target explicitly (which > > was marked as a wrong way to depend on network), so I think maybe some > > larger announcement for packagers is in order as well, to leave less > > broken systems and angry users as a result ;) > > > > I am not sure I really understand this. When you speak about services > WantedBy network.target - do you mean services activated on-demand > when network becomes available. No, these are services that make the network work. They are pulled in for network.target, so any service starting after that will be able to bind to some interface or connect to a remote host. > Could you give example? Sure, I have this mix (for two machines): rpcbind.service rpcidmapd.service rpcstatd.service wicd.service ypbind-mt.service epmd.service ipsec.service net@core.service net-firewall.service net@he6.service net-lo.service net@tnet.service net@xtit.service net@.service is just a template to start static network configuration script, other net-* stuff follows the same purpose, the rest are more or less what comes with the distro. I'm fairly sure that common units for other stuff like connman, wpa_supplicant or dhcpcd will also be in this category. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Fri, Mar 18, 2011 at 8:31 AM, Mike Kazantsev wrote: > On Fri, 18 Mar 2011 00:34:19 +0100 > Lennart Poettering wrote: > >> >> But what about the other direction? We definitely want network.target in >> the boot transaction if NM or network.service is part of it too. Because >> only then the network consuming services can be synchronized >> properly. Hence we want those two services pull in network.target, as a >> signal "Hey, we implement this, and when it is up, you can use it". >> >> So, here's what I am going to do now: >> >> a) Modify the Description= strings of the various target units where >> this applies to make clear that they exist for SysV/LSB compat only. >> >> b) Remove dbus.target >> >> c) Add a Wants+Before to syslog.socket on syslog.target. Since the >> socket is already enough to make logging possible this is all that is >> needed. >> >> d) fix the systemd code which parses LSB headers to interpret Provides >> like this. >> >> e) patch NM upstream and NTP in F15 to add the necessary dependencies. >> >> And Andrey, thanks a lot for pointing us to this problem and the >> solution! >> >> Questions? Anything we didn't think about? >> > > That'd make all the systems with currently enabled services in > network.target.wants misconfigured - network should fail on these > unless something Requires= (or Wants=) network.target explicitly (which > was marked as a wrong way to depend on network), so I think maybe some > larger announcement for packagers is in order as well, to leave less > broken systems and angry users as a result ;) > I am not sure I really understand this. When you speak about services WantedBy network.target - do you mean services activated on-demand when network becomes available. Could you give example? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Improve boot-time of systemd
On Fri, Mar 18, 2011 at 12:35 PM, fykc...@gmail.com wrote: > Hi all, > > We did a series boot-time tests of systemd, and found some interesting things: > (Note the tests were performed on a laptop with a 4-core mips cpu, AMD > RS780 chipset, 2GB Memory, rotate harddisk with ext4 filesystem, > debian squeeze, Linux 2.6.36 with fanotify enabled, systemd-v20, only > boot to console.) > > 1. What can readahead affect boot-time? > Sadly observed negative affect -- boot-time increases at least 1s. >From subjective feelings (no real measurements) I confirm it. > With bootchart, I find more I/O at boot compared with no readahead, > see attachment noreadahead-vs-readahead.png. > Thoughts: Maybe we need only monitor files with read access, not all > opend files? P.S. inotify seems enough for the job (with one more step > to open each file). > > 2. udev-settle.service serializes the boot process, see attachment > udev-settle.png. I have feeling that increased parallelism during boot (like starting fsck/mount as soon as device becomes available) actually has negative effect on consumer grade devices. My HDD in notebook simply is not prepared for it ... > I tried to create a hotplug.target(which is activated after > default.target), and made udev-settle reside at it, this rendered a > unbootable system. systemd depends on udev at early time. > Thoughts: devtmpfs is mounted, so all cold-plug jobs can be done > without udev involved. > IMHO, fast boot doesn't mean get all services ready in a short time, > but means popup an UI as soon as possible. Windows seems do hotplug > jobs after user log in. > Mandriva uses so called "speedboot" with sysvint - where GUI is started as soon as possible. It is handcrafted so that only several device classes are coldplugged and then DM is launched effectively from rc.sysinit already. Users did mention that boot under systemd actually feels slower then using sysvinit. > BTW, bootchart seems not very intuitive(no service, only processes. > Also some processes may be missed if they live between two "ps aux" > call of bootchart), is it possible to add similar feature to systemd? > > > > -- > Regards, > - cee1 > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] rsyslog drops messages in debug mode
On Fri, Mar 18, 2011 at 11:44 AM, Michal Schmidt wrote: > On Fri, 18 Mar 2011 07:42:34 +0100 Michael Biebl wrote: >> > On Fri, 18 Mar 2011 07:03:01 +0100 >> > Michael Biebl wrote: >> > >> >> when booting with systemd.log_level=debug, I get > [...] >> My point rather is, that for a default rsyslog + systemd installation >> imho this should not happen. > > When you add log_level=debug, you cannot call it the default > installation anymore. > If you lose messages with log_level=debug, then log_leevl=debug makes little sense in the first place. How should I work on bug reports if users are not able to provide sufficient debug information? We try by all means to not lose a single message on systemd side just to drop them in the end. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] rsyslog drops messages in debug mode
On Fri, 18 Mar 2011 07:42:34 +0100 Michael Biebl wrote: > > On Fri, 18 Mar 2011 07:03:01 +0100 > > Michael Biebl wrote: > > > >> when booting with systemd.log_level=debug, I get [...] > My point rather is, that for a default rsyslog + systemd installation > imho this should not happen. When you add log_level=debug, you cannot call it the default installation anymore. Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-logger and external syslog daemon
> -Original Message- > From: Lennart Poettering [mailto:lenn...@poettering.net] > Sent: Thursday, March 17, 2011 10:38 PM > To: Rainer Gerhards > Cc: Michael Biebl; Andrey Borzenkov; systemd- > de...@lists.freedesktop.org > Subject: Re: [systemd-devel] systemd-logger and external syslog daemon > > On Thu, 17.03.11 08:38, Rainer Gerhards (rgerha...@hq.adiscon.com) > wrote: > > > > You mean a new udev/dracut/systemd on an old kernel? The messages > they > > > print would look a bit weird if they are used together with log msg > > > timestamping the way the kernel does it, since the kernel doesn't > > > recognize the prefix. (See Kay's post about this). But besides > these > > > cosmetic issues nothing should really go wrong. > > > > > > (I wonder if we can find a nice way to detect whether the kernel is > new > > > enough for this, so that we could strip the facility automatically > for > > > older ones. Explcitily checking for kernel versions at runtime is > evil > > > though... I can't think of a good way though...) > > > > Wouldn't it work to check if there is a "" right at the start of > the > > message? I think that it is actual user data would be extremely > improbable, > > so this should be a good enough indication. That way, we could pull > the PRI > > even without the kernel patch (but, granted, it is kind of an > interface > > change...). > > Hmm? > > The question is how we can detect whether it is safe to write messages > to kmsg with PRI values with more than 3 bits. 2.6.39 and above will be > able > to handle that properly, even if you enable per-line printk kernel > timestamping. On 2.6.38 only 3-bit-PRI values will look good if you use > printk kernel timestamping. Probably I misunderstood the answer to "what happens on a kernel without that patch if a full PRI is written?". I understood the answer was "the PRI is moved into the message". So "<123>msg" would actually become "<1> [TS] <123>Msg" >From your answer I deduce this understanding is incorrect. So what will then happen on kernels without that patch if printk is provided a message "<123>MSg"? Rainer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
