adapter, what's in a name

adapter, what's in a name

[Karl Dahlke]

First, my mail client, edbrowse.sourceforge.net,
doesn't have a reply all function.
Never needed it.
Guess I better implement it.   :-)
Should probably take me a couple days of spare time,
if I can find a couple days of spare time;
and I'm sure other users will want it.
Meantime, I pulled the emails out of the headers and pasted them in.
Hope that reasonably works.

As was pointed out, it is difficult to place an accessibility adapter
under one particular subsystem.
Mine takes over the screen, to be a screen reader,
and it captures tty output, because it is more than just a screen reader,
it buffers output, exactly as generated, for my review.
And it uses the serial port to send text to my external synthesizer,
but sometimes it uses an on-board synth, and all this would be useless
if it didn't intercept keystrokes to read lines,
words, letters, and so on.
And I want to enhance it to do the same thing for usb keyboards.
It touches many subsystems, and doesn't belong in any one of them over the others.
It actually changes the computer, in a fundamental way.
That's why I suggested a new directory drivers/accessibility.

Here is another reason.
When you run make config, these accessibility adapters belong together logically.
CONFIG_ACCESSIBILITY
help:
Say Y here if you need to adapt this computer for a disabled user.
Saying Y will not increase the size of your kernel,
it will only offer various modules that you can use to
magnify the screen, modify the keyboard, send text to a speech synthesizer,
and so on.
If you don't anticipate any disabled users, it is ok to say N.

Most people will say N,
or perhaps M, building everything as modules in case they are needed some day.
I don't know, it just makes sense to me I guess.
If we can go along with this,
I can write a patch for drivers/Makefile and drivers/Kconfig
that would put this in place.

Karl Dahlke

Re: adapter, what's in a name

[Frans Pop]

Karl Dahlke wrote:
> Meantime, I pulled the emails out of the headers and pasted them in.
> Hope that reasonably works.

Well, you're still breaking the thread by starting a new one.

Guess when you're implementing reply-to-all, you should also think about
implementing support for In-Reply-To: and References: headers (and possibly
a whole lot of other stuff that's supposed to be included in a
standards-compliant MUA).

Cheers,
FJP

Re: adapter, what's in a name

[Stefan Richter]

Karl Dahlke wrote:
> As was pointed out, it is difficult to place an accessibility adapter
> under one particular subsystem.
> Mine takes over the screen, to be a screen reader,
> and it captures tty output, because it is more than just a screen reader,
> it buffers output, exactly as generated, for my review.
> And it uses the serial port to send text to my external synthesizer,
> but sometimes it uses an on-board synth, and all this would be useless
> if it didn't intercept keystrokes to read lines,
> words, letters, and so on.
> And I want to enhance it to do the same thing for usb keyboards.
> It touches many subsystems, and doesn't belong in any one of them over the others.

I would expect that these various functions are implemented in a modular
fashion, thus also giving some flexibility regarding the file layout of
the source code.

> Here is another reason.
> When you run make config, these accessibility adapters belong together logically.
> CONFIG_ACCESSIBILITY
> help:
> Say Y here if you need to adapt this computer for a disabled user.
> Saying Y will not increase the size of your kernel,
> it will only offer various modules that you can use to
> magnify the screen, modify the keyboard, send text to a speech synthesizer,
> and so on.
> If you don't anticipate any disabled users, it is ok to say N.

I agree that it makes a lot of sense to group all of these drivers into
a common menu.  The menu layout doesn't have to be entirely the same as
the source code files layout (it never is the same in the last
consequence anyway), but it would of course help to keep config menu
layout and source files layout mostly aligned.
-- 
Stefan Richter
-=====-==--- --=- =-=--
http://arcgraph.de/sr/

adapter, what's in a name

[Karl Dahlke]

The longer I stay on this list, the more I will learn.
But it's high volume, so I may not be able to stay for long.

I completely understand your point about the word adapter.
It is highly overloaded, to the point that it is almost meaningless.
How about "accessibility"?
Drivers and modules designed to make linux more accessible
could be placed in drivers/accessibility in the source tree.
It's just a suggestion.
If there is a better word for this concept, please let me know.

