Re: Final remote(4) / remote(9) API proposal

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 10 Oct 2008 14:34:56 -0400 (EDT)
    From:        "Jared D. McNeill" <jmcneill%invisible.ca@localhost>
    Message-ID:  
<Pine.NEB.4.64.0810101432590.17983%discovery.invisible.ca@localhost>

  | It depends what you mean by application. As I have stated before in this 
  | thread, /dev/remote isn't intended for direct use by the application that 
  | processes commands, they instead should talk to the userspace daemon which 
  | handles keymappings.

The application I meant was what you're calling the userspace daemon.

I guess it all depends what you see the interface between it and the
kernel looking like -- I know that is what is being discussed, but I
mean in a slightly different way.

If you imagine this daemon talking to /dev/remote /dev/controlpad
/dev/ethercontrol and a whole host of (potential) devices like that,
each of which speaking its own private protocol to fetch events
(which it then translates into suitable actions to deliver to the
final consumer applications) then I guess the name "remote" is OK
for the first of those interfaces to get implemented.

I'd however prefer a single path between the kernel and the daemon,
providing events from all the different kinds of application control
devices that might exist, and then translating those inputs into
events and handing them off to consumers.   The kernel drivers would
take the raw input from the different devices, talking whatever protocol
is needed to fetch that, and translate that into a common data stream
into the daemon.   In that context, "remote" is perhaps too specific.

kre