Re: Does braille console work?

[Samuel Thibault]

Hello,

Steven Rostedt, on ven. 17 mars 2017 09:02:08 -0400, wrote:
> Samuel Thibault  wrote:
> > Petr Mladek, on ven. 17 mars 2017 10:35:44 +0100, wrote:
> > > Anyway, the feature is not usable at the moment. Samuel, would
> > > you be able to fix and test it, please?  
> > 
> > Sure, it's already on my TODO list, I will do when I get the time.
> 
> Yes please.

Done so.

> There's no reason to keep that code if it's been broken for
> 3 years and nobody noticed.

It's rather that nobody complained. That's what usually happens with
accessibility: when something breaks, the concerned users do notice, but
end up just thinking "ok, yet another regression..."

> In fact, keeping it may actually make it
> more difficult to add accessibility in the future. Methodologies may
> change and the old broken code (that we've been complicating all other
> code with), may actually become a hindrance to a new methodology.

Why so?  I would say the contrary: the existing code shows the actual
needs and how they can be implemented.  That's the usual "show me actual
code" question answered.

> Getting rid of the complications it adds to the core code, and let the
> core code become more simplified may actually end up being easier to
> add accessibility in the future, than keeping the old cruft around.

No, because it means it'll get hard to get something implemented again,
because actual implementation will have been dropped.

Samuel

Re: Does braille console work?

[Samuel Thibault]

Hello,

Steven Rostedt, on ven. 17 mars 2017 09:02:08 -0400, wrote:
> Samuel Thibault  wrote:
> > Petr Mladek, on ven. 17 mars 2017 10:35:44 +0100, wrote:
> > > Anyway, the feature is not usable at the moment. Samuel, would
> > > you be able to fix and test it, please?  
> > 
> > Sure, it's already on my TODO list, I will do when I get the time.
> 
> Yes please.

Done so.

> There's no reason to keep that code if it's been broken for
> 3 years and nobody noticed.

It's rather that nobody complained. That's what usually happens with
accessibility: when something breaks, the concerned users do notice, but
end up just thinking "ok, yet another regression..."

> In fact, keeping it may actually make it
> more difficult to add accessibility in the future. Methodologies may
> change and the old broken code (that we've been complicating all other
> code with), may actually become a hindrance to a new methodology.

Why so?  I would say the contrary: the existing code shows the actual
needs and how they can be implemented.  That's the usual "show me actual
code" question answered.

> Getting rid of the complications it adds to the core code, and let the
> core code become more simplified may actually end up being easier to
> add accessibility in the future, than keeping the old cruft around.

No, because it means it'll get hard to get something implemented again,
because actual implementation will have been dropped.

Samuel

Re: Does braille console work?

[Steven Rostedt]

On Fri, 17 Mar 2017 10:40:51 +0100
Samuel Thibault  wrote:

> Petr Mladek, on ven. 17 mars 2017 10:35:44 +0100, wrote:
> > Anyway, the feature is not usable at the moment. Samuel, would
> > you be able to fix and test it, please?  
> 
> Sure, it's already on my TODO list, I will do when I get the time.
>

Yes please. There's no reason to keep that code if it's been broken for
3 years and nobody noticed. In fact, keeping it may actually make it
more difficult to add accessibility in the future. Methodologies may
change and the old broken code (that we've been complicating all other
code with), may actually become a hindrance to a new methodology.
Either keep it updated, or get rid of it. Getting rid of the
complications it adds to the core code, and let the core code become
more simplified may actually end up being easier to add accessibility
in the future, than keeping the old cruft around.

-- Steve

Re: Does braille console work?

[Steven Rostedt]

On Fri, 17 Mar 2017 10:40:51 +0100
Samuel Thibault  wrote:

> Petr Mladek, on ven. 17 mars 2017 10:35:44 +0100, wrote:
> > Anyway, the feature is not usable at the moment. Samuel, would
> > you be able to fix and test it, please?  
> 
> Sure, it's already on my TODO list, I will do when I get the time.
>

Yes please. There's no reason to keep that code if it's been broken for
3 years and nobody noticed. In fact, keeping it may actually make it
more difficult to add accessibility in the future. Methodologies may
change and the old broken code (that we've been complicating all other
code with), may actually become a hindrance to a new methodology.
Either keep it updated, or get rid of it. Getting rid of the
complications it adds to the core code, and let the core code become
more simplified may actually end up being easier to add accessibility
in the future, than keeping the old cruft around.

-- Steve

Re: Does braille console work?

[Aleksey Makarov]

