udev (viable) alternatives ?

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

udev (viable) alternatives ?

James-2
Ok,

So I have used eudev before, without issue before. Things are moving along
so now I see an udev-215 upgrade to udev-261 on a system running lxde.
I intend to migrate this system to lxqt in the next few weeks, after
I build up a new workstation.

So changing from udev-215 to eudev-1.10-r2 is as simple as
unmerging the former and emerging the latter ? The sytem
is not tweaked very much and still running a 3.13.6 kernel, for now.


Any other caveats (short term) on switching udev to eudev?


curiously,
James




Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

Dale-46
James wrote:

> Ok,
>
> So I have used eudev before, without issue before. Things are moving along
> so now I see an udev-215 upgrade to udev-261 on a system running lxde.
> I intend to migrate this system to lxqt in the next few weeks, after
> I build up a new workstation.
>
> So changing from udev-215 to eudev-1.10-r2 is as simple as
> unmerging the former and emerging the latter ? The sytem
> is not tweaked very much and still running a 3.13.6 kernel, for now.
>
>
> Any other caveats (short term) on switching udev to eudev?
>
>
> curiously,
> James
>
>

I switched to eudev back when it was just getting going.  Even then, it
was as easy as unmerge udev, emerge eudev then restart udev.  The init
is still called udev, at least it is here.  Other than being able to
ditch that broken init thingy for booting, I haven't seen any difference.

Hope that helps.

Dale

:-)  :-)

Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

Samuli Suominen-4
In reply to this post by James-2

On 25/09/14 18:25, James wrote:

> Ok,
>
> So I have used eudev before, without issue before. Things are moving along
> so now I see an udev-215 upgrade to udev-261 on a system running lxde.
> I intend to migrate this system to lxqt in the next few weeks, after
> I build up a new workstation.
>
> So changing from udev-215 to eudev-1.10-r2 is as simple as
> unmerging the former and emerging the latter ? The sytem
> is not tweaked very much and still running a 3.13.6 kernel, for now.
>
>
> Any other caveats (short term) on switching udev to eudev?

no support for kernel side predictable interface names where the naming
should
*really* be happening, eudev will always rename your interfaces with or
without USE="rule-generator"

to be explicit, eudev will ignore /lib/udev/hwdb.d/20-net-ifname.hwdb,
eudev will rename interfaces
marked as predictable by the kernel metadata, as in, eudev doesn't
contain this commit:

http://cgit.freedesktop.org/systemd/systemd/commit/network/99-default.link?id=04b67d49254d956d31bcfe80340fb9df7ed332d3

in fact, from what I last checked, eudev's networking is at same level
with udev-208, from time before the .link support at all

eudev is really useful only for sys-libs/musl users at this time, but
you are free to experiment with it!

- Samuli

Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

James-2
Samuli Suominen <ssuominen <at> gentoo.org> writes:


> > Any other caveats (short term) on switching udev to eudev?

> in fact, from what I last checked, eudev's networking is at same level
> with udev-208, from time before the .link support at all

ah, back when ethernet defaulted to eth0 not "enp5s0" ?


> eudev is really useful only for sys-libs/musl users at this time, but
> you are free to experiment with it!

so lilblue (Anthony's amd64  hardened gentoo) is the only candidate I can
think of with musl?  So I choose this, then profile must be set to:

(eslect profile list):
 [16]  hardened/linux/musl/amd64


I'd be better of with a fresh install of  lilblue + musl + eudev
is what you are really saying here?


James







Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

Dale-46
James wrote:
> Samuli Suominen <ssuominen <at> gentoo.org> writes:
>
>
>>> Any other caveats (short term) on switching udev to eudev?
>> in fact, from what I last checked, eudev's networking is at same level
>> with udev-208, from time before the .link support at all
> ah, back when ethernet defaulted to eth0 not "enp5s0" ?
>

Mine still does here.  It's been eth0, eth1 etc for ages even after
switching.  I don't recall doing anything to keep it that way.

>
> James
>
Dale

:-)  :-)

Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

Walter Dnes
In reply to this post by James-2
On Thu, Sep 25, 2014 at 07:03:02PM +0000, James wrote
> Samuli Suominen <ssuominen <at> gentoo.org> writes:
>
>
> > > Any other caveats (short term) on switching udev to eudev?
>
> > in fact, from what I last checked, eudev's networking is at same level
> > with udev-208, from time before the .link support at all
>
> ah, back when ethernet defaulted to eth0 not "enp5s0" ?

  I buy machines with one ethernet interface.  What I find particularly
annoying is this doublespeak about calling it "predictable".  Before the
change, it was predicatbly "eth0".  Now, it's different on every
different model.

--
Walter Dnes <[hidden email]>
I don't run "desktop environments"; I run useful applications

Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

Alan McKinnon-2
On 26/09/2014 02:23, Walter Dnes wrote:

> On Thu, Sep 25, 2014 at 07:03:02PM +0000, James wrote
>> Samuli Suominen <ssuominen <at> gentoo.org> writes:
>>
>>
>>>> Any other caveats (short term) on switching udev to eudev?
>>
>>> in fact, from what I last checked, eudev's networking is at same level
>>> with udev-208, from time before the .link support at all
>>
>> ah, back when ethernet defaulted to eth0 not "enp5s0" ?
>
>   I buy machines with one ethernet interface.  What I find particularly
> annoying is this doublespeak about calling it "predictable".  Before the
> change, it was predicatbly "eth0".  Now, it's different on every
> different model.
>


It's not doublespeak, the interfaces are named exactly according to
where they are on the PCI bus. If you had two interfaces, they show up
to the kernel in random order by time and sometimes eth0/eth1 are nto
the same they were before the reboot.


You are just looking at this from the wrong point of view.

--
Alan McKinnon
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

Samuli Suominen-4
In reply to this post by James-2

On 25/09/14 22:03, James wrote:
> Samuli Suominen <ssuominen <at> gentoo.org> writes:
>
>
>>> Any other caveats (short term) on switching udev to eudev?
>> in fact, from what I last checked, eudev's networking is at same level
>> with udev-208, from time before the .link support at all
> ah, back when ethernet defaulted to eth0 not "enp5s0" ?

nope, 208 was back when 80-net-name-slot.rules predictable rules were
used which
ignored kernel metadata for predictable networking
i.e. the insufficient implementatition, which got replaced by
99-default.link and 80-net-link-setup.rules
what you are referring is the buggy pre-udev-197 networking, which you
can unfortunately
still get with USE="rule-generator", it will keep renaming your
interfaces despite kernel
telling not to, so kernel drivers that mark eth0 as stable, might get
renamed to eg. eth1
if you have 2 cards
it's really messy, only 209 (and higher) handles things right, the new
.link setup, with kernel naming support

>
>
>> eudev is really useful only for sys-libs/musl users at this time, but
>> you are free to experiment with it!
> so lilblue (Anthony's amd64  hardened gentoo) is the only candidate I can
> think of with musl?  So I choose this, then profile must be set to:
>
> (eslect profile list):
>  [16]  hardened/linux/musl/amd64
>
>
> I'd be better of with a fresh install of  lilblue + musl + eudev
> is what you are really saying here?
>
>
>

that's the only usecase for eudev currently, yes, otherwise you have no
reason to switch

Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

Neil Bothwick
In reply to this post by Alan McKinnon-2
On Fri, 26 Sep 2014 05:27:15 +0200, Alan McKinnon wrote:

> >   I buy machines with one ethernet interface.  What I find
> > particularly annoying is this doublespeak about calling it
> > "predictable".  Before the change, it was predicatbly "eth0".  Now,
> > it's different on every different model.

> It's not doublespeak, the interfaces are named exactly according to
> where they are on the PCI bus. If you had two interfaces, they show up
> to the kernel in random order by time and sometimes eth0/eth1 are nto
> the same they were before the reboot.

That may be true for PCI devices but not for USB ones. If you unplug a
USB device and plug it back into the same port, it will get a different
device number. The naming is more predictable, but it's not there yet.


--
Neil Bothwick

The gene pool could use a little chlorine.

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

Canek Peláez Valdés
On Fri, Sep 26, 2014 at 3:07 AM, Neil Bothwick <[hidden email]> wrote:

> On Fri, 26 Sep 2014 05:27:15 +0200, Alan McKinnon wrote:
>
>> >   I buy machines with one ethernet interface.  What I find
>> > particularly annoying is this doublespeak about calling it
>> > "predictable".  Before the change, it was predicatbly "eth0".  Now,
>> > it's different on every different model.
>
>> It's not doublespeak, the interfaces are named exactly according to
>> where they are on the PCI bus. If you had two interfaces, they show up
>> to the kernel in random order by time and sometimes eth0/eth1 are nto
>> the same they were before the reboot.
>
> That may be true for PCI devices but not for USB ones. If you unplug a
> USB device and plug it back into the same port, it will get a different
> device number. The naming is more predictable, but it's not there yet.

That doesn't sound right. If unplugging a USB net device and plugging
it again *in the same port* results in a different device *name*, then
it is a bug and should be reported; the description of the algorithm
in [1] sounds like it should get always the same name for the same
port, unless I'm misunderstanding something.

Regards.

[1] http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n51
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

Neil Bothwick
On Fri, 26 Sep 2014 03:22:16 -0500, Canek Peláez Valdés wrote:

> > That may be true for PCI devices but not for USB ones. If you unplug a
> > USB device and plug it back into the same port, it will get a
> > different device number. The naming is more predictable, but it's not
> > there yet.  
>
> That doesn't sound right. If unplugging a USB net device and plugging
> it again *in the same port* results in a different device *name*, then
> it is a bug and should be reported; the description of the algorithm
> in [1] sounds like it should get always the same name for the same
> port, unless I'm misunderstanding something.
It certainly was the case. I couldn't test it directly because this
laptop doesn't have support for such devices, but plugging, unplugging
and replugging a USB ethernet adaptor resulted in a change of device
number. I just switched to a different machine and it does indeed give the
same name now, so things have been fixed and the interface names are now
predictable.

Ugly as hell, hard to remember, but they are predictable.


--
Neil Bothwick

Make it idiot proof and someone will make a better idiot.

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

Samuli Suominen-4
In reply to this post by Canek Peláez Valdés

On 26/09/14 11:22, Canek Peláez Valdés wrote:

> On Fri, Sep 26, 2014 at 3:07 AM, Neil Bothwick <[hidden email]> wrote:
>> On Fri, 26 Sep 2014 05:27:15 +0200, Alan McKinnon wrote:
>>
>>>>   I buy machines with one ethernet interface.  What I find
>>>> particularly annoying is this doublespeak about calling it
>>>> "predictable".  Before the change, it was predicatbly "eth0".  Now,
>>>> it's different on every different model.
>>> It's not doublespeak, the interfaces are named exactly according to
>>> where they are on the PCI bus. If you had two interfaces, they show up
>>> to the kernel in random order by time and sometimes eth0/eth1 are nto
>>> the same they were before the reboot.
>> That may be true for PCI devices but not for USB ones. If you unplug a
>> USB device and plug it back into the same port, it will get a different
>> device number. The naming is more predictable, but it's not there yet.
> That doesn't sound right. If unplugging a USB net device and plugging
> it again *in the same port* results in a different device *name*, then
> it is a bug and should be reported; the description of the algorithm
> in [1] sounds like it should get always the same name for the same
> port, unless I'm misunderstanding something.
>
> Regards.
>
> [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n51

I've seen this happening once on a cheap laptop with a stripped down
BIOS I can't
even recall brand for, it had a kludge in the BIOS settings for
hotplugging, turning
it off, allowed the port to remain same, turning it on, some machine
specific code
gets executed and the kernel interprets the same port as different port

Bad hardware, bad hardware settings, maybe missing exception for that
particular
hardware type in the code that determines the name... I'm not sure, I
don't have
the machine anymore

- Samuli

Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

Samuli Suominen-4

On 26/09/14 11:47, Samuli Suominen wrote:

> On 26/09/14 11:22, Canek Peláez Valdés wrote:
>> On Fri, Sep 26, 2014 at 3:07 AM, Neil Bothwick <[hidden email]> wrote:
>>> On Fri, 26 Sep 2014 05:27:15 +0200, Alan McKinnon wrote:
>>>
>>>>>   I buy machines with one ethernet interface.  What I find
>>>>> particularly annoying is this doublespeak about calling it
>>>>> "predictable".  Before the change, it was predicatbly "eth0".  Now,
>>>>> it's different on every different model.
>>>> It's not doublespeak, the interfaces are named exactly according to
>>>> where they are on the PCI bus. If you had two interfaces, they show up
>>>> to the kernel in random order by time and sometimes eth0/eth1 are nto
>>>> the same they were before the reboot.
>>> That may be true for PCI devices but not for USB ones. If you unplug a
>>> USB device and plug it back into the same port, it will get a different
>>> device number. The naming is more predictable, but it's not there yet.
>> That doesn't sound right. If unplugging a USB net device and plugging
>> it again *in the same port* results in a different device *name*, then
>> it is a bug and should be reported; the description of the algorithm
>> in [1] sounds like it should get always the same name for the same
>> port, unless I'm misunderstanding something.
>>
>> Regards.
>>
>> [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n51
> I've seen this happening once on a cheap laptop with a stripped down
> BIOS I can't
> even recall brand for, it had a kludge in the BIOS settings for
> hotplugging, turning
> it off, allowed the port to remain same, turning it on, some machine
> specific code
> gets executed and the kernel interprets the same port as different port
>
> Bad hardware, bad hardware settings, maybe missing exception for that
> particular
> hardware type in the code that determines the name... I'm not sure, I
> don't have
> the machine anymore
>
> - Samuli
>

Later kernels *can mark interfaces predictable in a new form of
metadata*, and udev >= 209 can
pick that information up, and then it won't do anykind of userspace
renaming on it, since kernel
has declared the interface name to be steady...predictable...always
same, so I hope
we are moving towards kernel assigning predictable names for all drivers
and we can get rid of
the userspace renaming of interfaces all together at some point
I really believe this is a task for the kernel to provide predictable
names, and all this userspace
renaming is just a bandage we can hopefully soon rip off

- Samuli

Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

David W Noon-2
On Fri, 26 Sep 2014 12:04:47 +0300, Samuli Suominen
([hidden email]) wrote about "Re: [gentoo-user] Re: udev (viable)
alternatives ?" (in <[hidden email]>):

[snip]
> Later kernels *can mark interfaces predictable in a new form of
> metadata*, and udev >= 209 can
> pick that information up, and then it won't do anykind of userspace
> renaming on it, since kernel
> has declared the interface name to be steady...predictable...always
> same, so I hope
> we are moving towards kernel assigning predictable names for all drivers
> and we can get rid of
> the userspace renaming of interfaces all together

I hope these kernel-assigned interface names are configurable, as I have
been naming the interfaces on my machines with *mnemonic* names for many
years now. [These are names like "inet" and "lan" for interfaces that
connect the machine to the Internet or my LAN.]  I certainly do not want
to go back to "eth0" and the like -- or worse still, udev's
"predictable" names -- as these are not mnemonic in any way.
--
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
[hidden email] (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 

Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

Samuli Suominen-4

On 26/09/14 19:47, David W Noon wrote:

> On Fri, 26 Sep 2014 12:04:47 +0300, Samuli Suominen
> ([hidden email]) wrote about "Re: [gentoo-user] Re: udev (viable)
> alternatives ?" (in <[hidden email]>):
>
> [snip]
>> Later kernels *can mark interfaces predictable in a new form of
>> metadata*, and udev >= 209 can
>> pick that information up, and then it won't do anykind of userspace
>> renaming on it, since kernel
>> has declared the interface name to be steady...predictable...always
>> same, so I hope
>> we are moving towards kernel assigning predictable names for all drivers
>> and we can get rid of
>> the userspace renaming of interfaces all together
> I hope these kernel-assigned interface names are configurable, as I have
> been naming the interfaces on my machines with *mnemonic* names for many
> years now. [These are names like "inet" and "lan" for interfaces that
> connect the machine to the Internet or my LAN.]  I certainly do not want
> to go back to "eth0" and the like -- or worse still, udev's
> "predictable" names -- as these are not mnemonic in any way.

Later kernel marks some drivers interface names "predictable" or
"stable", not sure which word is best to use here, and then udev
won't rename it by default to anything. The kernel assigned name
could be anything, and I doubt it's in the eth* namespace
And they can still be renamed by custom rules, that won't change,
it's just that they won't get renamed by *default* anymore

Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

tanstaafl-2
In reply to this post by Samuli Suominen-4
On 9/26/2014 1:04 AM, Samuli Suominen <[hidden email]> wrote:
> On 25/09/14 22:03, James wrote:
>> I'd be better of with a fresh install of  lilblue + musl + eudev
>> is what you are really saying here?

> that's the only usecase for eudev currently, yes, otherwise you have no
> reason to switch

Hi Samuli,

So, is the above still true?

eudev is looking more attractive every day... but can it continue to
work and be supported if Lennart gets his way and upstream udev stops
working without systemd?

Just saw reference to the following thread on the debian-user list, and
it includes a couple of responses from you (and an insult hurled at you
from Lennart)... and I'm a bit worried that gentoo will be forced to
swallow the systemd koolaid sometime maybe even sooner rather than later
if Lennart succeeds in making udev work only with systemd, as he makes
clear his desire to do just that here:

http://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html

Notably:

Lennart said:
>>> Also note that at that point we intend to move udev onto kdbus
>>> as transport, and get rid of the userspace-to-userspace
>>> netlink-based tranport udev used so far. Unless the
>>> systemd-haters prepare another kdbus userspace until then this
>>> will effectively also mean that we will not support non-systemd
>>> systems with udev anymore starting at that point. Gentoo folks,
>>> this is your wakeup call.

Samuli replied:
>> I've already set minimum kernel required to 2.6.39 in >= 213, and
>> I'd be fine setting it even higher. Talking only of the udev bit
>> here. I don't like dropping support for old versions, but if that's
>> what has to be done, I'll go with that. Please, don't use this as
>> an excuse to drop support for MinimalBuilds as described in wiki in
>> some manner. As in, if it's still possible to use some kernel, like
>> kernel with kdbus, and even if it requires an userspace library
>> like 'libsystemd-something' to go with it, and still get a udev one
>> way or another, that can run standalone, we are all good.

Lennart responded:
> You need the userspace code to set up the bus and its policy and
> handle activation. That's not a trivial task. For us, that's what
> sytemd does in PID 1. You'd need to come up with an alternative for
> that.

Samuli said:
>> I'd really hate to be forced to fork (or carry huge patchset)
>> unnecessarily (I'm not a systemd hater, I'm not a eudev lover, I'm
>> simply working on what is provided to me by *you*, udev upstream)

Lennart replied:

> Oh god. You know, if you come me like this as blame me that I would
> "force" you to do something, then you just piss me off and make me
> ignore you.
>
> Anyway, as soon as kdbus is merged this i how we will maintain udev,
> you have ample time to figure out some solution that works for you,
> but we will not support the udev-on-netlink case anymore. I see three
> options: a) fork things, b) live with systemd, c) if hate systemd
> that much, but love udev so much, then implement an alternative
> userspace for kdbus to do initialiuzation/policy/activation.
>
> Also note that this will not be a change that is just internal
> between udev and libudev. We expect that clients will soonishly just
> start doing normal bus calls to the new udev, like they'd do them to
> any other system service instead of using libudev.

Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

Rich Freeman
On Mon, Nov 10, 2014 at 6:04 AM, Tanstaafl <[hidden email]> wrote:
>
> eudev is looking more attractive every day... but can it continue to
> work and be supported if Lennart gets his way and upstream udev stops
> working without systemd?
>

Well, there are no plans to make udev stop working without systemd as
far as I can tell.  HOWEVER, there ARE plans to require using kdbus to
communicate with udev, and for that to work there needs to be a
userspace initialization of kdbus/etc.

Udev is probably just be the tip of the iceberg.  Lots of packages use
dbus, and it seems likely to me that many will start switching to
kdbus.  The fact that it is going to be a standard kernel IPC
mechanism also means that packages that have avoided dbus in the
interests of not having large dependencies may start picking it up as
well - it might be used even on embedded systems.

I have no idea how much work is involved or if anybody else is
interested in doing it.  If busybox is willing to have their mdev
module, I don't see why they wouldn't want a kdbus module to go along
with that.  However, that is speaking mostly out of ignorance, and
somebody needs to write the code.

I don't think avoiding kdbus is going to be a viable long-term
solution.  Folks who don't want to run systemd need to start planning
for this, and cross "needs dbus" off their list of reasons not to use
systemd.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

tanstaafl-2
On 11/10/2014 7:30 AM, Rich Freeman <[hidden email]> wrote:
> Well, there are no plans to make udev stop working without systemd as
> far as I can tell.  HOWEVER, there ARE plans to require using kdbus to
> communicate with udev, and for that to work there needs to be a
> userspace initialization of kdbus/etc.

So... you're saying I'm mis-reading this:

> Unless the systemd-haters prepare another kdbus userspace until then
> this will effectively also mean that we will not support non-systemd
> systems with udev anymore starting at that point. Gentoo folks, this
> is your wakeup call.

and that it doesn't mean that "udev will stop working without systemd",
or, as Lennart said, "... we will not support non-systemd systems with
udev anymore staryting at that point (when udev is moved onto kdbus as
transport)?

Or... maybe eudev (or mdev, or both) could or would have to be
[re]written so as to be fulfill the 'kdbus userspace' role Lennart
mentions above?

Being 'not a dev' (or programmer at all), I guess it is entirely
possible it isn't as bad as it sounds, but his "Gentoo folks, this is
your wake-up call." comment is what really stands out to me, as a gentoo
user.

I don't care about dbus/kdbus - if it is in the kernel, and under Linus'
control, and I need to enable it to use my systems, that is fine with
me. What I want is to always have the option - a *stable* option - to
not have to install/use systemd if I don't want to.

Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

Rich Freeman
On Mon, Nov 10, 2014 at 8:23 AM, Tanstaafl <[hidden email]> wrote:
> On 11/10/2014 7:30 AM, Rich Freeman <[hidden email]> wrote:
>> Well, there are no plans to make udev stop working without systemd as
>> far as I can tell.  HOWEVER, there ARE plans to require using kdbus to
>> communicate with udev, and for that to work there needs to be a
>> userspace initialization of kdbus/etc.
>
> So... you're saying I'm mis-reading this:

Somewhat.

>
>> Unless the systemd-haters prepare another kdbus userspace until then
>> this will effectively also mean that we will not support non-systemd
>> systems with udev anymore starting at that point. Gentoo folks, this
>> is your wakeup call.
>
> and that it doesn't mean that "udev will stop working without systemd",
> or, as Lennart said, "... we will not support non-systemd systems with
> udev anymore staryting at that point (when udev is moved onto kdbus as
> transport)?

The part that you're missing is the "Unless the systemd-haters [sic]
prepare another kdbus userspace."

Like many parts of the kernel, kdbus needs initialization from
userspace.  This is no different than what udev does in the first
place - the kernel has device drivers, but SOMETHING has to populate
/dev with device nodes if you want to use them.  Now /dev has been
around since the dawn of time, so we get our choice of 47 different
ways of doing that.  Kdbus hasn't been around for long at all, so
nobody has really written any standalone processes for initializing
it.

As far as I can tell, udev will work just fine as long as something
sets up kdbus.  I'd have to study it a bit more to understand if there
is some reason that this something has to be PID 1.

I don't care for the attitude/etc and especially the treatment of
Samuli (who seems to do his best to cooperate with everybody in this
contentious area), but stepping back I can't really say that a project
deciding to move to a new API based on a new IPC feature is all that
controversial on its own.  Normally when this sort of thing happens
there are a bunch of projects built to support such a new kernel
feature in userspace.

I think the main reasons that we are where we are right now are:
1.  All the big distros are moving to systemd anyway, so they don't
really have much of an itch to scratch here.
2.  Most folks not interested in systemd seem to generally not be
interested in dbus at all.  I think there is a lot of hope that this
problem will just go away, and I suspect that if anything it will get
a lot worse.
3.  Those who aren't using systemd to some extent are a bit split
across udev, eudev, and busybox mdev.  This does divide up the labor
pool a bit and means interests aren't 100% aligned.

The situation doesn't really see irreparable to me, but it does seem
like there is something to be done.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: udev (viable) alternatives ?

Samuli Suominen-4
In reply to this post by tanstaafl-2

On 10/11/14 13:04, Tanstaafl wrote:
> On 9/26/2014 1:04 AM, Samuli Suominen <[hidden email]> wrote:
>> On 25/09/14 22:03, James wrote:
>>> I'd be better of with a fresh install of  lilblue + musl + eudev
>>> is what you are really saying here?
>> that's the only usecase for eudev currently, yes, otherwise you have no
>> reason to switch
> Hi Samuli,
>
> So, is the above still true?

Yes, it's still true, there is no reason to change away from sys-fs/udev
except for sys-libs/musl use,
and even then, I'd be happy to accept musl compability patches for
sys-fs/udev's ebuild, but the
sys-libs/musl maintainer decided to put his work to sys-fs/eudev
instead. So unless some user
does the work for him...

I wouldn't worry about it at all, there is no way *sys-fs/udev ebuild*
will ever need systemd. There
might be a news item later, with instructions on moving to something
else, but that's not something
we are even planning at the moment, so sys-fs/udev is still the de facto
proper upstream /dev
manager.

12