From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Cuyle Fritzinger Date: Sun, 03 Feb 2002 00:58:18 +0000 Subject: Re: User-level Tasks in Hotplug Scripts? Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Note: sorry for all the CC's. i've lost track of who is on what list. :P > > > Is there anything wrong with the simplistic approach of having a demon > > > listening on a socket? If you want it generic, you have to use generic > > > means of communication. > > You don't want to pass out permission to access your X server to anyone > > who happens to ask for it (if you do, you've compromized everything, > > or go down into compartmentalized workstation hell, someplace where we > > went 10 years ago and found fundamentally painful). > > So the issue is fundamentally one of authenticating > > the configuration GUI's process to the X server to allow connection. > There's no reason the listening demon has to be part of X, or is there ? > An interrested user would start a task listening upon login. The listener should definitely be left to the desktops, or as a background process as login in the case of a non-X environment. The hotplug backend might implement a generic configuration language. We've done this with gPhoto by using some common widgets and it works really well. we use it for configuration of camera settings (exposure, lens modes, etc...). It supports menus, lists, radio buttons, text entries, etc... all the standard widgets. Perhaps it would all work something like this: 1) Desktop listener listens on a port/fifo/pipe/whatever... 2) User plugs device 3) Hotplug runs appropriate script ("init"). init would be whatever hotplug does now. 4) Hotplug then runs script with "get_config" arg to retrieve the configuration 'widgets' (written to stdout) 5) Hotplug then writes the configuration widgets to the port/fifo/pipe/whatever, prefixed by a header that describes which device this is for. For now, hotplug considers itself done. 6) User select settings, selects OK. 7) Desktop listener writes the updated configuration widgets to the port/fifo/pipe/whatever 8) Hotplug then reads in the updated configuration widgets, then calls the appropriate hotplug script with "set_config" arg (config items are read from stdin). 9) Hotplug script handles the rest. Now, if multiple hotplug scripts try to claim a device, perhaps hotplug will write a configuration that lets the user select which script to use, and then it continues with the chosen hotplug script. This is something that came up when i brought this up earlier: what if jphoto and gphoto both want to use the device? just let them run, or let the user decide? if there is no listener, then perhaps they all should run. if there is a listener, let the user decide. security? make sure you only accept connections from a user who is locally logged in (not remote), unless you configure it differently to allow remote connections. this just needs to be developed further in a USB security model. (local user = full permissions on all USB devices?) :P -=Scott Fritzinger The gPhoto project www.gphoto.org _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel