From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Wed, 04 Jan 2006 01:20:59 +0000 Subject: Re: [PATCH] The Mandriva Collection Message-Id: <20060104012059.GA12798@vrfy.org> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org On Tue, Jan 03, 2006 at 08:55:23PM +0100, Olivier Blin wrote: > Kay Sievers writes: >=20 > >> We've also moved udevinfo in /bin, since it is needed early at boot to > >> apply permissions on device nodes, before /usr is mounted. It uses the > >> pam_console.dev agent, that we install as /lib/udev/pam_console.dev > > > > You probably just want to add the symlinks to the event environment? >=20 > Yes, it would be better. I added this after the last mail, it's DEVLINKS in the current udev. > > Hey, but matching on device node names with pam_console in a udev envir= onment > > sounds pretty strange anyway... >=20 > What's that strange? You can name devices whatever you like with udev and having a separate config file in /etc which matches on device names is just silly. Infrastructure to provide access to devices must know the kind/class of device what pam_console can't know. We are thinking about integrating that functionality in HAL as SUSE already does, but not in away we would like to see upstream. Todays systems must also support user switching what pam_console's simple chgrp() can't provide. You want to have ACL's on device nodes like we do with resmgr. We will work on integrating/replacing resmgr into/with DBUS/HAL, when the needed SUSE kernel patches for ACL's on tmpfs show up in the upstream kernel. > >> We also provide a script to convert hotplug usermaps to udev rules. > >> Camera and scanners aren't yet handled by hal, and some drivers still > >> don't use the standard way to load firmwares in the kernel. See: > >> http://qa.mandriva.com/twiki/bin/view/Main/Udev#Hot_plug_usermaps > > > > That certainly belongs to HAL. There should be almost no overlap between > > the need for "user permissions" and system without HAL these days. >=20 > Right, gphoto stuff is now handled in hal, it's the way to go. Fine. > >> By the way, the ueagle-atm author want to use fxload in this new > >> driver, is there any good alternative? A ticket is opened there: > >> https://gna.org/task/?func=DEtailitem&item_id'08 >=20 > But what for these fxload stuff? We still need some usermaps > equivalent (i.e. apply the same action for different device IDs). How many map entries we are talking about? > >> Finally, we added some agents for ieee1394, net, and input (all copied > >> from the old hotplug agents). > > > > IDE and input should get MODALIAS soon. >=20 > Yep, that should remove some more non-standard patches/scripts. Yes, I think that are the last ones that are widely used. > >> For a complete list of patches, scripts, rules, and packaging files, > >> see: http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/udev/ > > > > Don't you have the nice persistent /dev/disk rules? But I still can see > > devfs disk crap, bah ... :) >=20 > I happen to use theses nice symlinks as well, in the Mandriva package, > we use the etc/udev/persistent.rules file from the udev tarball. Ah nice, that's great. Kay ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick _______________________________________________ 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