Re: [PATCH] The Ubuntu Collection

[Kay Sievers <kay.sievers@vrfy.org>]

On Wed, Dec 07, 2005 at 05:12:59PM +0000, Scott James Remnant wrote:
> Attached are the current set of Ubuntu patches to udev, as of 077.  The
> rest of this e-mail is a brief description of each one, and why we have
> it.

Thanks for sending this. We made pretty good progress the last weeks and
seems the way udev is integrated in the systems is getting more similar
across distros. The goal is to make it as similar as possible, so we may
be able to share most of the stuff.

> 01-lib-udev.patch
>     This arranges for the various extras programs to be installed
>     directly into /lib/udev/ rather than into /sbin/.  Pretty sweet and
>     obvious.

That's nice. I wanted to do this too, but I need to make sure, not to
break existing users of the tools, cause they have been installed in
sbin for a long time. But in general I agree, that we should move all
the udev tools to /lib/udev. Btw: Marco had a nice idea and udev 077
automatically picks up the tools there, if RUN="firmware.sh" is given.

> 02-no-sepol.patch
>     The libsepol dependency seems to only exist on RedHat, with the
>     versions of the SELinux libraries we have in Ubuntu, there wasn't
>     any need for it.  Removing it saved us from having to security audit
>     libsepol as part of our main promotion procedure.

I'm waiting for an answer from Harald, Red Hat added this recently and
it may be needed with a newer version of selinux, don't know.

> 10-udev-conf.patch
>     We've given up trying to support people who want their udev_root and
>     udev_rules to be in different places; with initramfs, changing this
>     would mean regenerating the initramfs as well.  We decided to just
>     drop mention of the two options as a safety catch against pedocide.

Funny patch. :)

> 40-udevplug.patch
>     This adds an extra tool to udev called "udevplug", it's basically a
>     binary that handles tickling uevents and waiting for udevd to finish
>     processing them.  The command-line options let you choose exactly
>     what to tickle (or just everything), and do things like filter by
>     sysfs attributes.  (manpage included)

That's a nice tool. We will probably want such a thing in the tree, but
I want to wait until early next year, when we passed a lot of testing
with the current udev and really know what we need. Changing stuff in
the tree that is bootup relevant is not too funny for the guys who are
already have enough trouble catching up all the time. :)

I expect we want a way to specify for what kind of events or what device
nodes we want to wait to appear. Think of a SCSI controller that scans
a lot of buses during bootup needs a lot of time to do this but there is
not a single disk connected. Udevplug (like the simple initscripts
others use too) will delay the bootup process, even when all requirements
of the fstab are already fulfilled. We will see, what we really need here.
I'll stick with the shell scripts for now and we can come up with something
next year to put in the tree.

> 50-result-whitespace.patch
>     In a few places udev calls the replace_untrusted_chars() function on
>     things like program output; it treats \t, \r, \n, and other
>     whitespace characters (other than space itself) as illegal and
>     replaces them with an underscore.  This patch slightly alters that
>     behaviour, it leaves them as untrusted, but instead replaces those
>     of whitespace-ilk with an ordinary space, instead of an underscore. 
>     We use this because various helpers output a newline-separated list
>     of modules, and we wanted to pass that $result straight to modprobe.

Yes, I see, may make sense at some places as a separate function. What are
the tools you call and this is useful?

> 55-run-program.patch
>     This reduces the severity of the "exec of program failed" error IF
>     the reason the program couldn't be run was because it didn't exist
>     yet.  With /dev/.udev/failed, helpers not existing yet isn't
>     serious, it just means they need to be retried later and there's no
>     point screaming too loudly about it.

Yeah, I'm still unsure if the used tool should be required to be in the
rootfs or not. But it sounds like a sane default, if we don't require
this.

For the higher level things HAL is the approproate place to do device
setup anyway. That's the reason I ignored all the map conversion things,
cause digital cameras, scanners and such things belong to HAL these days
and not in udev rules.

> 60-firmware-hunt.patch
>     This modifies the firmware_helper extra to also look in
>     /lib/firmware/$KERNEL_VERSION which is where we put firmware that
>     comes with our kernel images.

Hmm, I'm no longer sure that the C programs for something that is
usually 20 lines of shell long and called 3 times at bootup make sense.
For the firmware case I always wanted to add some handling for missing
firmware, but even for this we would not need a C program. Hmm...

> 80-extras-dvb_device_name.patch
>     This adds a dvb_device_name helper that's pretty much equivalent to
>     the shell code passed around between the distros, just rather faster
>     and usable in busybox environments.  As with all our extras,
>     includes a manpage.

Hmm, why isn't the simple shell command in the RUN key not working in
busybox?

> 80-extras-ide_media.patch
>     Adds an ide_media helper that looks up the media type under /proc,
>     again somewhat similar to the shell code but this also will wait for
>     the node to appear under /proc, avoiding a race condition.

I've submitted a patch that adds MODALIAS for autoloading of IDE
modules.

> 80-extras-pnp_modules.patch
>     Another binary helper replacing shell code, outputs a list of
>     module aliases for a pnp device.

Hmm, again, do we want this as a C program?

> 80-extras-storage_enum.patch
>     An odd one, we use this in the installer to make the
>     devfs-like /dev/discs, /dev/cdroms and /dev/floppy directories which
>     the debian-installer we use still requires.  We didn't use the
>     existing devfs scripts because they don't cope well with everything
>     getting plugged at once, this is reasonably safe against that and
>     ensures that each gets a unique number.

Yeah, you should better get rid of _any_ simple enumeration now on a
system where devices can come and go any time and no order is guaranteed.
Such an approach will cause much more trouble than it solves. :)

> 80-extras-usb_device_name.patch
>     Back to the binary helpers again, this one is for the usb_device
>     subsystem and again just replaces equivalent shell code other
>     distros use.

Oh, seems you don't like the weird RUN rules that call a shell one
liner. :)

> 80-extras-vio_type.patch
>     Binary helper to look up the type of a vio device under /proc, and
>     like ide_media wait for the node to appear to avoid races.

Is this needed, even as we have MODALIAS for vio now?



Btw: I use udevd in initramfs now too and udev and udevstart are no
longer needed at all. You know, I didn't like to start the daemon there
in the first place, but killing udevd before leaving initramfs, after
the rootfs is mounted, works nice and seems like a nice way to do it.

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