Re: [PATCH] udevd: fix WAIT_FOR_SYSFS

[Alan Jenkins <alan-jenkins@tuffmail.co.uk>]

Alan Jenkins wrote:
> Kay Sievers wrote:
>   
>> On Thu, Oct 23, 2008 at 21:56, Alan Jenkins <alan-jenkins@tuffmail.co.uk> wrote:
>>   
>>     
>>> Kay Sievers wrote:
>>>     
>>>       
>>>> On Thu, Oct 23, 2008 at 21:03, Kay Sievers <kay.sievers@vrfy.org> wrote:
>>>>       
>>>>         
>>>>> On Thu, Oct 23, 2008 at 20:37, Alan Jenkins <alan-jenkins@tuffmail.co.uk> wrote:
>>>>>
>>>>>         
>>>>>           
>>>>>> The wait should be ordered after matching KERNEL, ENV, etc.
>>>>>> but before ATTR.
>>>>>>
>>>>>> Without this, WAIT_FOR_SYSFS rules will be applied unconditionally
>>>>>> to all events.
>>>>>>
>>>>>>           
>>>>>>             
>>>>> Ah, nice! Thanks for finding that out. I do not have any of theses
>>>>> rules left, as there are currently no know issues with recent kernels.
>>>>> :) Applied.
>>>>>         
>>>>>           
>>>> Oh, now that I expect it works for you without the long delay. :) How
>>>> does is compare? Is it still slower?
>>>>       
>>>>         
>>   
>>     
>>> No, that fixed it.  The network interface rename problem seems to have
>>> gone as well (!).
>>>
>>> I just tested it on my desktop.  oprofile says it now _reduces_ cpu
>>> cycles in udevd by 10%.  Not big enough to show up in time(1), but not
>>> bad!  And it should help more on the EeePC, which has a less lavish cpu
>>> cache.
>>>     
>>>       
>> Sounds good. I've changed a few other things, which might make things faster:
>>
>> We cache the results of getpwnam/getgrnam() during rules parse time,
>> some of the rules files I have here have ~700 rules with GROUP="..."
>> keys ...
>>
>> We check at parse time, if we need to call fnmatch() for a key, or can
>> just go with the much cheaper strcmp(). That seems to make a real
>> difference with the large rules files I have.
>>   
>>     
>
> Nice.
>
>   
>> Also the snprintf() that was used compose the buffer to pass the event
>> to a socket was _very_ expensive. We just use strlcpy() now and cache
>> the result for the next RUN+="socket:" call.
>>   
>>     
>
> I might adapt that for udev-exec.
>
> But I think it needs a flag like envp_uptodate, no?
>   

And for bonus points...

udev_device_get_properties_envp() could return pointers into this
buffer, instead of allocating individual strings on the heap.

Alan