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
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/
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/
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.
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.
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/