Re: [systemd-devel] F19 network device naming
On 10/23/2013 07:02 PM, Nicholas Majeran wrote: I would expect to see enp65s0f0 and enp65s0f1, like the e1000e. Read the source luke [1]... JBG 1. http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] F19 network device naming
Thanks. I did read the comments in that source before sending a message to the mailing list -- but I am still unclear why the SolarFlare card doesn't behave like the e1000e, and adds a device to the end of the devname. > On Oct 24, 2013, at 2:56 AM, "Jóhann B. Guðmundsson" > wrote: > >> On 10/23/2013 07:02 PM, Nicholas Majeran wrote: >> I would expect to see enp65s0f0 and enp65s0f1, like the e1000e. > > Read the source luke [1]... > > JBG > > 1. > http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20 > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Can apps ship their own copy of libudev?
Hi, First time I post to the list, so please bear with me :) I'm a developer working on Qt. The Qt project just released a beta of the upcoming version 5.2, and to help people to test it we've been also releasing an installer with binaries for Linux that is supposed to work on a variety of distributions. One of the problems [1] we still have to fix is our libudev.so.0 dependency ... That is, we're building the packages on Ubuntu 11.10 and link against system libudev.so.0 , while some modern distributions are (solely) providing libudev.so.1. For some parts of Qt the libudev dependency is actually not that important , and we can disable it. However, for the QtSerialPort library I've been told libudev is crucial: It uses it to enumerate all available ports. So, to overcome this we've been thinking about building & shipping our own copy of libudev (renamed , or statically linked, to avoid clashes) ... Would you expect such a pristine version of libudev, compiled on distribution A , to work flawlessly on distribution B? What problems would you anticipate? Kind Regards Kai Koehne [1]: https://bugreports.qt-project.org/browse/QTBUG-34176 PS: Where can I vote for getting libudev into LSB ? :) -- Kai Köhne, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868 Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] F19 network device naming
On Wed, Oct 23, 2013 at 9:02 PM, Nicholas Majeran wrote: > I have recently installed Fedora 19 on a Dell R620. > I'm trying to grok the new device naming scheme put forth in systemd, but > the results are a bit confusing. > > This box has four onboard ports -- those are all correctly labelled as > eno[1-4]. > However, when I begin to add in PCIe cards, I don't see what I would expect. > > I've installed two PCIe cards: > one two-port Intel e1000e and one two port SolarFlare Performa card. > [root@sunelkvm6 ~]# ethtool -i enp65s0f0 > driver: sfc > version: 3.2 > firmware-version: 3.2.2.6124 > bus-info: :41:00.0 > supports-statistics: yes > supports-test: yes > supports-eeprom-access: no > supports-register-dump: yes > supports-priv-flags: no > [root@sunelkvm6 ~]# ethtool -i enp65s0f1d1 > driver: sfc > version: 3.2 > firmware-version: 3.2.2.6124 > bus-info: :41:00.1 > supports-statistics: yes > supports-test: yes > supports-eeprom-access: no > supports-register-dump: yes > supports-priv-flags: no > > I would expect to see enp65s0f0 and enp65s0f1, like the e1000e. Yeah, that would be right. I guess someone messed up the kernel driver and exports dev_id == 1 where it needs to be 0. dev_id in the kernel is supposed to count upwards for netdevs of the *same* device(pci) parent, not for netdevs from separate devices. You can check with: $ grep . /sys/class/net/*/dev_id Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can apps ship their own copy of libudev?
On Thu, Oct 24, 2013 at 2:15 PM, Koehne Kai wrote: > First time I post to the list, so please bear with me :) I'm a developer > working on Qt. The Qt project just released a beta of the upcoming version > 5.2, and to help people to test it we've been also releasing an installer > with binaries for Linux that is supposed to work on a variety of > distributions. > > One of the problems [1] we still have to fix is our libudev.so.0 dependency > ... That is, we're building the packages on Ubuntu 11.10 and link against > system libudev.so.0 , while some modern distributions are (solely) providing > libudev.so.1. For some parts of Qt the libudev dependency is actually not > that important , and we can disable it. However, for the QtSerialPort library > I've been told libudev is crucial: It uses it to enumerate all available > ports. > > So, to overcome this we've been thinking about building & shipping our own > copy of libudev (renamed , or statically linked, to avoid clashes) ... Would > you expect such a pristine version of libudev, compiled on distribution A , > to work flawlessly on distribution B? What problems would you anticipate? No, you cannot really ship your own libudev, it is coupled with the daemon. They speak a non-trivial wire protocol and write udev database files which are a private implementation only; they changed in the past, and might change at any time again. Libudev and udevd can only be used in the same version. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can apps ship their own copy of libudev?
On Thu, Oct 24, 2013 at 3:15 PM, Laszlo Papp wrote: > On Thu, Oct 24, 2013 at 2:09 PM, Kay Sievers wrote: >> No, you cannot really ship your own libudev, it is coupled with the >> daemon. They speak a non-trivial wire protocol and write udev database >> files which are a private implementation only; they changed in the >> past, and might change at any time again. Libudev and udevd can only >> be used in the same version. > Do you provide some compatibility for a reasonable time to accommodate the > existing users to switch onto the changed wired protocol? No, the daemon and the lib need to be updated at the same time, there is no promise about compat in any direction, they just belong together. > Failing that, what > would you suggest for the Qt developers? Is there an alternative solution to > keep udev in the loop without building two separate packages, or > distribution dependent packages? Libudev0 and libudev1 are almost API compatible, only a few pointless functions are no longer provided by the new library. There should be no problem at compilation time, both versions should work fine. Things built by distributions should not notice anything, but for binary compatibility across different versions of libraries, I have no sensible idea, sorry. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can apps ship their own copy of libudev?
> -Original Message- > From: Kay Sievers [mailto:k...@vrfy.org] > Subject: Re: [systemd-devel] Can apps ship their own copy of libudev? > > [...] > Libudev0 and libudev1 are almost API compatible, only a few pointless > functions are no longer provided by the new library. There should be no > problem at compilation time, both versions should work fine. Things built by > distributions should not notice anything, but for binary compatibility across > different versions of libraries, I have no sensible idea, sorry. Alright, case closed then :( Thanks for the quick answer! Kai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] F19 network device naming
Yep, that's definitely the case here: [root@sunelkvm6 ~]# grep . /sys/class/net/*/dev_id /sys/class/net/eno1/dev_id:0x0 /sys/class/net/eno2/dev_id:0x0 /sys/class/net/eno3/dev_id:0x0 /sys/class/net/eno4/dev_id:0x0 /sys/class/net/enp4s0f0/dev_id:0x0 /sys/class/net/enp4s0f1/dev_id:0x0 /sys/class/net/enp65s0f0/dev_id:0x0 /sys/class/net/enp65s0f1d1/dev_id:0x1 /sys/class/net/lo/dev_id:0x0 Thanks for the pointer. As far as correcting this, should I contact the maintainer of the sfc driver? Thanks. - Original Message - From: "Kay Sievers" To: "Nicholas Majeran" Cc: systemd-devel@lists.freedesktop.org Sent: Thursday, October 24, 2013 8:03:48 AM Subject: Re: [systemd-devel] F19 network device naming On Wed, Oct 23, 2013 at 9:02 PM, Nicholas Majeran wrote: > I have recently installed Fedora 19 on a Dell R620. > I'm trying to grok the new device naming scheme put forth in systemd, but > the results are a bit confusing. > > This box has four onboard ports -- those are all correctly labelled as > eno[1-4]. > However, when I begin to add in PCIe cards, I don't see what I would expect. > > I've installed two PCIe cards: > one two-port Intel e1000e and one two port SolarFlare Performa card. > [root@sunelkvm6 ~]# ethtool -i enp65s0f0 > driver: sfc > version: 3.2 > firmware-version: 3.2.2.6124 > bus-info: :41:00.0 > supports-statistics: yes > supports-test: yes > supports-eeprom-access: no > supports-register-dump: yes > supports-priv-flags: no > [root@sunelkvm6 ~]# ethtool -i enp65s0f1d1 > driver: sfc > version: 3.2 > firmware-version: 3.2.2.6124 > bus-info: :41:00.1 > supports-statistics: yes > supports-test: yes > supports-eeprom-access: no > supports-register-dump: yes > supports-priv-flags: no > > I would expect to see enp65s0f0 and enp65s0f1, like the e1000e. Yeah, that would be right. I guess someone messed up the kernel driver and exports dev_id == 1 where it needs to be 0. dev_id in the kernel is supposed to count upwards for netdevs of the *same* device(pci) parent, not for netdevs from separate devices. You can check with: $ grep . /sys/class/net/*/dev_id Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can apps ship their own copy of libudev?
On Thu, Oct 24, 2013 at 6:39 AM, Kay Sievers wrote: > On Thu, Oct 24, 2013 at 3:15 PM, Laszlo Papp wrote: >> On Thu, Oct 24, 2013 at 2:09 PM, Kay Sievers wrote: > >>> No, you cannot really ship your own libudev, it is coupled with the >>> daemon. They speak a non-trivial wire protocol and write udev database >>> files which are a private implementation only; they changed in the >>> past, and might change at any time again. Libudev and udevd can only >>> be used in the same version. > >> Do you provide some compatibility for a reasonable time to accommodate the >> existing users to switch onto the changed wired protocol? > > No, the daemon and the lib need to be updated at the same time, there > is no promise about compat in any direction, they just belong > together. > >> Failing that, what >> would you suggest for the Qt developers? Is there an alternative solution to >> keep udev in the loop without building two separate packages, or >> distribution dependent packages? > > Libudev0 and libudev1 are almost API compatible, only a few pointless > functions are no longer provided by the new library. There should be > no problem at compilation time, both versions should work fine. Things > built by distributions should not notice anything, but for binary > compatibility across different versions of libraries, I have no > sensible idea, sorry. One of the places I encountered this problem is Steam - it links against libudev0 while most non-pleistocene distributions are well into libudev1... Symlinking them allows me to waste time playing games :^) I can't recompile Steam, sadly. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can apps ship their own copy of libudev?
On Thursday 2013-10-24 14:15, Koehne Kai wrote:
>
>I'm a developer working on Qt.[...]
>https://bugreports.qt-project.org/browse/QTBUG-34176 [is] one of the
>problems we still have[,] to fix is our libudev.so.0 dependency ...
>That is, we're building the packages on Ubuntu 11.10 and link
>against system libudev.so.0 , while some modern distributions are
>(solely) providing libudev.so.1.
#34176 is an old hat: in general, you must ship all the dependent
libraries with your program package, because your program has been built
against exactly those and there is no guarantee the target system has
any of them, or a particular version. Symlinking does not fix that and
is an error, because symlinks do not make the potentially changed ABI
(which is reflected in the number switch) magically available.
In case of udev, as has already been said in this thread, just
providing it is not enough, which brings us to:
>So, to overcome this we've been thinking about building & shipping
>our own copy of libudev (renamed , or statically linked, to avoid
>clashes) ... Would you expect such a pristine version of libudev,
>compiled on distribution A , to work flawlessly on distribution B?
>What problems would you anticipate?
On the total contrary. To overcome this, you ought to build one
package per distro-version, with Open Build Service being one
possible way to get there. This actually has multiple benefits: you
would no longer need to ship libraries, because you can rely on what
the base system already, as such, you would not even need to worry
about udev any longer either, and third you also make the users happy
because they get a native archive instead of {some unmanaged .run or a
foreign .deb/.rpm that might or might not work}.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] F19 network device naming
On Thu, Oct 24, 2013 at 6:50 PM, Nicholas Majeran wrote: > /sys/class/net/enp65s0f0/dev_id:0x0 > /sys/class/net/enp65s0f1d1/dev_id:0x1 > /sys/class/net/lo/dev_id:0x0 > > Thanks for the pointer. As far as correcting this, should I contact the > maintainer of the sfc driver? Yes, the kernel should be fixed. The driver should start counting the dev_id at 0, for every individual device (a separate pci function is a "device"), not per driver. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can apps ship their own copy of libudev?
El 24/10/13 09:15, Koehne Kai escribió: > Hi, > > First time I post to the list, so please bear with me :) I'm a developer > working on Qt. The Qt project just released a beta of the upcoming version > 5.2, and to help people to test it we've been also releasing an installer > with binaries for Linux that is supposed to work on a variety of > distributions. > > One of the problems [1] we still have to fix is our libudev.so.0 dependency > ... That is, we're building the packages on Ubuntu 11.10 and link against > system libudev.so.0 , while some modern distributions are (solely) providing > libudev.so.1. For some parts of Qt the libudev dependency is actually not > that important , and we can disable it. However, for the QtSerialPort library > I've been told libudev is crucial: It uses it to enumerate all available > ports. > > So, to overcome this we've been thinking about building & shipping our own > copy of libudev (renamed , or statically linked, to avoid clashes) ... I strongly recommend you not to do this, instead please talk with the relevant distribution maintainers in order to get adequate binaries released for each distribution. I not only believe, but I will bet good money that what your are trying to do will in the end working really poorly if at all. -- "If debugging is the process of removing bugs, then programming must be the process of putting them in." - Edsger Dijkstra ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
