Re: [PATCH] The Mandriva Collection

Re: [PATCH] The Mandriva Collection

[Olivier Blin]

Scott James Remnant <scott@ubuntu.com> writes:

> Attached are the current set of Ubuntu patches to udev, as of 077.

(sorry for being a moron, but where are these new releases announced?)

In Mandriva, the only big patch is a coldplug implementation in
udevstart (similar to udevsynthethize, but synchronous). It will be
dropped once we build a kernel package that provides uevent.

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

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

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/?funcfitailitem&item_id'08

We don't use anymore the hotplug.d and dev.d directories, and we use
/lib/firwmare and /lib/udev, so the package is pretty "standard".

Finally, we added some agents for ieee1394, net, and input (all copied
from the old hotplug agents).

For a complete list of patches, scripts, rules, and packaging files,
see: http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/udev/

Regards

-- 
Olivier Blin - Mandriva



-------------------------------------------------------
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\x16865&op=click
_______________________________________________
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

Re: [PATCH] The Mandriva Collection

[Marco d'Itri]

On Dec 12, Olivier Blin <oblin@mandriva.com> wrote:

> 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:
Why? There is nothing wrong with fxload, at least for most devices.

-- 
ciao,
Marco


-------------------------------------------------------
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\x16865&op=click
_______________________________________________
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

Re: [PATCH] The Mandriva Collection

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

On Mon, 2005-12-12 at 18:43 +0100, Olivier Blin wrote:

> Scott James Remnant <scott@ubuntu.com> writes:
> 
> > Attached are the current set of Ubuntu patches to udev, as of 077.
> 
> We also provide a script to convert hotplug usermaps to udev rules.
> 
For this we use grepmap, a native tool to parse the map files directly
rather than convert them ... largely just for backwards compatibility
now though, everything else is a udev rule.

http://people.ubuntu.com/~scott/software/grepmap/

Scott
-- 
Scott James Remnant
scott@canonical.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] The Mandriva Collection

[Olivier Blin]

