* [Buildroot] Discussing libudev, was: Re: [PATCH v6 09/32] mesa3d: dri2 does not need udev support
@ 2014-05-12 19:55 Bernd Kuhls
2014-05-12 20:53 ` Yann E. MORIN
2014-05-12 21:02 ` Thomas Petazzoni
0 siblings, 2 replies; 6+ messages in thread
From: Bernd Kuhls @ 2014-05-12 19:55 UTC (permalink / raw)
To: buildroot
Bernd Kuhls <bernd.kuhls@t-online.de> wrote in
news:1399716164-6452-10-git-send-email-bernd.kuhls at t-online.de:
> http://cgit.freedesktop.org/mesa/mesa/commit/configure.ac?id=b959fd967493
> 8e127a34d42d34b903e3a9ae7ad9 "The loader infrastructure for everything
> but DRI2 requires that udev be present"
>
> Check for udev only for dri3.
> Patch sent upstream:
> https://bugs.freedesktop.org/show_bug.cgi?id=75212#c5
Hi,
I would like to discuss feedback I received for my patch to remove udev as
a requirement for mesa dri2 support. Before going into details I would like
to explain the system where I am using xbmc:
The distro (www.fli4l.de) uses buildroot to compile its binary files and
the kernel. As an user-provided package for fli4l I am building xbmc &
tvheadend here, so I am not in a position to have a free design choice
while using fli4l, which I want to do.
Quoted are some important configuration options of fli4l:
buildroot .config
BR2_i386=y
BR2_TOOLCHAIN_USES_UCLIBC=y
BR2_TOOLCHAIN_BUILDROOT=y
BR2_ROOTFS_DEVICE_CREATION_STATIC=y
busybox .config
CONFIG_MDEV=y
Now the feedback on the mesa3d bug tracker:
https://bugs.freedesktop.org/show_bug.cgi?id=75212#c6
Emil Velikov wrote:
--- snip
udev != libudev. The latter can be used without the presence of the former
as it is a selection of helper functions that helps abstract dev
manipulations.
AFAICS you have a couple options here - install libudev or keep a bunch of
local patches. I would encourage you go with the former.
--- snap
This was an interesting piece of information for me because I am patching
xbmc to remove its libudev dependency in the cec-adapter detection part.
While trying to setup Emil?s suggestion I created a libudev package which
was successfully linked by libcec and its binary cec-client to detect my
cec adapter so I guess Emil?s idea could really work.
I have yet to do more testing but reading through the udev/systemd/eudev
discussion of the last months here I would like to ask for feedback already
at this early stage whether a seperate libudev package is useful for the
broader public.
Regards, Bernd
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Discussing libudev, was: Re: [PATCH v6 09/32] mesa3d: dri2 does not need udev support
2014-05-12 19:55 [Buildroot] Discussing libudev, was: Re: [PATCH v6 09/32] mesa3d: dri2 does not need udev support Bernd Kuhls
@ 2014-05-12 20:53 ` Yann E. MORIN
2014-05-12 20:59 ` Bernd Kuhls
2014-05-12 21:02 ` Thomas Petazzoni
1 sibling, 1 reply; 6+ messages in thread
From: Yann E. MORIN @ 2014-05-12 20:53 UTC (permalink / raw)
To: buildroot
Bernd, All,
On 2014-05-12 21:55 +0200, Bernd Kuhls spake thusly:
> Emil Velikov wrote:
> --- snip
> udev != libudev. The latter can be used without the presence of the former
> as it is a selection of helper functions that helps abstract dev
> manipulations.
>
> AFAICS you have a couple options here - install libudev or keep a bunch of
> local patches. I would encourage you go with the former.
> --- snap
>
> This was an interesting piece of information for me because I am patching
> xbmc to remove its libudev dependency in the cec-adapter detection part.
> While trying to setup Emil?s suggestion I created a libudev package which
> was successfully linked by libcec and its binary cec-client to detect my
> cec adapter so I guess Emil?s idea could really work.
>
> I have yet to do more testing but reading through the udev/systemd/eudev
> discussion of the last months here I would like to ask for feedback already
> at this early stage whether a seperate libudev package is useful for the
> broader public.
Short answer: yes.
Loang answer: yes, it would be interesting to the broader public. :-)
Now, this should be well integrated with the existing udev providers.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| 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. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Discussing libudev, was: Re: [PATCH v6 09/32] mesa3d: dri2 does not need udev support
2014-05-12 20:53 ` Yann E. MORIN
@ 2014-05-12 20:59 ` Bernd Kuhls
0 siblings, 0 replies; 6+ messages in thread
From: Bernd Kuhls @ 2014-05-12 20:59 UTC (permalink / raw)
To: buildroot
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote in
news:20140512205324.GD3619 at free.fr:
> Now, this should be well integrated with the existing udev providers.
Hi,
reading the current code I am not sure what BR2_PACKAGE_HAS_UDEV means.
Currently only eudev and systemd select BR2_PACKAGE_HAS_UDEV, both are system
daemons while libudev being only a subset of them. I am not sure if libudev
should be a udev provider at all. My current patch includes
depends on !BR2_INIT_SYSTEMD
depends on !BR2_PACKAGE_EUDEV
Regards, Bernd
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Discussing libudev, was: Re: [PATCH v6 09/32] mesa3d: dri2 does not need udev support
2014-05-12 19:55 [Buildroot] Discussing libudev, was: Re: [PATCH v6 09/32] mesa3d: dri2 does not need udev support Bernd Kuhls
2014-05-12 20:53 ` Yann E. MORIN
@ 2014-05-12 21:02 ` Thomas Petazzoni
2014-05-12 21:12 ` Bernd Kuhls
1 sibling, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2014-05-12 21:02 UTC (permalink / raw)
To: buildroot
Dear Bernd Kuhls,
On Mon, 12 May 2014 21:55:37 +0200, Bernd Kuhls wrote:
> This was an interesting piece of information for me because I am patching
> xbmc to remove its libudev dependency in the cec-adapter detection part.
> While trying to setup Emil?s suggestion I created a libudev package which
> was successfully linked by libcec and its binary cec-client to detect my
> cec adapter so I guess Emil?s idea could really work.
>
> I have yet to do more testing but reading through the udev/systemd/eudev
> discussion of the last months here I would like to ask for feedback already
> at this early stage whether a seperate libudev package is useful for the
> broader public.
What would be the upstream source for this libudev package?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Discussing libudev, was: Re: [PATCH v6 09/32] mesa3d: dri2 does not need udev support
2014-05-12 21:02 ` Thomas Petazzoni
@ 2014-05-12 21:12 ` Bernd Kuhls
2014-05-12 21:50 ` Thomas Petazzoni
0 siblings, 1 reply; 6+ messages in thread
From: Bernd Kuhls @ 2014-05-12 21:12 UTC (permalink / raw)
To: buildroot
Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote
in news:20140512230238.76c7fb6b at free-electrons.com:
> What would be the upstream source for this libudev package?
Hi,
I copied the systemd package and build only the libudev part, short snippets
from my hacky package:
LIBUDEV_VERSION = 212
LIBUDEV_SITE = http://www.freedesktop.org/software/systemd/
LIBUDEV_SOURCE = systemd-$(LIBUDEV_VERSION).tar.xz
[...]
define LIBUDEV_BUILD_CMDS
$(TARGET_MAKE_ENV) $(MAKE1) -C $(@D) \
src/libudev/libudev.pc \
src/shared/errno-from-name.h \
src/shared/errno-to-name.h \
src/shared/af-from-name.h \
src/shared/af-to-name.h
$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) libudev.la
endef
followed by some LIBUDEV_INSTALL_STAGING/TARGET_CMDS file copying.
Regards, Bernd
^ permalink raw reply [flat|nested] 6+ messages in thread* [Buildroot] Discussing libudev, was: Re: [PATCH v6 09/32] mesa3d: dri2 does not need udev support
2014-05-12 21:12 ` Bernd Kuhls
@ 2014-05-12 21:50 ` Thomas Petazzoni
0 siblings, 0 replies; 6+ messages in thread
From: Thomas Petazzoni @ 2014-05-12 21:50 UTC (permalink / raw)
To: buildroot
Dear Bernd Kuhls,
On Mon, 12 May 2014 23:12:16 +0200, Bernd Kuhls wrote:
> I copied the systemd package and build only the libudev part, short snippets
> from my hacky package:
>
> LIBUDEV_VERSION = 212
> LIBUDEV_SITE = http://www.freedesktop.org/software/systemd/
> LIBUDEV_SOURCE = systemd-$(LIBUDEV_VERSION).tar.xz
> [...]
> define LIBUDEV_BUILD_CMDS
> $(TARGET_MAKE_ENV) $(MAKE1) -C $(@D) \
> src/libudev/libudev.pc \
> src/shared/errno-from-name.h \
> src/shared/errno-to-name.h \
> src/shared/af-from-name.h \
> src/shared/af-to-name.h
> $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) libudev.la
> endef
>
> followed by some LIBUDEV_INSTALL_STAGING/TARGET_CMDS file copying.
To be honest, this seems quite hacky to me, and fragile for future
version bumps.
If you run a complete monster software such as XBMC, I'm pretty sure
your platform can also afford to run either eudev or systemd, no?
In Buildroot, we've always tried to avoid going *against* upstream
decisions. The decision of upstream for udev is to bundle it as part of
systemd. 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.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-05-12 21:50 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-12 19:55 [Buildroot] Discussing libudev, was: Re: [PATCH v6 09/32] mesa3d: dri2 does not need udev support Bernd Kuhls
2014-05-12 20:53 ` Yann E. MORIN
2014-05-12 20:59 ` Bernd Kuhls
2014-05-12 21:02 ` Thomas Petazzoni
2014-05-12 21:12 ` Bernd Kuhls
2014-05-12 21:50 ` Thomas Petazzoni
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox