[gentoo-dev] About udev-145: new features / extras and kernel requirements

[gentoo-dev] About udev-145: new features / extras and kernel requirements

[Matthias Schwarzott]

Hi there!

The new udev-145 and newer have some new kernel requirements. How should the 
ebuild verify they are met?
Some possible ways:
1. Check config under /usr/src/linux
2. Check /proc/config.gz
3. Print message for user in pkg_postinst



Second point: udev-145 bundles a lot of new extras, but they can only be 
enabled/disabled all or nothing.

These extras are:
* udev-acl: Apply consolekit permissions to devices for users (audio, video, 
joysticks, scanner, cameras, ...)
* usb-db: Provide udev-rules with device names of pci and usb devices
* hid2hci: Special utility to fix resume of some hid devices
* keymap: Auto-configure model specific keys found on many laptops 
("brightness up", "next song", "www browser", or "suspend")
* modem-modeswitch: Switch modems that provide virtual cd-drive with drivers 
to modem mode
* gudev: glib/gobject support for libudev

This makes udev depend on these libs:
libacl, libglib2, libusb, usbutils, pciutils, gperf

Up to now I have just added use-flag "extras" to control these. But I suppose 
that udev-acl and maybe gudev is a hard requirement for newer hal or 
devicekit versions. And upstream thinks these should be enabled by default.

Are any of these extras considered harmful?

Regards
Matthias

Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements

[Arun Raghavan]

2009/8/30 Matthias Schwarzott <zzam@gentoo.org>:
> Hi there!
>
> The new udev-145 and newer have some new kernel requirements. How should the
> ebuild verify they are met?
> Some possible ways:
> 1. Check config under /usr/src/linux
> 2. Check /proc/config.gz
> 3. Print message for user in pkg_postinst

All of the above? Rationale being (1) is required to check against the
kernel you're supposedly using, (2) for the kernel you definitely are
using, and (3) to make sure people remember.

An alternative to (2) and (3), though is to add a check to the udev initscript.

Cheers,
-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements

[Nirbheek Chauhan]

On Sun, Aug 30, 2009 at 7:41 PM, Matthias Schwarzott<zzam@gentoo.org> wrote:
> Hi there!
>
> The new udev-145 and newer have some new kernel requirements. How should the
> ebuild verify they are met?
> Some possible ways:
> 1. Check config under /usr/src/linux
> 2. Check /proc/config.gz
> 3. Print message for user in pkg_postinst
>

ebuilds usually use linux-info.eclass for this, but that only checks
/usr/src/linux -- although checking /proc/config.gz *as well* would be
better. That change should be made in the eclass.

Personally, I would also add an ewarn into pkg_postinst to prevent
users from blundering into a broken system.

> Second point: udev-145 bundles a lot of new extras, but they can only be
> enabled/disabled all or nothing.
>

Eww. I suppose upstream is not open to making it a bit more granular?

> These extras are:
> * udev-acl: Apply consolekit permissions to devices for users (audio, video,
> joysticks, scanner, cameras, ...)

This looks very useful for desktop users. As long as it doesn't pull
in ConsoleKit itself, enabling this by default should not be a
problem.

> * usb-db: Provide udev-rules with device names of pci and usb devices

What are the consumers of this?

> * hid2hci: Special utility to fix resume of some hid devices

If the consumer of this is pm-suspend, pm-hibernate etc, I say enable
by default.

> * keymap: Auto-configure model specific keys found on many laptops
> ("brightness up", "next song", "www browser", or "suspend")

This should be enabled by default, especially since HAL is getting
deprecated, and everything using HAL for this stuff will have to turn
to udev (X, gnome, kde)

> * gudev: glib/gobject support for libudev
>

This is the interface almost everything is going to turn to with GNOME
2.28 (via DeviceKit-power and DeviceKit-disks in most cases). By the
time GNOME 2.30 and 3.0 are released, (theoretically) nothing will use
HAL.

I believe there are ongoing efforts to port X to use udev/gudev
instead of HAL, as well as KDE[1]

> This makes udev depend on these libs:
> libacl, libglib2, libusb, usbutils, pciutils, gperf
>
> Up to now I have just added use-flag "extras" to control these. But I suppose
> that udev-acl and maybe gudev is a hard requirement for newer hal or
> devicekit versions. And upstream thinks these should be enabled by default.

There are no "new" versions of HAL anymore (it's gone into maintenance
mode), but all current DeviceKit-{power,disks} versions *need* gudev.

In summation, I say hard-enable these:

acl, keymap, hid2hci

Put "gudev" under a USE-flag, enabled by +use, and put the rest under
"extras", not enabled by default.


