linux-kernel - Re: adapter, what's in a name

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47BBF532.4030704@s5r6.in-berlin.de>
Date:	Wed, 20 Feb 2008 10:38:58 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Karl Dahlke <eklhad@...cast.net>
CC:	linux-kernel@...r.kernel.org, Sam Ravnborg <sam@...nborg.org>,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	Randy Dunlap <randy.dunlap@...cle.com>, Valdis.Kletnieks@...edu
Subject: Re: adapter, what's in a name

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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/