On 7/17/20 12:06 PM, Greg Kroah-Hartman wrote:
> On Tue, Jul 14, 2020 at 10:50:39AM +0200, Bartlomiej Zolnierkiewicz wrote:
>>
>> On 7/14/20 10:17 AM, Greg Kroah-Hartman wrote:
>>> On Tue, Jul 14, 2020 at 10:06:05AM +0200, Bartlomiej Zolnierkiewicz wrote:
>>>>
>>>> Hi Tony,
>>>>
>>>> On 7/9/20 11:18 PM, Tony Asleson wrote:
>>>>> Hi Bartlomiej,
>>>>>
>>>>> On 6/24/20 5:35 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>>> The root source of problem is that libata transport uses different
>>>>>> naming scheme for ->tdev devices (please see dev_set_name() in
>>>>>> ata_t{dev,link,port}_add()) than libata core for its logging
>>>>>> functionality (ata_{dev,link,port}_printk()).
>>>>>>
>>>>>> Since libata transport is part of sysfs ABI we should be careful
>>>>>> to not break it so one idea for solving the issue is to convert
>>>>>> ata_t{dev,link,port}_add() to use libata logging naming scheme and
>>>>>> at the same time add sysfs symlinks for the old libata transport
>>>>>> naming scheme.
>>>
>>> Given the age of the current implementation, what suddenly broke that
>>> requires this to change at this point in time?
>>
>> Unfortunately when adding libata transport classes (+ at the same
>> time embedding struct device-s in libata dev/link/port objects) in
>> the past someone has decided to use different naming scheme than
>> the one used for standard libata log messages (which use printk()
>> without any reference to struct device-s in libata dev/link/port
>> objects).
>>
>> Now we would like to use dev_printk() for standard libata logging
>> functionality as this is required for 2 pending patchsets:
>>
>> - move DPRINTK to dynamic debugging (from Hannes Reinecke)
>>
>> - add persistent durable identifier storage log messages (from Tony)
>>
>> but we don't want to change standard libata log messages and
>> confuse users..
>
> All of that mess with symlinks just for a common debug printk? That
> seems excessive :)
Unfortunately "a common debug printk" means all log messages generated
by libata core..
> Just use the device name and don't worry about it, I doubt anyone will
> notice, unless the name is _really_ different.
Well, Geert has noticed and complained pretty quickly:
https://lore.kernel.org/linux-ide/alpine.DEB.2.21.2003241414490.21582@xxxxxxxxxxxxxx/
Anyway, I don't insist that hard on keeping the old names and
I won't be the one handling potential bug-reports.. (added Jens to Cc:).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
