lkml.org 
[lkml]   [2022]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] printk: console: Allow each console to have its own loglevel
Greg Kroah-Hartman writes:
>> If you're talking about properly freeing the memory, I suppose it should
>> happen by doing something like the following in unregister_console():
>>
>> if (!console_drivers)
>> /* free the class object under console lock */
>>
>> ...right? Let me know if I'm misunderstanding you.
>
>You can't do that as the driver core should now be managing the
>lifespace of that object. You can't "know" when the object's memory is
>to be freed EXCEPT in the release function.
>
>So free it there please.
>
>Or do not tie the lifepan of the console class device object to the
>console object, and keep it separate. I don't remember exactly how you
>tied them together here, sorry.

[...]

>> > Do you ever free the class?
>>
>> Currently no. What do you think about the above proposal to do it once the
>> console driver list is exhausted?
>
>If the code can never be unloaded, no, don't worry about it.

So just so I understand, there's no problem here if we're not going to free the
class object, correct? These two stanzas in your reply refer to the same thing,
right?

For context: the class comes up with printk, and printk can never be unloaded,
so the class is never freed.

The devices that attach to this class are stored in `struct console', which has
its lifecycle managed externally from this code.

I feel like I'm missing something here, but the two quoted parts of your reply
seem to contradict each other (the first one talks about the right place to
free the class, whereas the second says it's not necessary to free the class),
so I'm a bit confused.

\
 
 \ /
  Last update: 2022-05-18 22:30    [W:0.116 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site