On 03/17/2017 03:53 AM, Samuel Thibault wrote:
> Hello,
> 
> Aleksey Makarov, on jeu. 16 mars 2017 17:02:53 +0300, wrote:
>> There can be 3 outcomes from this function:
>> 1) it returns NULL and does not set brl_options
>> 2) it returns NULL and set the variable pointed by str to NULL
>> 3) it returns non-NULL
> 
> Uh, that's odd indeed, the intent was that it'd return an error code
> only.
> 
>> To register a braille console (i. e. to call __add_preferred_console()
>> with non-NULL brl_options) function _braille_console_setup() should
>> return NULL and initialize brl_options. 
> 
> return 0 (as in no error), actually, in the intent.
> 
>> 1) in this case brl_options is NULL and non-braille console is registered
>> 2) kernel produces oops later in console_setup().  I reproduced it
>>passing "console=brl=aaa" parameter to kernel, see below.
>> 3) no console is registered
>>
>> So braille console registration should not work.  What do I miss?
> 
> Nothing, the code transformation was broken :/

So the kernel contains seemingly unmaintained code that does not work
for at least 3 years.  Its parts in printk.c considerably complicate
code support.

>> So it looks like braille console has not been used for more than 3 years.
>> Should we remote it?
> 
> Please, no :)
> 
> It is indeed not often useful, since one would usually use a userland
> daemon to access the system, but when one's system does not boot
> properly or something similar, it's useful to have the braille
> console. That's just very not often useful.

Why should we keep the code which does not work?  And which is used
more than 3 years ago and usage requires patching.
I think removing it is a good idea

Thank you
Aleksey Makarov

> Samuel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Does braille console work?

[Aleksey Makarov]

On 03/17/2017 03:53 AM, Samuel Thibault wrote:
> Hello,
> 
> Aleksey Makarov, on jeu. 16 mars 2017 17:02:53 +0300, wrote:
>> There can be 3 outcomes from this function:
>> 1) it returns NULL and does not set brl_options
>> 2) it returns NULL and set the variable pointed by str to NULL
>> 3) it returns non-NULL
> 
> Uh, that's odd indeed, the intent was that it'd return an error code
> only.
> 
>> To register a braille console (i. e. to call __add_preferred_console()
>> with non-NULL brl_options) function _braille_console_setup() should
>> return NULL and initialize brl_options. 
> 
> return 0 (as in no error), actually, in the intent.
> 
>> 1) in this case brl_options is NULL and non-braille console is registered
>> 2) kernel produces oops later in console_setup().  I reproduced it
>>passing "console=brl=aaa" parameter to kernel, see below.
>> 3) no console is registered
>>
>> So braille console registration should not work.  What do I miss?
> 
> Nothing, the code transformation was broken :/

So the kernel contains seemingly unmaintained code that does not work
for at least 3 years.  Its parts in printk.c considerably complicate
code support.

>> So it looks like braille console has not been used for more than 3 years.
>> Should we remote it?
> 
> Please, no :)
> 
> It is indeed not often useful, since one would usually use a userland
> daemon to access the system, but when one's system does not boot
> properly or something similar, it's useful to have the braille
> console. That's just very not often useful.

Why should we keep the code which does not work?  And which is used
more than 3 years ago and usage requires patching.
I think removing it is a good idea

Thank you
Aleksey Makarov

> Samuel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Does braille console work?

[Samuel Thibault]

Petr Mladek, on ven. 17 mars 2017 10:35:44 +0100, wrote:
> Anyway, the feature is not usable at the moment. Samuel, would
> you be able to fix and test it, please?

Sure, it's already on my TODO list, I will do when I get the time.

Samuel

Re: Does braille console work?

[Samuel Thibault]

Petr Mladek, on ven. 17 mars 2017 10:35:44 +0100, wrote:
> Anyway, the feature is not usable at the moment. Samuel, would
> you be able to fix and test it, please?

Sure, it's already on my TODO list, I will do when I get the time.

Samuel

Re: Does braille console work?

[Petr Mladek]

Hello,

On Fri 2017-03-17 01:53:55, Samuel Thibault wrote:
> Aleksey Makarov, on jeu. 16 mars 2017 17:02:53 +0300, wrote:
> > 
> > So braille console registration should not work.  What do I miss?
> 
> Nothing, the code transformation was broken :/

> > So it looks like braille console has not been used for more than 3 years.
> > Should we remote it?
> 
> Please, no :)
> 
> It is indeed not often useful, since one would usually use a userland
> daemon to access the system, but when one's system does not boot
> properly or something similar, it's useful to have the braille
> console. That's just very not often useful.

