All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.