possible bug in mdev (r21557)

[Daniel Mierswa]

On 26.05.2008 22:01, Denys Vlasenko:
> On Monday 26 May 2008 16:34, Daniel Mierswa wrote:
>   
>> On 26.05.2008 14:45, Denys Vlasenko:
>>     
>>> Yes. Please find out what path is passed by kernel to mdev for your device.
>>> Replace mdev.c with the attached file. It has the following
>>> debug printout added:
>>>
>>> static void make_device(char *path, int delete)
>>> {
>>> ...
>>>         /* Determine device name, type, major and minor */
>>>         device_name = bb_basename(path);
>>> bb_error_msg("PATH '%s' DEVICE NAME '%s'", path, device_name);
>>>
>>> Rebuild busybox, run the boot process and let the mailing list
>>> know what you see.
>>>       
>
>   
>> /sys/class/usb_endpoint/usbdev\d.\d_ep\d\d
>>     
>
> I'm sorry, but where are "PATH" and "DEVICE" strings?
> bb_error_msg contains them, so they ought to be visible.
>
> If you want bug to be fixed, you have to spend a bit of your time
> writing your responses so that they have a high chance of being
> understood by the recipient. Your first post was good (you spent
> considerable time tracking bug down), but this one is not.
>
> For one, 5th char in this path is 'c', and therefore 1.8.3
> would create a char device too:
>
>         type = path[5]=='c' ? S_IFCHR : S_IFBLK;
>
> It means that you are probably showing wrong path. It's not
> the path which causes the problem.
> --
> vda
>   
I'm sorry that I didn't recognize it was necessary, since the device was 
everything behind the last slash. It gets created with

mdev: PATH '/sys/class/usb_endpoint/usbdev1.1_ep00' DEVICE NAME 
'usbdev1.1_ep00'

Those are both created during mdev -s. The ls -l of both files (the 
working and the failing version are exactly the same, as you've just 
said, they're both character devices)

crw-rw----   1 0      0     254,    0 usbdev1.1_ep00

As said, this is the output directly after mdev -s.
I'm not even sure if that's the right place to debug that.
I'm starting a blkid loop which does blkid -o device -lt UUID=myuuid 
every second and stops once it returns 0.
The kernel printk rolls down probably 10 seconds after the /init 
execution (the one with the information sde: sde1 sde2 and so on). But 
the mdev debugging line you gave me doesn't show up anymore. The first 
version (21556) just sits there waiting after the printk and the second 
version (21557) lets blkid return 0 and continue. However the mdev line 
doesn't occur after mdev -s anymore. Any chance that I'm debugging this 
at the wrong place? Thanks for your time so far.

-- 
Mierswa, Daniel

If you still don't like it, that's ok: that's why I'm boss. I simply know better than you do.
               --- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22