And I finally understand what you are trying to say about /proc.
Processes, and perhaps memory and raid by extension,
but not everything under the planet.
Would it be better for accessibility drivers to create files through sysfs, e.g.
/sys/accessibility/jupiter/synth
Naturally the jupiter subtree would appear when that module was loaded,
and disappear when it was removed.

One person said, essentially,
"We'll worry about this when the first such driver comes along."
But that's a chicken egg problem, isn't it?
Let's set it up now, so things have a place to be.
Besides, speakup has been around for a long long time,
and jupiter almost as long.
These have both been converted to use the new notifiers,
along with pcclicks (sounds accompanying console output),
halfqwerty (one handed typing), and others.
Many of these will not need any virtual files, but some will,
and they need a place to be.
Beyond this, the software should exist somewhere, someday, in the source tree.
Not every driver under the sun, but some of them,
that have proved their merit, and meet the high standard of Linux coding, etc.
Mac comes bundled with an internal screen reader,
and windows has had an accessibility section for a long time, why not linux?
This is the best operating system in so many ways;
let's not be behind when it comes to accessibility.

Your thoughts are welcome.

Karl Dahlke

Re: adapter, what's in a name

[Stefan Richter]

Karl Dahlke wrote:
> The longer I stay on this list, the more I will learn.
> But it's high volume, so I may not be able to stay for long.

Because of the high volume at this list, it is essential that
  - you keep everyone who posted in a tread in the Cc: list of your
    replies, (that way it is possible to discuss on LKML even with
    people who are not subscribed; but more importantly, people who
    take part in a discussion are less likely to miss replies),
  - you actually reply rather than start new threads all the time.

So, as Randy already asked you, please use reply-to-all when continuing
this discussion.  That way (and with other measures like good subjects,
or respectively keeping the subject in replies if applicable) the list
volume becomes easily manageable.

> Drivers and modules designed to make linux more accessible
> could be placed in drivers/accessibility in the source tree.
> It's just a suggestion.
> If there is a better word for this concept, please let me know.
> 
> And I finally understand what you are trying to say about /proc.
> Processes, and perhaps memory and raid by extension,
> but not everything under the planet.
> Would it be better for accessibility drivers to create files through sysfs, e.g.
> /sys/accessibility/jupiter/synth
> Naturally the jupiter subtree would appear when that module was loaded,
> and disappear when it was removed.

Aren't those drivers ones for
  - input devices,
  - display devices (in a more general sense than visual displays, i.e.
    also including audible and tactile displays)?
Besides, if you had for example an USB device of that type, the most
natural place for its sources would be somewhere beneath drivers/usb/.

About the userspace interfaces of such drivers:

  - As was noted, /proc is generally not for userspace ABIs except to
expose properties of processes and a few selected other core properties
of the kernel.

  - /sys is for userspace ABIs which specifically pertain to properties
of kernel objects, notably properties of the kernel representations of
devices and of kernel modules.  Have a look into /sys/devices, /sys/bus,
and /sys/modules to get an idea.  Note, a lot of what is exposed in /sys
does not constitute stable long-time supported ABIs; see
Documentation/sysfs-rules.txt.

  - There are other types of ABIs for I/O (character device files, block
device files), message-based(?) I/O (netlink), configuration (configfs),
and more.

I have no idea what kind of communication with userspace the various
accessibility related drivers maintain.
-- 
Stefan Richter
-=====-==--- --=- =-=--
http://arcgraph.de/sr/

Re: adapter, what's in a name

[Stefan Richter]

I wrote:
>   - There are other types of ABIs for I/O (character device files, block
> device files), message-based(?) I/O (netlink), configuration (configfs),
> and more.

PS:  Device files are not only suitable for bulk I/O via read and write,
they are also capable of event notification by means of poll and select
and of other kinds of I/O like configuration related I/O by means of ioctl.
-- 
Stefan Richter
-=====-==--- --=- =-=--
http://arcgraph.de/sr/

Re: adapter, what's in a name

[Jan Engelhardt]

On Feb 20 2008 10:38, Stefan Richter wrote:
>Karl Dahlke wrote:
>> The longer I stay on this list, the more I will learn.
>> But it's high volume, so I may not be able to stay for long.
>
>Because of the high volume at this list, it is essential that
>  - you keep everyone who posted in a tread in the Cc: list of your
>    replies, (that way it is possible to discuss on LKML even with
>    people who are not subscribed; but more importantly, people who
>    take part in a discussion are less likely to miss replies),
>  - you actually reply rather than start new threads all the time.

