RE: [PATCH] serio.c: dynamically control serio ports bindings via procfs (Was: [RFC/RFT] Raw access to serio ports)

[Dmitry Torokhov]

Sau Dan Lee wrote:
> 
> I've  added procfs  support to  serio.c, so  that we  can  now control
> dynamically which serio ports connect  to which serio devices.  I call
> it "serio_switch", because it conceptually works like a patch panel or
> a switch with which you can rewire the connections.

Let me start with saying that this is a very good patch and that is
exactly what I have in mind with regard to serio port/device binding.
The only problem with the patch is that it uses wrong foundation, namely
procfs, because:
 
- procfs hierarchy is disconnected from the rest of the system. You
  cannot trace device ownership starting with root PCI bus down to your
  AUX port.
- there is no automatic hotplug notification to the userspace
- it is not flexible with regard to adding custom attributes to the
  drivers. I can see you adding rate and resolution to psmouse driver
  and repeat rate to atkbd. With sysfs drivers can themselves create
  attributes and they will be cleaned up once device disappears. With
  procfs you will have to export it form serio to be available to
  drivers and cleanup can be a nightmare.

Of course sysfs has its "problems" - it requires users to follow certain
lifetime rules which are different from what serio uses at the moment.

So we have several options - if we adopt procfs based solution now we
will have to maintain it for very long time, along with competing sysfs
implementation. Dropping one kernel parameter which will never be widely
used is much easier, IMO.

So I propose we all join our ranks and tame that sysfs together ;) I had
some patches that were converting drivers to the sysfs adding them to
serio bus, I probably should just send what I have as is for review
(I was going to rediff them as they are somewhat stale, I'll see what
shape they are later tonight).

--
Dmitry

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