I see the points. I would personally prefer to keep it even though
it is not much used and it complicates some code paths. Well, I do
not feel in the position to decide about it.

Anyway, the feature is not usable at the moment. Samuel, would
you be able to fix and test it, please?

Best Regards,
Petr

Re: Does braille console work?

[Petr Mladek]

Hello,

On Fri 2017-03-17 01:53:55, Samuel Thibault wrote:
> Aleksey Makarov, on jeu. 16 mars 2017 17:02:53 +0300, wrote:
> > 
> > So braille console registration should not work.  What do I miss?
> 
> Nothing, the code transformation was broken :/

> > So it looks like braille console has not been used for more than 3 years.
> > Should we remote it?
> 
> Please, no :)
> 
> It is indeed not often useful, since one would usually use a userland
> daemon to access the system, but when one's system does not boot
> properly or something similar, it's useful to have the braille
> console. That's just very not often useful.

I see the points. I would personally prefer to keep it even though
it is not much used and it complicates some code paths. Well, I do
not feel in the position to decide about it.

Anyway, the feature is not usable at the moment. Samuel, would
you be able to fix and test it, please?

Best Regards,
Petr

Re: Does braille console work?

[Samuel Thibault]

Aleksey Makarov, on ven. 17 mars 2017 12:00:02 +0300, wrote:
> I think removing it is a good idea

Removing potential for accessibility is almost never a good idea.

Getting that code in was difficult because it required introducing
accessibility features in the rest of the core. Removing that code means
that some time later somebody will suggest removing those accessibility
feature, thus making the work of somebody who wants to add accessibility
support even harder, while it is already crazily hard.

Samuel

Re: Does braille console work?

[Samuel Thibault]

Aleksey Makarov, on ven. 17 mars 2017 12:00:02 +0300, wrote:
> I think removing it is a good idea

Removing potential for accessibility is almost never a good idea.

Getting that code in was difficult because it required introducing
accessibility features in the rest of the core. Removing that code means
that some time later somebody will suggest removing those accessibility
feature, thus making the work of somebody who wants to add accessibility
support even harder, while it is already crazily hard.

Samuel

Re: Does braille console work?

[Samuel Thibault]

Hello,

Aleksey Makarov, on jeu. 16 mars 2017 17:02:53 +0300, wrote:
> There can be 3 outcomes from this function:
> 1) it returns NULL and does not set brl_options
> 2) it returns NULL and set the variable pointed by str to NULL
> 3) it returns non-NULL

Uh, that's odd indeed, the intent was that it'd return an error code
only.

> To register a braille console (i. e. to call __add_preferred_console()
> with non-NULL brl_options) function _braille_console_setup() should
> return NULL and initialize brl_options. 

return 0 (as in no error), actually, in the intent.

> 1) in this case brl_options is NULL and non-braille console is registered
> 2) kernel produces oops later in console_setup().  I reproduced it
>passing "console=brl=aaa" parameter to kernel, see below.
> 3) no console is registered
> 
> So braille console registration should not work.  What do I miss?

Nothing, the code transformation was broken :/

> So it looks like braille console has not been used for more than 3 years.
> Should we remote it?

Please, no :)

It is indeed not often useful, since one would usually use a userland
daemon to access the system, but when one's system does not boot
properly or something similar, it's useful to have the braille
console. That's just very not often useful.

Samuel

Re: Does braille console work?

[Samuel Thibault]

Hello,

Aleksey Makarov, on jeu. 16 mars 2017 17:02:53 +0300, wrote:
> There can be 3 outcomes from this function:
> 1) it returns NULL and does not set brl_options
> 2) it returns NULL and set the variable pointed by str to NULL
> 3) it returns non-NULL

Uh, that's odd indeed, the intent was that it'd return an error code
only.

> To register a braille console (i. e. to call __add_preferred_console()
> with non-NULL brl_options) function _braille_console_setup() should
> return NULL and initialize brl_options. 

return 0 (as in no error), actually, in the intent.

> 1) in this case brl_options is NULL and non-braille console is registered
> 2) kernel produces oops later in console_setup().  I reproduced it
>passing "console=brl=aaa" parameter to kernel, see below.
> 3) no console is registered
> 
> So braille console registration should not work.  What do I miss?

Nothing, the code transformation was broken :/

> So it looks like braille console has not been used for more than 3 years.
> Should we remote it?

Please, no :)

It is indeed not often useful, since one would usually use a userland
daemon to access the system, but when one's system does not boot
properly or something similar, it's useful to have the braille
console. That's just very not often useful.

Samuel