From: Dmitry Torokhov <dtor_core@ameritech.net>
To: Sau Dan Lee <danlee@informatik.uni-freiburg.de>
Cc: linux-kernel@vger.kernel.org,
Tuukka Toivonen <tuukkat@ee.oulu.fi>,
Andries Brouwer <aeb@cwi.nl>, Vojtech Pavlik <vojtech@suse.cz>
Subject: Re: [PATCH] serio.c: dynamically control serio ports bindings via procfs (Was: [RFC/RFT] Raw access to serio ports)
Date: Thu, 3 Jun 2004 02:39:40 -0500 [thread overview]
Message-ID: <200406030239.40046.dtor_core@ameritech.net> (raw)
In-Reply-To: <xb7d64h3y2k.fsf@savona.informatik.uni-freiburg.de>
On Thursday 03 June 2004 02:22 am, Sau Dan Lee wrote:
> >>>>> "Dmitry" == Dmitry Torokhov <dtor_core@ameritech.net> writes:
>
> >> Unfortunately, the connection between devices and drivers
> >> (either in the serio.c interface or in the input.c interface)
> >> is a graph. It is more complicated than an array. Yes, you
> >> can represent a graph with a matrix or an adjacency list, both
> >> representable as arrays in one way or another. Nothing in a
> >> digital computer cannot be represented by an array of bits
> >> anyway! But useability of the interface must not be ignored.
> >>
>
> Dmitry> I am not sure where you see the problem - consider a PCI
> Dmitry> bus and all PCI devices and all drivers tyhat currently
> Dmitry> present in kernel. They are using the new driver model and
> Dmitry> sysfs and they come together quite nicely.
>
> # ls -l /sys/bus/pci/devices/0000:01:00.0
>
> -r--r--r-- 1 root root class
> -rw-r--r-- 1 root root config
> -rw-r--r-- 1 root root detach_state
> -r--r--r-- 1 root root device
> -r--r--r-- 1 root root irq
> drwxr-xr-x 2 root root power
> -r--r--r-- 1 root root resource
> -r--r--r-- 1 root root subsystem_device
> -r--r--r-- 1 root root subsystem_vendor
> -r--r--r-- 1 root root vendor
>
> # ls -l /sys/bus/pci/drivers/PIIX\ IDE
>
> lrwxrwxrwx 1 root root 17:20 0000:00:07.1 ->
> ../../../../devices/pci0000:00/0000:00:07.1
> --w------- 1 root root 17:20 new_id
>
>
> The info are binary (shown in 0x???? notation). Each reflects
> directly the binary value of the corresponding 'attribute'.
>
> 1) None of these are arrays. But in the input system, each device can
> be attached to _multiple_ handlers, and each handler can handle
> _multiple_ devices. That's an n-to-n relation.
And when they join together they form a new entity, a new device. And that's
input system, not serio.
>
> 2) I can't find out how to dynamically change the driver of a PCI
> device.
No need really. PCI devices are easily identifiable.
>
> 3) PCI device<-->handler is a many-to-one relation. The input system
> is many-to-many.
>
> 4) How to display/parse a device<-->handler connection? You want to
> show and accept a pointer value?
Strings are perfectly valid:
[dtor@core dtor]$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
acpi-cpufreq
[dtor@core dtor]$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
powersave userspace performance
It just depends on implementation.
>
> The sysfs interface looks very confusing to me.
>
Yes, I haven't wrapped my mind around it completely either. But we have
Greg K-H and others who will make sure we chose the right path ;)
--
Dmitry
next prev parent reply other threads:[~2004-06-03 7:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-02 19:09 [PATCH] serio.c: dynamically control serio ports bindings via procfs (Was: [RFC/RFT] Raw access to serio ports) Dmitry Torokhov
2004-06-03 5:54 ` Sau Dan Lee
2004-06-03 6:16 ` Dmitry Torokhov
2004-06-03 6:45 ` Sau Dan Lee
2004-06-03 6:58 ` Dmitry Torokhov
2004-06-03 7:22 ` Sau Dan Lee
2004-06-03 7:39 ` Dmitry Torokhov [this message]
2004-06-03 7:47 ` Sau Dan Lee
-- strict thread matches above, loose matches on Subject: below --
2004-06-02 9:49 [RFC/RFT] Raw access to serio ports (2/2) Sau Dan Lee
2004-06-02 12:33 ` Dmitry Torokhov
2004-06-02 17:24 ` [PATCH] serio.c: dynamically control serio ports bindings via procfs (Was: [RFC/RFT] Raw access to serio ports) Sau Dan Lee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200406030239.40046.dtor_core@ameritech.net \
--to=dtor_core@ameritech.net \
--cc=aeb@cwi.nl \
--cc=danlee@informatik.uni-freiburg.de \
--cc=linux-kernel@vger.kernel.org \
--cc=tuukkat@ee.oulu.fi \
--cc=vojtech@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.