Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
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
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
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
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: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
On Sun, Aug 30, 2009 at 10:45 AM, William Hubbs 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 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
> 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
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 : robb...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpH1PMbWGvYu.pgp
Description: PGP signature
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
-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
On Sun, Aug 30, 2009 at 08:16:47PM +0530, Nirbheek Chauhan wrote: > On Sun, Aug 30, 2009 at 7:41 PM, Matthias Schwarzott 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 willi...@gentoo.org pgpdLEnuLNcR5.pgp Description: PGP signature
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
On Sun, 30 August 2009 Matthias Schwarzott 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
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
On Sun, Aug 30, 2009 at 7:41 PM, Matthias Schwarzott 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
2009/8/30 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 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)
[gentoo-dev] About udev-145: new features / extras and kernel requirements
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
