From mboxrd@z Thu Jan 1 00:00:00 1970 From: Havoc Pennington Date: Fri, 18 Apr 2003 05:39:05 +0000 Subject: Re: communicating with user login sessions 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 On Thu, Apr 17, 2003 at 04:50:14PM -0700, David Brownell wrote: > I've added a link to D-Bus right there. Thanks! > How would you speculate that a hotplug event should be delivered > to the "system message bus"? I'm not quite sure how the kernel > would be expected to authenticate itself, or whether it should. > If there's going to be a daemon collecting kernel events, I tend > to think it should be able to read them directly ... Alan was kind enough to explain some of how devices work to me last week. If I understand correctly, there are really two phases to hotplugging a device. There was just some discussion of this here: http://www.xfree86.org/pipermail/forum/2003-April/001307.html http://www.xfree86.org/pipermail/forum/2003-April/001328.html http://www.xfree86.org/pipermail/forum/2003-April/001329.html Specifically, the relevant bit of those mails is that there's a multi-phase process, and during that process there are two separate places we might want to kick out to userspace. In brief: a) we might first notify userspace that an unknown device has appeared on the USB or other bus b) we might then notify userspace that a major/minor has been created, i.e. there is a new usable device So my understanding is that for a), we pretty much just want some simple-as-possible low-overhead single process that loads the right driver for the given device. This driver then creates 0-N major/minor. For b), lots of apps might want to know, and they might be running in a user login session. For example, that's the point where your desktop might want to display a camera icon if you plug in a camera. Please correct this if I'm confused, because I really am an Xlib-and-above programmer most of the time. ;-) It seems to me that D-BUS is really nice for b), where we want to tell the user session about a new usable device. This is kind of the canonical purpose of D-BUS. But I'm not sure it's all that useful for a). The one exception is that as part of a), you might sometimes want to ask the user what driver to load. So you could use D-BUS for that. "Is this a mass storage device?" etc. Or more simply, D-BUS could be used to show an error message: "I don't know what you just plugged in, but I'm ignoring it." That way you don't plug in an unknown device and just get silence, you have some indication that the device works even if there's no driver. When people say "hotplug" do they mean both a) and b) or only a)? I'm a bit unclear on why you want multiple handlers for a) as people have discussed recently - my simplistic understanding is that all you can do with a device in phase a) is load a driver for it - so I think I'm missing some data. Anyway, I've been trying to get some notes together on how devices might appear to the applications/desktop layer of the OS. They aren't really presentable, but part of the notes are the appended sketch of "what happens when plugging in a camera" - I'd love comments on it. Havoc (Note: In this sequence of events, the word "system" means an appropriate conglomerate of kernel and userspace features, it does not imply kernelspace.) - I plug in my new digital camera. - If the camera's interface type (e.g. USB) supports it, the presence of a new device is noticed without user intervention. - The system gets whatever information is available from the device about the hardware model. Vendor, ProdID, whatever it can get. - The system consults a mapping from hardware model information to driver information. This mapping is created by merging three sources of information: user-provided information, OEM-provided information, and operating-system-vendor-provided information. - If no driver is found, the system delivers a notification to the desktop environment, and the desktop environment informs the user that the device is not supported. Alternatively, the desktop environment asks the user which driver to try and passes the answer back to the system; the system a) tries that driver and b) saves the driver information in the above-mentioned mapping. [D-BUS proposed for implementation of this] - The system loads a driver once one has been found in the mapping, or added to the mapping. - A major/minor pair is created for the device, along with a /dev file if necessary. - A notification is sent out that a new major/minor pair has been created. [D-BUS proposed for implementation of this] - The user's desktop environment asks the system what sort of device is represented by the major/minor pair: camera, scanner, printer, etc. - If the system does not know, it says "device type is unknown." - If the device type is unknown, the desktop environment asks the user to provide it. "What did you just plug in?" - After the user provides this information, the desktop environment passes it back to the system. The system records a mapping from the hardware model identifying information to the device type. Next time a major/minor pair is created for a device with the same model information, the system will report its type accordingly. - The desktop environment allows the user to interact with the device in device-appropriate ways. For example, view images from a camera, monitor errors from a printer, or whatever. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ 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