Skip to contentSkip to conversation

WIP: libudev: New package

PATCH New Bernd Kuhls 3 participants 7 messages May 26, 2014 – Jun 11, 2014

lore
Share & tools
lore

Bernd Kuhls

author
#0 lore raw

cover WIP: libudev: New package

Hi,

in reply to Thomas[1]: "Gentoo has decided to provide a maintained fork of udev as eudev, so we support both options. But I definitely wouldn't want to support things that are completely Buildroot-specific."

for my first libudev package, based on systemd sourcecode, aimed at platforms having BR2_ROOTFS_DEVICE_CREATION_STATIC=y I picked up his hint. This libudev package is now based on eudev sourcecode in a less hackish way. Even the Gentoo ebuild[2] partly uses "$(MAKE) -C $(@D)/src/libudev".

This package install these files to $(STAGING_DIR):
./usr/include/libudev.h ./usr/lib/libudev.la
./usr/lib/libudev.a ./usr/lib/pkgconfig/libudev.pc ./usr/lib/libudev.so -> ../../lib/libudev.so.1.4.0 ./lib/libudev.so.1.4.0
./lib/libudev.so.1 -> libudev.so.1.4.0

I am planning to merge this libudev package and the existing eudev package, but I am not sure what is the best way. This is something I would like to discuss based on this patch. My idea is to compile libudev using eudev.mk for platforms without a udev daemon. Therefore this patch should not be committed as is.

Btw, I am using this package successfully to provide udev device detection support to libcec, which in turn is used by xbmc to find my cec adapter without hacking xbmc, which I did in the past ;)

Regards, Bernd

[1] http://article.gmane.org/gmane.comp.lib.uclibc.buildroot/83953
[2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/eudev/eudev-1.6.ebuild

Signature · 1 line
1.7.10.4
author
#1 lore raw

PATCH 1/1 WIP: libudev: New package

Signed-off-by Bernd Kuhls <[email protected]>
---
 package/Config.in          |    1 +
 package/libudev/Config.in  |    9 +++++++++
 package/libudev/libudev.mk |   43 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 53 insertions(+)
 create mode 100644 package/libudev/Config.in
 create mode 100644 package/libudev/libudev.mk
package/Config.in +1 -0
index 3bc8d24..14d632e 100644
@@ -631,6 +631,7 @@ source "package/libqmi/Config.in"
 source "package/libraw1394/Config.in"
 source "package/libserial/Config.in"
 source "package/libsoc/Config.in"
+source "package/libudev/Config.in"
 source "package/libusb/Config.in"
 source "package/libusb-compat/Config.in"
 source "package/libv4l/Config.in"
package/libudev/Config.in new file +9 -0
new file mode 100644
index 0000000..f3f1b59
@@ -0,0 +1,9 @@
+config BR2_PACKAGE_LIBUDEV
+	bool "libudev"
+	depends on !BR2_INIT_SYSTEMD
+	depends on !BR2_PACKAGE_EUDEV
+	help
+	  libudev provides a set of functions for accessing the udev database
+	  and querying sysfs.
+
+	  http://github.com/gentoo/eudev/
package/libudev/libudev.mk new file +43 -0

43 lines not on this page · raw message

Signature · 1 line
1.7.10.4
#2 lore raw

PATCH 1/1 WIP: libudev: New package

Bernd, All,

On 2014-05-26 20:31 +0200, Bernd Kuhls spake thusly:

Quoted 2 lines
Signed-off-by Bernd Kuhls <[email protected]>

[--SNIP--]

package/libudev/Config.in line 4

Quoted 10 lines
package/libudev/Config.in new file +4 -0
new file mode 100644
index 0000000..f3f1b59
@@ -0,0 +1,9 @@
+config BR2_PACKAGE_LIBUDEV
+	bool "libudev"
+	depends on !BR2_INIT_SYSTEMD
+	depends on !BR2_PACKAGE_EUDEV

Maybe replace those two 'depends on' with simply:

depends on !BR2_PACKAGE_HAS_UDEV

[--SNIP--]

Quoted 6 lines
package/libudev/libudev.mk new file +0 -0
new file mode 100644
index 0000000..9dfd214

package/libudev/libudev.mk line 10

Quoted 10 lines
package/libudev/libudev.mk new file +10 -0
@@ -0,0 +1,43 @@
+################################################################################
+#
+# libudev
+#
+################################################################################
+
+LIBUDEV_VERSION = v1.6
+LIBUDEV_SITE = $(call github,gentoo,eudev,$(LIBUDEV_VERSION))
+LIBUDEV_LICENSE = GPLv2+ (programs), LGPLv2.1+ (libraries)
+LIBUDEV_LICENSE_FILES = COPYING

I was wondering if we could somehow keep this in sync with the eudev package, to avoid duplicating the versions, so we can bump both in a single change.

package/libudev/libudev.mk line 21

Quoted 11 lines
package/libudev/libudev.mk new file +11 -0
+LIBUDEV_INSTALL_STAGING = YES
+LIBUDEV_AUTORECONF = YES
+
+LIBUDEV_DEPENDENCIES = host-pkgconf
+
+LIBUDEV_CONF_OPT += \
+	--disable-manpages \
+	--with-rootlibdir=/lib \
+	--libexecdir=/lib \
+	--with-firmware-path=/lib/firmware \
+	--disable-introspection \

Would it be possible to build the library with introspection? That would require adding gobject-introspection, though... But I'm not too fluent in udev itself, so I won;t complain! ;-)

Quoted 12 lines
package/libudev/libudev.mk new file +12 -0
+	--disable-keymap \
+	--disable-libkmod \
+	--disable-modules \
+	--disable-selinux \
+	--disable-rule-generator \
+	--disable-gtk-doc \
+	--disable-gudev \
+	--enable-split-usr
+
+define LIBUDEV_BUILD_CMDS
+	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/src/libudev
+endef

package/libudev/libudev.mk line 43

Quoted 10 lines
package/libudev/libudev.mk new file +10 -0
+
+define LIBUDEV_INSTALL_STAGING_CMDS
+	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/src/libudev DESTDIR=$(STAGING_DIR) install
+endef
+
+define LIBUDEV_INSTALL_TARGET_CMDS
+	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/src/libudev DESTDIR=$(TARGET_DIR) install
+endef
+
+$(eval $(autotools-package))

Otherwise, looks good to me.

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
#3 lore raw

PATCH 1/1 WIP: libudev: New package

Hi,

"Yann E. MORIN" <[email protected]> wrote in news:20140526211909.GA13529 at free.fr:

Quoted 6 lines

package/libudev/Config.in line 4

Quoted 2 lines
package/libudev/Config.in new file +2 -0
+     depends on !BR2_INIT_SYSTEMD
+     depends on !BR2_PACKAGE_EUDEV

Maybe replace those two 'depends on' with simply:

depends on !BR2_PACKAGE_HAS_UDEV

I think we need to distinguish between the need for a daemon managing /dev and libudev. Currently a lot of packages depend on BR2_PACKAGE_HAS_UDEV although libudev should be enough for them. For libcec & xbmc I can confirm this for sure, I suppose this is also valid for mesa3d, maybe others.

Libcec, for example, needs a patch like this for configure.ac though:

- REQUIRES="$REQUIRES udev"
+ REQUIRES="$REQUIRES libudev"

As several packages (systemd, eudev, libudev) can provide libudev we should add a new provider BR2_PACKAGE_HAS_LIBUDEV and let xbmc, libcec, mesa, ... depend on it instead of BR2_PACKAGE_HAS_UDEV. With this change in place adding your suggestion makes sense.

What do you think?

Quoted 8 lines

package/libudev/libudev.mk line 10

Quoted 4 lines
package/libudev/libudev.mk new file +4 -0
+LIBUDEV_VERSION = v1.6
+LIBUDEV_SITE = $(call github,gentoo,eudev,$(LIBUDEV_VERSION))
+LIBUDEV_LICENSE = GPLv2+ (programs), LGPLv2.1+ (libraries)
+LIBUDEV_LICENSE_FILES = COPYING

I was wondering if we could somehow keep this in sync with the eudev package, to avoid duplicating the versions, so we can bump both in a single change.

My plan is to merge libudev to the eudev package, a bump patch for eudev v1.6 was already posted by sagaert.

Quoted 5 lines
Quoted 1 line

+ --disable-introspection \

Would it be possible to build the library with introspection? That would require adding gobject-introspection, though... But I'm not too fluent in udev itself, so I won;t complain! ;-)

I?ll have a look.

Regards, Bernd

#4 lore raw

PATCH 1/1 WIP: libudev: New package

Bernd, All,

On 2014-05-27 06:46 +0200, Bernd Kuhls spake thusly:

Quoted 6 lines

"Yann E. MORIN" <[email protected]> wrote in news:20140526211909.GA13529 at free.fr:

Quoted 3 lines
Quoted 2 lines
package/libudev/Config.in new file +2 -0
+     depends on !BR2_INIT_SYSTEMD
+     depends on !BR2_PACKAGE_EUDEV
Quoted 8 lines
Quoted 3 lines

Maybe replace those two 'depends on' with simply:

depends on !BR2_PACKAGE_HAS_UDEV

I think we need to distinguish between the need for a daemon managing /dev and libudev. Currently a lot of packages depend on BR2_PACKAGE_HAS_UDEV although libudev should be enough for them. For libcec & xbmc I can confirm this for sure, I suppose this is also valid for mesa3d, maybe others.

Well, the concept behind this single "depends on !HAS_UDEV" is that udev-providing packages surely install a libudev.so, no?

Thus, there is no point in building libudev if we already have a udev-providing package. Unless I'm misled.

Quoted 11 lines

Libcec, for example, needs a patch like this for configure.ac though:

(quoted diff) +1 -1
-    REQUIRES="$REQUIRES udev"
+    REQUIRES="$REQUIRES libudev"

As several packages (systemd, eudev, libudev) can provide libudev we should add a new provider BR2_PACKAGE_HAS_LIBUDEV and let xbmc, libcec, mesa, ... depend on it instead of BR2_PACKAGE_HAS_UDEV. With this change in place adding your suggestion makes sense.

What do you think?

I'm not sure about adding a new virtual package 'HAS_LIBUDEV'... Further thinking is needed...

Quoted 11 lines
Quoted 8 lines

package/libudev/libudev.mk line 10

Quoted 4 lines
package/libudev/libudev.mk new file +4 -0
+LIBUDEV_VERSION = v1.6
+LIBUDEV_SITE = $(call github,gentoo,eudev,$(LIBUDEV_VERSION))
+LIBUDEV_LICENSE = GPLv2+ (programs), LGPLv2.1+ (libraries)
+LIBUDEV_LICENSE_FILES = COPYING

I was wondering if we could somehow keep this in sync with the eudev package, to avoid duplicating the versions, so we can bump both in a single change.

My plan is to merge libudev to the eudev package, a bump patch for eudev v1.6 was already posted by sagaert.

Yes, that would be nice.

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

+ --disable-introspection \

Would it be possible to build the library with introspection? That would require adding gobject-introspection, though... But I'm not too fluent in udev itself, so I won;t complain! ;-)

I?ll have a look.

Just a random thought, no worry! ;-)

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
author
#5 lore raw

PATCH 1/1 WIP: libudev: New package

"Yann E. MORIN" <[email protected]> wrote in news:20140527171915.GB3503 at free.fr:

Quoted 9 lines

Bernd, All,

On 2014-05-27 06:46 +0200, Bernd Kuhls spake thusly:

Quoted 5 lines

I think we need to distinguish between the need for a daemon managing /dev and libudev. Currently a lot of packages depend on BR2_PACKAGE_HAS_UDEV although libudev should be enough for them. For libcec & xbmc I can confirm this for sure, I suppose this is also valid for mesa3d, maybe others.

Quoted 5 lines

Well, the concept behind this single "depends on !HAS_UDEV" is that udev-providing packages surely install a libudev.so, no?

Thus, there is no point in building libudev if we already have a udev-providing package. Unless I'm misled.

Hi,

ok, so we stick to "depends on BR2_PACKAGE_HAS_UDEV", even if the eudev package only builds libudev, this is something I am working on atm. Mesa3d already links to this libudev, I have yet to conduct runtime testing.

My current approach is to create a new option BR2_PACKAGE_EUDEV_DAEMON, default y for backward-compatability, which builds the eudev package like it is possible now. Having this option disabled will only build libudev. I am not sure if this is the right way Kconfig-wise, any suggestions?

Also I would like to propose changing the comment "xy needs udev /dev management" to something more correct because libudev does not manage /dev, it only reads it.

If a package really needs an udev daemon its dependency should then be changed.

Regards, Bernd

#6 lore raw

PATCH 1/1 WIP: libudev: New package

Bernd, All,

On 2014-06-11 18:28 +0200, Bernd Kuhls spake thusly:

Quoted 15 lines

"Yann E. MORIN" <[email protected]> wrote in news:20140527171915.GB3503 at free.fr:

Quoted 12 lines

Bernd, All,

On 2014-05-27 06:46 +0200, Bernd Kuhls spake thusly:

Quoted 5 lines

I think we need to distinguish between the need for a daemon managing /dev and libudev. Currently a lot of packages depend on BR2_PACKAGE_HAS_UDEV although libudev should be enough for them. For libcec & xbmc I can confirm this for sure, I suppose this is also valid for mesa3d, maybe others.

Well, the concept behind this single "depends on !HAS_UDEV" is that udev-providing packages surely install a libudev.so, no?

Quoted 6 lines
Quoted 2 lines

Thus, there is no point in building libudev if we already have a udev-providing package. Unless I'm misled.

Hi,

ok, so we stick to "depends on BR2_PACKAGE_HAS_UDEV", even if the eudev

No, it's the opposite: depends on ! BR2_PACKAGE_HAS_UDEV

I.e., do not present libudev in the menuconfig if we already have either systemd or eudev.

But since we want your libudev package to be merged with the eudev package, we'll have to come with some tricks...

Quoted 7 lines

package only builds libudev, this is something I am working on atm. Mesa3d already links to this libudev, I have yet to conduct runtime testing.

My current approach is to create a new option BR2_PACKAGE_EUDEV_DAEMON, default y for backward-compatability, which builds the eudev package like it is possible now. Having this option disabled will only build libudev. I am not sure if this is the right way Kconfig-wise, any suggestions?

I'll have a look at it tonight (UTC+2).

Quoted 6 lines

Also I would like to propose changing the comment "xy needs udev /dev management" to something more correct because libudev does not manage /dev, it only reads it.

If a package really needs an udev daemon its dependency should then be changed.

Not sure. I think we should keep _HAS_UDEV as-is, to mean "has a udev daemon", and had a new virtual package _HAS_LIBUDEV which means "has a libudev, but maybe not a daemon", and have the virtual package udev be a provider of libudev.

I'll see what I can come up with.

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'