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 01:16:49 -0500 [thread overview]
Message-ID: <200406030116.49431.dtor_core@ameritech.net> (raw)
In-Reply-To: <xb7smdd425i.fsf@savona.informatik.uni-freiburg.de>
On Thursday 03 June 2004 12:54 am, Sau Dan Lee wrote:
> >>>>> "Dmitry" == Dmitry Torokhov <dtor_core@ameritech.net> writes:
>
> Dmitry> Let me start with saying that this is a very good patch
> Dmitry> and that is exactly what I have in mind with regard to
> Dmitry> serio port/device binding. The only problem with the
> Dmitry> patch is that it uses wrong foundation, namely procfs,
> Dmitry> because:
> ...
>
> Dmitry> So we have several options - if we adopt procfs based
> Dmitry> solution now we will have to maintain it for very long
> Dmitry> time, along with competing sysfs implementation. Dropping
> Dmitry> one kernel parameter which will never be widely used is
> Dmitry> much easier, IMO.
>
> It's not just the matter of dropping one kernel parameter. The procfs
> support, _already implemented_, allows one to fine-tune the binding
> between serio ports and devices, which is a new and useful feature
> that your kernel parameter doesn't provide.
What I was trying to say is serio and input system will have sysfs support,
there is no question about that because sysfs _is_ the new driver model. So
by adopting procfs based solution we'll get ourselves 2 competing interfaces
for the same thing, just one will be very limited.
>
> Can you unbind the keyboard port? Can you bind/unbind any of the AUX
> ports *dynamically* without reloading the i8042 module? These
No, and I was not trying to. It is just a stop-gap measure to help end
users to get their PS/2 devices working until we have proper infrastructure
in place.
> functionalities are already there in the serio-related code. Just a
> userland interface is missing. My patch is to fill this gap.
>
>
>
> Dmitry> So I propose we all join our ranks and tame that sysfs
> Dmitry> together ;) I had some patches that were converting
> Dmitry> drivers to the sysfs adding them to serio bus,
>
> sysfs looks good for simple parameters: integers, strings. For
> anything more complicated (sets, graphs), I don't see it fit (yet).
> Unfortunately, the serio port<-->device relation is already a graph (1
> to n).
>
> I'd like to see how you implement the device<-->handler binding in
> input.c using sysfs.
Sysfs provides all the same features as procfs (I mean you write read/write
methods and have them do whatever you please) but it also has benefits of
your stuff integrating with the rest of devices into a hierarchy.
--
Dmitry
next prev parent reply other threads:[~2004-06-03 6:17 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 [this message]
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
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=200406030116.49431.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.