1. http://fedoraproject.org/wiki/KDE_Programming_Wishlist
-- 
~Nirbheek Chauhan

GNOME+Mozilla Team, Gentoo

Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements

[Bruno]

On Sun, 30 August 2009 Matthias Schwarzott <zzam@gentoo.org> wrote:
> The new udev-145 and newer have some new kernel requirements. How
> should the ebuild verify they are met?
> Some possible ways:
> 1. Check config under /usr/src/linux

/usr/src/linux is not the best place to look at...

Checks should rather be done on first kernel config found in following
locations (checked in this order):
 - KBUILD_OUTPUT
 - KERNEL_DIR
 - /usr/src/linux, /proc/config.gz, /lib/modules/$(uname -r)/build/.config

Maybe just use linux-info eclass for the checks

> 2. Check /proc/config.gz

This should rather happen in init script, if possible do not check
on every boot but only when a "new" kernel is used (e.g. when uname
output changes)

> 3. Print message for user in pkg_postinst

This makes sense in any case.

> Second point: udev-145 bundles a lot of new extras, but they can only
> be enabled/disabled all or nothing.
> 
> These extras are:
> * udev-acl: Apply consolekit permissions to devices for users (audio,
> video, joysticks, scanner, cameras, ...)

Is this bound to consolekit or does it rather fall under 'acl' use-flag?
I guess this includes a kernel requirement (ACL support for tmpfs)

> * usb-db: Provide udev-rules with device names of pci and usb devices
> * hid2hci: Special utility to fix resume of some hid devices
> * keymap: Auto-configure model specific keys found on many laptops 
> ("brightness up", "next song", "www browser", or "suspend")
> * modem-modeswitch: Switch modems that provide virtual cd-drive with
> drivers to modem mode
> * gudev: glib/gobject support for libudev

Is gudev just a binding or is it more? If it's just a binding it may
be nice to have it tied to a use-flag.

> This makes udev depend on these libs:
> libacl, libglib2, libusb, usbutils, pciutils, gperf

Bruno

[gentoo-dev] Re: About udev-145: new features / extras and kernel requirements

[Duncan]

Arun Raghavan posted on Sun, 30 Aug 2009 19:54:47 +0530 as excerpted:

> 2009/8/30 Matthias Schwarzott <zzam@gentoo.org>:
>> Hi there!
>>
>> The new udev-145 and newer have some new kernel requirements. How
>> should the ebuild verify they are met?
>> Some possible ways:
>> 1. Check config under /usr/src/linux
>> 2. Check /proc/config.gz
>> 3. Print message for user in pkg_postinst
> 
> All of the above? Rationale being (1) is required to check against the
> kernel you're supposedly using, (2) for the kernel you definitely are
> using, and (3) to make sure people remember.

Indeed, all of the above, but not requiring the first two only giving 
their status in #3.