Indeed, in PINE, mails with your address in Cc get preprended with a
minus sign, mails with your addr in To gets prepended with a plus
sign, conveniently marking the discussions one has taken part in. (Or
alternatively, one can use 'select all mails with my address' to
color-highlight it.) Pretty nifty.

>Aren't those drivers ones for
>  - input devices,
>  - display devices (in a more general sense than visual displays, i.e.
>    also including audible and tactile displays)?
>Besides, if you had for example an USB device of that type, the most
>natural place for its sources would be somewhere beneath drivers/usb/.

Well actually, I think it would go into drivers/input/. It is not
quite obvious.

Wireless USB -- drivers/net/wireless, not drivers/usb/
Serial USB   -- drivers/usb/serial, not drivers/serial/usb/
for example, but it seems to flow well anyway.

Re: adapter, what's in a name

[Stefan Richter]

Jan Engelhardt wrote:
> On Feb 20 2008 10:38, Stefan Richter wrote:
>>Because of the high volume at this list, it is essential that
>>  - you keep everyone who posted in a tread in the Cc: list of your
>>    replies,
...
> Indeed, in PINE, mails with your address in Cc get preprended with a
> minus sign,

Also, one can have rules to automatically sort into different mail folders.

...
>>Aren't those drivers ones for
>>  - input devices,
>>  - display devices (in a more general sense than visual displays, i.e.
>>    also including audible and tactile displays)?
>>Besides, if you had for example an USB device of that type, the most
>>natural place for its sources would be somewhere beneath drivers/usb/.
> 
> Well actually, I think it would go into drivers/input/. It is not
> quite obvious.
> 
> Wireless USB -- drivers/net/wireless, not drivers/usb/
> Serial USB   -- drivers/usb/serial, not drivers/serial/usb/
> for example, but it seems to flow well anyway.

Right, I should have looked that up before posting.

Many drivers interact with more than one kernel subsystem, so the answer
to what put where is indeed not always obvious.
-- 
Stefan Richter
-=====-==--- --=- =-=--
http://arcgraph.de/sr/

Re: adapter, what's in a name

[Jan Engelhardt]

On Feb 19 2008 18:16, Karl Dahlke wrote:
>
>I completely understand your point about the word adapter.
>It is highly overloaded, to the point that it is almost meaningless.
>How about "accessibility"?
>Drivers and modules designed to make linux more accessible
>could be placed in drivers/accessibility in the source tree.
>It's just a suggestion.
>If there is a better word for this concept, please let me know.

Yes, that does not sound bad. It is a common term in the redmond os,
and I think I even saw it in the kde control center last time I used
that.

>And I finally understand what you are trying to say about /proc.
>Processes, and perhaps memory and raid by extension,

RAID is in /sys/block/md*/md  ;-)

>but not everything under the planet.
>Would it be better for accessibility drivers to create files through sysfs, e.g.
>/sys/accessibility/jupiter/synth
>Naturally the jupiter subtree would appear when that module was loaded,
>and disappear when it was removed.

Naturally, just like it would in procfs.

>One person said, essentially,
>"We'll worry about this when the first such driver comes along."
>But that's a chicken egg problem, isn't it?

To a given extent yes, because procfs code is somewhat different
from sysfs is somewhat different from a character-based device.
(Maybe you also want to have both a device and a sysfs file, like md.)

>Let's set it up now, so things have a place to be.
>Besides, speakup has been around for a long long time,
>and jupiter almost as long.
>These have both been converted to use the new notifiers,
>along with pcclicks (sounds accompanying console output),
>halfqwerty (one handed typing), and others.

(Mentioning "halfqwerty" reminds me of Sony's 13-key Thumb Phrase "IM".)

>Many of these will not need any virtual files, but some will,
>and they need a place to be.
>Beyond this, the software should exist somewhere, someday, in the source tree.
>Not every driver under the sun, but some of them,
>that have proved their merit, and meet the high standard of Linux coding, etc.
>Mac comes bundled with an internal screen reader,
>and windows has had an accessibility section for a long time, why not linux?

What accessibility functions does Windows have that Linux (in
general, things are usually implemented only in X or KDE) does not?

>This is the best operating system in so many ways;
>let's not be behind when it comes to accessibility.