Re: TODO file

[Okash Khawaja <okash.khawaja@gmail.com>]

On Thu, 14 Mar 2019 13:24:47 +0100
Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:

> Okash Khawaja, le jeu. 14 mars 2019 11:07:26 +0000, a ecrit:
> > I can't find any reference to in_atomic() in speakup code.
> > According to "Atomic context and kernel API design" [1] lwn
> > article, in_atomic() started being phased out of general kernel
> > code around 2.6.26. I guess this commit removed remaining
> > references to in_atomic: d7500135802c "Staging: speakup: Move
> > pasting into a work item". Is there any more work to be done for
> > this?  
> 
> It seems there is no more indeed.
> 
> > Also can someone give a bit of a background or pointers regarding
> > moving kobjects:
> > 
> > "The kobjects may have to move to a more proper place in /sys. The
> > discussion on lkml resulted to putting speech synthesizers in the
> > "speech" class, and the speakup screen reader itself into
> > /sys/class/vtconsole/vtcon0/speakup, the nasty path being handled by
> > userland tools."  
> 
> I don't remember the discussion. I'm not sure what is best. Moving
> synthesizers to a speech class and the screen reader to vtconsole
> makes sense technically, less so in terms of users (and the userland
> tools then have to adapt to the new path). I'd say try to find the
> discussions where the location was discussed, to check whether this
> is really wanted by kernel developers, otherwise I'd stay leave it
> where it is and focus on items which are more useful.
> 
> Actually, perhaps the only item that remains for getting out of
> staging/ is the selection duplication. Perhaps it is time to check
> with Greg what he sees needs to be done. Perhaps only codestyle
> remains at this point? (getting out of staging is an important goal,
> both for settling the driver, but also for getting included in
> distributions which build only mainline drivers)

That sounds good. I'll start a thread with Greg and see where we go.

Thanks very much.

Okash