Some people don't have the kernel option enabling /proc/config.gz turned 
on, so #2 isn't reliable, and #1, /usr/src/linux, could point who /knows/ 
where, maybe something current, maybe not.  (Here, it points at my local 
kernel git repo... which may or may not correspond to the currently 
running kernel, tho it's usually reasonably close, and it's usually 
within a few days of upstream unless I'm git bisecting some bug.)

Thus, neither of the first two is reliable, but checking them and putting 
the status in #3 should be helpful.

Another alternative, ultimately safer: add another option, and require 
that at least one of the three pass:

1-2 as they are.

3. Check UDEV_ASSUME_KERNEL_OPTS in the environment (could be set in 
make.conf for portage and compatible PMs).

Then in the message corresponding to the original #3 except presumably in 
unpack or prepare, report status as a reminder, and die if none of the 
above tests pass.  #3, the env var, would allow users to override without 
hacking the ebuild itself, if for some reason they decided they needed 
to.  If it's the only one that passes, ewarn/eerror to the effect 
"Relying on UDEV_ASSUME_KERNEL_OPTS override.  If it breaks, you get to 
keep the pieces!"

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements

[William Hubbs]

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

On Sun, Aug 30, 2009 at 08:16:47PM +0530, Nirbheek Chauhan wrote:
> On Sun, Aug 30, 2009 at 7:41 PM, Matthias Schwarzott<zzam@gentoo.org> wrote:
> > Hi there!
> >
> > The new udev-145 and newer have some new kernel requirements. How should the
> > ebuild verify they are met?
> > Some possible ways:
> > 1. Check config under /usr/src/linux
> > 2. Check /proc/config.gz
> > 3. Print message for user in pkg_postinst
> >
> 
> ebuilds usually use linux-info.eclass for this, but that only checks
> /usr/src/linux -- although checking /proc/config.gz *as well* would be
> better. That change should be made in the eclass.
 
 I agree here.  The eclass should check /proc/config.gz.
 Also, another reason to use the eclass is it respects KBUILD_OUTPUT if
 it is set.

If /proc/config.gz is the first thing we check, I don't think we need to
bother at all with checking .config since we know the setup of the
running kernel.  What does everyone think?

-- 
William Hubbs
gentoo accessibility team lead
williamh@gentoo.org

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements

[Mike Auty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

William Hubbs wrote:
>  I agree here.  The eclass should check /proc/config.gz.
>  Also, another reason to use the eclass is it respects KBUILD_OUTPUT if
>  it is set.

- From the indenting I can't tell if you wrote this or not, however, we
need to differentiate between running and build time environments.
Ebuilding is a build-time process.  That means the running kernel isn't
 important, since we're not running udev, we're just building it.  When
the machine is next rebooted, we could be using a completely different
kernel (or even one that hasn't been installed yet).  We should only
care about the build-time kernel when we're building, which the user has
to specify (which they do implicitly by using /usr/src/linux, or
explicitly by using KBUILD_OUTPUT or another environment variable).

If you go by the running kernel, then you're requiring people to reboot
their computers before they can build software for a kernel they're
about to run.  That simply ensures downtime on a potentially critical
service, and moreover it's an unnecessary constraint.  The existing udev
can continue running until the machine is rebooted without a problem.
When the machine restarts *any* kernel could be chosen, and build time
checks won't help prevent a bad kernel from being booted.  That's why
the linux-info.eclass does the checks it currently does, and *doesn't*
check /proc/config.gz and *doesn't* check /$(uname -r)/ directories...

So in summary:

* Check the running kernel if you're about to run.
* Check the kernel the user's chosen to build against if you're about to
build, using linux-info.

If the ebuild restarts the service (causing a reread off disk, rather
than just a reread of the rules) then fine, use the check to disable the
restart, and/or warn the user, but don't stop the user from building the
software.

You can also put a check in the init.d, but it just creates the
possibility that the check is wrong when udev could potentially still
run.  I'd simply try running udev and check if it exits or errors as
expected.  Only if it doesn't exit or error when it should would I add
checks to the initscript, and even then I'd suggest fixing the code to
error correctly, over adding our own checks in...

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkqapk4ACgkQu7rWomwgFXqDbACgtYdXtmlgo6JA49o9on111XPE
Y/QAnROtzEhAUg0ML9J+nd6rTvKfZeFz
=pbOj
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements

[Robin H. Johnson]

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

On Sun, Aug 30, 2009 at 05:05:05PM +0200, Bruno wrote:
> Is this bound to consolekit or does it rather fall under 'acl' use-flag?
> I guess this includes a kernel requirement (ACL support for tmpfs)
Yes, this would imply CONFIG_TMPFS_POSIX_ACL to actually be used.

> > * usb-db: Provide udev-rules with device names of pci and usb devices
> > * hid2hci: Special utility to fix resume of some hid devices
> > * keymap: Auto-configure model specific keys found on many laptops 
> > ("brightness up", "next song", "www browser", or "suspend")
> > * modem-modeswitch: Switch modems that provide virtual cd-drive with
> > drivers to modem mode
> > * gudev: glib/gobject support for libudev
> Is gudev just a binding or is it more? If it's just a binding it may
> be nice to have it tied to a use-flag.
USE=glib has a couple of packages already, and this looks like another
good one for it.

> > This makes udev depend on these libs:
> > libacl, libglib2, libusb, usbutils, pciutils, gperf
dev-util/gperf is not a lib. It's one of those packages that should
almost NEVER be seen in RDEPEND even, as it generates C/C++ during build
time only.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]

Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements

[Lars Wendler]

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

> In summation, I say hard-enable these:
>
> acl
>

Please don't do this. It would force installation of sys-apps/acl to any user 
which I think is not desired by everybody. I'd rather like to see this being 
enabled by either the acl or the consolekit USE flag.

Lars Wendler (Polynomial-C)
Gentoo Staffer and bug-wrangler

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

Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements

[Jeremy Olexa]

On Sun, Aug 30, 2009 at 10:45 AM, William Hubbs<williamh@gentoo.org> wrote:
> On Sun, Aug 30, 2009 at 08:16:47PM +0530, Nirbheek Chauhan wrote:
>> On Sun, Aug 30, 2009 at 7:41 PM, Matthias Schwarzott<zzam@gentoo.org> wrote:
>> > Hi there!
>> >
>> > The new udev-145 and newer have some new kernel requirements. How should the
>> > ebuild verify they are met?
>> > Some possible ways:
>> > 1. Check config under /usr/src/linux
>> > 2. Check /proc/config.gz
>> > 3. Print message for user in pkg_postinst
>> >
>>
>> ebuilds usually use linux-info.eclass for this, but that only checks
>> /usr/src/linux -- although checking /proc/config.gz *as well* would be
>> better. That change should be made in the eclass.
>
>  I agree here.  The eclass should check /proc/config.gz.
>  Also, another reason to use the eclass is it respects KBUILD_OUTPUT if
>  it is set.
>
> If /proc/config.gz is the first thing we check, I don't think we need to
> bother at all with checking .config since we know the setup of the
> running kernel.  What does everyone think?

William, not picking on you, just replying in general.

People that suggest to only check /proc/config.gz only are pretty
crazy considering that file is a tunable option. What if the user has
CONFIG_IKCONFIG_PROC=n?? The ebuild fails?! Of course, I haven't seen
any code yet, so maybe people are just suggesting to check config.gz
if is exists, then proceed via other means? ;-)

-Jeremy

Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements

[Mart Raudsepp]

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

On Sun, 2009-08-30 at 16:11 +0200, Matthias Schwarzott wrote:
> Hi there!

A late hello,

> Second point: udev-145 bundles a lot of new extras, but they can only be 
> enabled/disabled all or nothing.
> 
> These extras are:
> * udev-acl: Apply consolekit permissions to devices for users (audio, video, 
> joysticks, scanner, cameras, ...)
> * usb-db: Provide udev-rules with device names of pci and usb devices
> * hid2hci: Special utility to fix resume of some hid devices
> * keymap: Auto-configure model specific keys found on many laptops 
> ("brightness up", "next song", "www browser", or "suspend")
> * modem-modeswitch: Switch modems that provide virtual cd-drive with drivers 
> to modem mode

I think the thread hasn't seen an answer to the question of when these
are actually used or useful, as asked in another subthread as well.

> * gudev: glib/gobject support for libudev

Would it be possible to have this in a separate package? Of course then
with a temporary compatibility PDEPEND on it with udev[extras] until
packages needing gudev migrate over.
And what of the above listed other things besides core udev does gudev
require or potentially use?

> This makes udev depend on these libs:
> libacl, libglib2, libusb, usbutils, pciutils, gperf
> 
> Up to now I have just added use-flag "extras" to control these. But I suppose 
> that udev-acl and maybe gudev is a hard requirement for newer hal or 
> devicekit versions. And upstream thinks these should be enabled by default.
> 
> Are any of these extras considered harmful?

On some non-desktop systems perhaps, yes.

-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

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

Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements

[Daniel Drake]

Matthias Schwarzott wrote:
> Up to now I have just added use-flag "extras" to control these. But I suppose 
> that udev-acl and maybe gudev is a hard requirement for newer hal or 
> devicekit versions. And upstream thinks these should be enabled by default.

I've been playing with Fedora lately and they split it in 3: udev, 
libudev, libgudev.

You will find that some apps will start requiring libgudev 
unconditionally. For example, the upcoming NetworkManager 0.8.

Daniel

Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements

[Matthias Schwarzott]

On Montag, 9. November 2009, Mart Raudsepp wrote:
> On Sun, 2009-08-30 at 16:11 +0200, Matthias Schwarzott wrote:
> > Hi there!
>
> A late hello,
>
> > Second point: udev-145 bundles a lot of new extras, but they can only be
> > enabled/disabled all or nothing.
> >
> > These extras are:
> > * udev-acl: Apply consolekit permissions to devices for users (audio,
> > video, joysticks, scanner, cameras, ...)
> > * usb-db: Provide udev-rules with device names of pci and usb devices
> > * hid2hci: Special utility to fix resume of some hid devices
> > * keymap: Auto-configure model specific keys found on many laptops
> > ("brightness up", "next song", "www browser", or "suspend")
> > * modem-modeswitch: Switch modems that provide virtual cd-drive with
> > drivers to modem mode
>
> I think the thread hasn't seen an answer to the question of when these
> are actually used or useful, as asked in another subthread as well.
>
> > * gudev: glib/gobject support for libudev
>
> Would it be possible to have this in a separate package? Of course then
> with a temporary compatibility PDEPEND on it with udev[extras] until
> packages needing gudev migrate over.

The question is: DO we really need to split udev that upstream bundled into 
one tarball?


> And what of the above listed other things besides core udev does gudev
> require or potentially use?

To be answered by someone else, I do not need these yet.

Matthias