'Twas brillig, and Lennart Poettering at 02/07/12 09:48 did gyre and gimble:
> On Mon, 02.07.12 09:15, Colin Guthrie ([email protected]) wrote:
>
>> On some really old hardware, the default timeout of 120 (which may even
>> be reduced further on the command line) is insufficient.
>>
>> While such cases are specialist and (nowadays) relatively rare, it is
>> still nice to be able to provide a method to increase the timeout
>> when needed.
>
> Hmpf, the idea of settling things is borked, and just increasing the
> timeout doesn't really fix that...
>From an "in principle" point of view I can't disagree... from an "in
practice" PoV, it does fix real problems people have had.
> But anyway:
>
>> + /*
>> + * read the kernel commandline, in case we need to tweak timeout
>> + * udev.settle-timeout=<timeout> settle timeout
>> + *
>> + */
>> + f = fopen("/proc/cmdline", "r");
>> + if (f != NULL) {
>> + char cmdline[4096];
>> +
>> + if (fgets(cmdline, sizeof(cmdline), f) != NULL) {
>> + char *pos;
>> +
>> + pos = strstr(cmdline, "udev.settle-timeout=");
>> + if (pos != NULL) {
>> + pos += strlen("udev.settle-timeout=");
>> + timeout = strtoul(pos, NULL, 0);
>> + log_debug("timeout=%i (via kernel
>> cmdline)\n", timeout);
>> + }
>> + }
>> + fclose(f);
>> + }
>
> Could you please use read_one_line_file() instead? Could you also please
> use FOREACH_WORD to iterate through it, so that word boundaries are
> respected? Also, please use safe_atou() to parse the integer? it gets
> the error handling right, which is relly hard to with naked strtoul().
Weird, I thought I was looking at the same code in src/udev/udevd.c when
I rebased the patch to pick up on any "newisms", but clearly I had the
wrong tree selected (185?) when I did that. Fudge. Will redo and repost.
Col
--
Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