md@Linux.IT (Marco d'Itri) writes:

> On Dec 12, Olivier Blin <oblin@mandriva.com> wrote:
>
>> 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:
> Why? There is nothing wrong with fxload, at least for most devices.

But is there any way currently to request fxload on hotplug event, or
should it be triggered when the device is plugged?
The later would require an udev rule per device IDs, which is the
equivalent of usermaps.

-- 
Olivier Blin - Mandriva



-------------------------------------------------------
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\x16865&op=click
_______________________________________________
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

Re: [PATCH] The Mandriva Collection

[Marco d'Itri]

On Dec 12, Olivier Blin <oblin@mandriva.com> wrote:

> But is there any way currently to request fxload on hotplug event, or
> should it be triggered when the device is plugged?
> The later would require an udev rule per device IDs, which is the
> equivalent of usermaps.
Yes, but again there is nothing wrong with this. The first VID/PID
pair will make udev run fxload, then the second one will appear and the
kernel driver will be loaded.

-- 
ciao,
Marco


-------------------------------------------------------
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\x16865&op=click
_______________________________________________
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

Re: [PATCH] The Mandriva Collection

[Olivier Blin]

Scott James Remnant <scott@canonical.com> writes:

>> We also provide a script to convert hotplug usermaps to udev rules.
>> 
> For this we use grepmap, a native tool to parse the map files directly
> rather than convert them ... largely just for backwards compatibility
> now though, everything else is a udev rule.
>
> http://people.ubuntu.com/~scott/software/grepmap/

Thanks!
Then, the ieee1384 agent we copied from hotplug in Mandriva can be
better replaced with grepmap.
It could also be used to parse the remaining usermaps we use (gphoto,
bluetooth, scanners), but it's probably slower than converting them to
pure udev rules.

-- 
Olivier Blin - Mandriva



-------------------------------------------------------
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\x16865&op=click
_______________________________________________
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

Re: [PATCH] The Mandriva Collection

[Marco d'Itri]

On Dec 12, Olivier Blin <oblin@mandriva.com> wrote:

> Then, the ieee1384 agent we copied from hotplug in Mandriva can be
> better replaced with grepmap.
Why? ieee1384 drivers now support $MODALIAS (which is not yet generated
by the kernel, but can be created with a trivial shell script, look at
the Debian package).

-- 
ciao,
Marco


-------------------------------------------------------
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\x16865&op=click
_______________________________________________
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

Re: [PATCH] The Mandriva Collection

[Olivier Blin]

md@Linux.IT (Marco d'Itri) writes:

> On Dec 12, Olivier Blin <oblin@mandriva.com> wrote:
>
>> Then, the ieee1384 agent we copied from hotplug in Mandriva can be
>> better replaced with grepmap.
>
> Why? ieee1384 drivers now support $MODALIAS (which is not yet generated
> by the kernel

This kernel changelog entry tells it's supported in 2.6.14:
[PATCH] provide MODALIAS= enviroment variable to autoload ieee1394
modules via udev

> but can be created with a trivial shell script, look at
> the Debian package).

Right, it's even better to generate the modalias when possible.
Anyway, this shouldn't be needed anymore in recent kernels, I'll stop
bothering you with the old kernel in Mandriva cooker.

-- 
Olivier Blin - Mandriva



-------------------------------------------------------
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\x16865&op=click
_______________________________________________
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

Re: [PATCH] The Mandriva Collection

[Olivier Blin]

md@Linux.IT (Marco d'Itri) writes:

> On Dec 12, Olivier Blin <oblin@mandriva.com> wrote:
>
>> But is there any way currently to request fxload on hotplug event, or
>> should it be triggered when the device is plugged?
>> The later would require an udev rule per device IDs, which is the
>> equivalent of usermaps.
> Yes, but again there is nothing wrong with this. The first VID/PID
> pair will make udev run fxload, then the second one will appear and the
> kernel driver will be loaded.

It requires to compare twice more all IDs for each plugged USB device,
which is avoided when using request_firmware().

And it needs a VID/PID rules list, which may not be easy to write
without duplication. What's the proper construction to replace this
kind of usermaps?

ACTION="add", SUBSYSTEM="usb", \
 SYSFS{idProduct}="xxxA", SYSFS{idVendor}="yyyA", \
 RUN+="/sbin/fxload -t fx2 -I /lib/firmware/ezusb/foo.hex"
ACTION="add", SUBSYSTEM="usb", \
 SYSFS{idProduct}="xxxB", SYSFS{idVendor}="yyyB", \
 RUN+="/sbin/fxload -t fx2 -I /lib/firmware/ezusb/foo.hex"
ACTION="add", SUBSYSTEM="usb", \
 SYSFS{idProduct}="xxxC", SYSFS{idVendor}="yyyC", \
 RUN+="/sbin/fxload -t fx2 -I /lib/firmware/ezusb/bar.hex"
ACTION="add", SUBSYSTEM="usb", \
 SYSFS{idProduct}="xxxD", SYSFS{idVendor}="yyyD", \
 RUN+="/sbin/fxload -t fx2 -I /lib/firmware/ezusb/bar.hex"

Writing dozens of such rules is very verbose, not readable at all, and
error prone. Is there at least some tool to automate this?

It can probably be simplified using PRODUCT values:

ACTION="add", SUBSYSTEM="usb", \
 ENV{PRODUCT}="xxxA/yyyA/*|xxxB/yyyB/*", \
 RUN+="/sbin/fxload -t fx2 -I /lib/firmware/ezusb/foo.hex"
ACTION="add", SUBSYSTEM="usb", \
 ENV{PRODUCT}="xxxC/yyyC/*|xxxD/yyyD/*" \
 RUN+="/sbin/fxload -t fx2 -I /lib/firmware/ezusb/bar.hex"

More generally, is there some construction to factorize this?
condA, condB, cond1, cond2, RUN+="fxload foo"
condA, condB, cond3, cond4, RUN+="fxload foo"
condA, condB, cond5, cond6, RUN+="fxload bar"
condA, condB, cond7, cond8, RUN+="fxload bar"

It duplicates condA and condB tests for all rules, and copy-paste
errors may be hard to spot because of long rules. (this example looks
short, but it gets trickier when condX and RUN values are expanded to
longer expressions).
Can we use environment variables to solve this, or is there something
better?

!condA, GOTO "fxload_end"
!condB, GOTO "fxload_end"
cond1, cond2, ENV{FXLOAD_FILE}=foo, GOTO="fxload_do"
cond3, cond4, ENV{FXLOAD_FILE}=foo, GOTO="fxload_do"
cond5, cond6, ENV{FXLOAD_FILE}ºr, GOTO="fxload_do"
cond7, cond8, ENV{FXLOAD_FILE}ºr, GOTO="fxload_do"
ENV{FXLOAD_FILE}!="?*", GOTO="fxload_end"
LABEL="fxload_do", RUN+="fxload $FXLOAD_FILE"
LABEL="fxload_end"

-- 
Olivier Blin - Mandriva



-------------------------------------------------------
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\x16865&op=click
_______________________________________________
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

Re: [PATCH] The Mandriva Collection

[Marco d'Itri]

On Dec 12, Olivier Blin <oblin@mandriva.com> wrote:

> And it needs a VID/PID rules list, which may not be easy to write
> without duplication. What's the proper construction to replace this
> kind of usermaps?
In one of my packages (which maybe should just have used fxload for
stage1...) I use:

BUS!="usb", ACTION!="add", GOTO="eciadsl_usb_add_end"

# Aethra Starmodem
SYSFS{idVendor}="0659", SYSFS{idProduct}="0915", \
        RUN+="/lib/hotplug/eciadsl stage1"
SYSFS{idVendor}="0915", SYSFS{idProduct}="0916", \
        RUN+="/lib/hotplug/eciadsl stage2 4 GS7070"

...

LABEL="eciadsl_usb_add_end"

Obviously I did not manually write rules for each of the 26 modems
supported, a trivial perl program does it.
Similar programs have been implemented by the libgphoto2 and libsane
maintainers.


> It can probably be simplified using PRODUCT values:
Ugly, and probably slower.

-- 
ciao,
Marco


-------------------------------------------------------
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\x16865&op=click
_______________________________________________
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

Re: [PATCH] The Mandriva Collection

[Kay Sievers]

On Mon, Dec 12, 2005 at 06:43:19PM +0100, Olivier Blin wrote:
> Scott James Remnant <scott@ubuntu.com> writes:
> 
> > Attached are the current set of Ubuntu patches to udev, as of 077.

> In Mandriva, the only big patch is a coldplug implementation in
> udevstart (similar to udevsynthethize, but synchronous). It will be
> dropped once we build a kernel package that provides uevent.
> 
> 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?
Hey, but matching on device node names with pam_console in a udev environment
sounds pretty strange anyway...

> 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.

> 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Þtailitem&item_id'08
> 
> We don't use anymore the hotplug.d and dev.d directories, and we use
> /lib/firwmare and /lib/udev, so the package is pretty "standard".

That's nice. So we are coming closer to a common setup.

> Finally, we added some agents for ieee1394, net, and input (all copied
> from the old hotplug agents).

IDE and input should get MODALIAS soon.

> 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 ... :)

Thanks,
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\x16865&op=click
_______________________________________________
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

Re: [PATCH] The Mandriva Collection

[Olivier Blin]

md@Linux.IT (Marco d'Itri) writes:

> Obviously I did not manually write rules for each of the 26 modems
> supported, a trivial perl program does it.
> Similar programs have been implemented by the libgphoto2 and libsane
> maintainers.

I wrote a more generic one to import usermaps, can't we ship such a
tool in the udev package, so that work isn't duplicated among all
distros?
My current script misses some features, but can be easily improved:
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/~checkout~/SPECS/udev/udev_import_usermap

>> It can probably be simplified using PRODUCT values:
> Ugly, and probably slower.

Yep, I saw that in the wis-go7007 rules file.

-- 
Olivier Blin - Mandriva



-------------------------------------------------------
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\x16865&op=click
_______________________________________________
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

Re: [PATCH] The Mandriva Collection

[Marco d'Itri]

On Dec 21, Olivier Blin <oblin@mandriva.com> wrote:

> > Obviously I did not manually write rules for each of the 26 modems
> > supported, a trivial perl program does it.
> > Similar programs have been implemented by the libgphoto2 and libsane
> > maintainers.
> I wrote a more generic one to import usermaps, can't we ship such a
> tool in the udev package, so that work isn't duplicated among all
> distros?
The point is that distributions should not need to *convert* hotplug
maps but just ship rules files in the appropriate packages.

-- 
ciao,
Marco


-------------------------------------------------------
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\x16865&op=click
_______________________________________________
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

Re: [PATCH] The Mandriva Collection

[Olivier Blin]

md@Linux.IT (Marco d'Itri) writes:

> On Dec 21, Olivier Blin <oblin@mandriva.com> wrote:
>
>> > Obviously I did not manually write rules for each of the 26 modems
>> > supported, a trivial perl program does it.
>> > Similar programs have been implemented by the libgphoto2 and libsane
>> > maintainers.
>> I wrote a more generic one to import usermaps, can't we ship such a
>> tool in the udev package, so that work isn't duplicated among all
>> distros?
> The point is that distributions should not need to *convert* hotplug
> maps but just ship rules files in the appropriate packages.

It's often more convenient to write hotplug maps, because it allows to
gather all devices IDs in one file, without RUN settings duplication.

You have some perl program to write the rules, what does it take as
input? Maybe it can packaged with udev (IIRC, you're currently
shipping this script in all your packages using it).

-- 
Olivier Blin - Mandriva



-------------------------------------------------------
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\x16865&op=click
_______________________________________________
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

Re: [PATCH] The Mandriva Collection

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

On Dec 21, Olivier Blin <oblin@mandriva.com> wrote:

> It's often more convenient to write hotplug maps, because it allows to
> gather all devices IDs in one file, without RUN settings duplication.
If you want to go for convenience then you should just have a list of
VID/PID pairs to be used to generate maps and rules, which is what most
applications apparently do.

> You have some perl program to write the rules, what does it take as
> input? Maybe it can packaged with udev (IIRC, you're currently
> shipping this script in all your packages using it).
My program just parses the file provided by the package with the list
of supported devices and is barely about the "quick hack" level, I do
not think it's much interesting but here it is.

-- 
ciao,
Marco

[-- Attachment #2: build_rules.pl --]
[-- Type: text/x-perl, Size: 1393 bytes --]

#!/usr/bin/perl -w
# build a udev rules file from the devices list in modules.db

use strict;

my %seen;

print <<END;
BUS!="usb", ACTION!="add", GOTO="eciadsl_usb_add_end"

END

while (<STDIN>) {
	chomp;
	next if /^#/ or /^$/;

	s/\t(\(#\d\))\t/ $1\t/;
	/^([^\t]+)\t+([\da-fA-F]{4})\t+([\da-fA-F]{4})\t+([\da-fA-F]{4})\t+([\da-fA-F]{4})\t+(GS\d{4})\t+(\d)\t+(\d)$/
		or die "Cannot parse the following line:\n$_\n";
	my ($device, $vid1, $pid1, $vid2, $pid2, $chip, $altsync, $altpppoeci)
		= ($1, $2, $3, $4, $5, $6, $7, $8);

	# suppress duplicated devices
	next if $seen{$vid1.$pid1.$vid2.$pid2.$chip.$altsync.$altpppoeci};
	$seen{$vid1.$pid1.$vid2.$pid2.$chip.$altsync.$altpppoeci} = 1;

	# Some devices have the same VID and PID but require different alt
	# parameters. Their owners are out of luck, and will need to manually
	# fix their configuration.
	next if $device =~ /^Linkmax HSA 100$/;

	# sanity check
	die "DUPLICATE: $device!\n" if $seen{$vid1.$pid1} or $seen{$vid2.$pid2};
	$seen{$vid1.$pid1} = 1; $seen{$vid2.$pid2} = 1;

	print "# $device\n";

	print <<"END" if $vid1.$pid1 ne $vid2.$pid2;
SYSFS{idVendor}=="$vid1", SYSFS{idProduct}=="$pid1", \\
	RUN+="/lib/hotplug/eciadsl stage1"
END

	print <<"END";
SYSFS{idVendor}=="$vid2", SYSFS{idProduct}=="$pid2", \\
	RUN+="/lib/hotplug/eciadsl stage2 $altsync $chip"

END
}

print <<END;
LABEL="eciadsl_usb_add_end"
END

exit 0;

Re: [PATCH] The Mandriva Collection

[Olivier Blin]

Kay Sievers <kay.sievers@vrfy.org> writes:

>> 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?

Yes, it would be better.
Or just use a single rule that runs a sh with the for loop.

> Hey, but matching on device node names with pam_console in a udev environment
> sounds pretty strange anyway...

What's that strange?

>> 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.

Right, gphoto stuff is now handled in hal, it's the way to go.

>> 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Þtailitem&item_id'08

But what for these fxload stuff? We still need some usermaps
equivalent (i.e. apply the same action for different device IDs).

>> Finally, we added some agents for ieee1394, net, and input (all copied
>> from the old hotplug agents).
>
> IDE and input should get MODALIAS soon.

Yep, that should remove some more non-standard patches/scripts.

>> 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 ... :)

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.

Regards

-- 
Olivier Blin - Mandriva



-------------------------------------------------------
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\x16865&op=click
_______________________________________________
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

Re: [PATCH] The Mandriva Collection

[Kay Sievers]

On Tue, Jan 03, 2006 at 08:55:23PM +0100, Olivier Blin wrote:
> Kay Sievers <kay.sievers@vrfy.org> writes:
> 
> >> 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?
> 
> 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 environment
> > sounds pretty strange anyway...
> 
> 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.
> 
> 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Þtailitem&item_id'08
> 
> 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.
> 
> 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 ... :)
> 
> 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\x16865&op=click
_______________________________________________
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