[gentoo-user] udev (viable) alternatives ?

[gentoo-user] udev (viable) alternatives ?

[James]

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

Re: [gentoo-user] udev (viable) alternatives ?

[Dale]

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

:-)  :-) 

Re: [gentoo-user] udev (viable) alternatives ?

[Samuli Suominen]

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

[gentoo-user] Re: udev (viable) alternatives ?

[James]

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

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Dale]

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

:-)  :-) 

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Walter Dnes]

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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Alan McKinnon]

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
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Canek Peláez Valdés]

On Fri, Sep 26, 2014 at 3:07 AM, Neil Bothwick <neil@digimed.co.uk> 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

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Samuli Suominen]

On 26/09/14 11:22, Canek Peláez Valdés wrote:
> On Fri, Sep 26, 2014 at 3:07 AM, Neil Bothwick <neil@digimed.co.uk> 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

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Samuli Suominen]

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 <neil@digimed.co.uk> 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

Re: [gentoo-user] Re: udev (viable) alternatives ?

[David W Noon]

On Fri, 26 Sep 2014 12:04:47 +0300, Samuli Suominen
(ssuominen@gentoo.org) wrote about "Re: [gentoo-user] Re: udev (viable)
alternatives ?" (in <54252C2F.1030901@gentoo.org>):

[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]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Samuli Suominen]

On 26/09/14 19:47, David W Noon wrote:
> On Fri, 26 Sep 2014 12:04:47 +0300, Samuli Suominen
> (ssuominen@gentoo.org) wrote about "Re: [gentoo-user] Re: udev (viable)
> alternatives ?" (in <54252C2F.1030901@gentoo.org>):
>
> [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

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Samuli Suominen]

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

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Tanstaafl]

On 9/26/2014 1:04 AM, Samuli Suominen <ssuominen@gentoo.org> 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.

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Rich Freeman]

On Mon, Nov 10, 2014 at 6:04 AM, Tanstaafl <tanstaafl@libertytrek.org> 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

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Tanstaafl]

On 11/10/2014 7:30 AM, Rich Freeman <rich0@gentoo.org> 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.

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Rich Freeman]

On Mon, Nov 10, 2014 at 8:23 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 11/10/2014 7:30 AM, Rich Freeman <rich0@gentoo.org> 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

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Samuli Suominen]

On 10/11/14 13:04, Tanstaafl wrote:
> On 9/26/2014 1:04 AM, Samuli Suominen <ssuominen@gentoo.org> 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.

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Tanstaafl]

On 11/10/2014 10:48 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> 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.

Well, that sounds reassuring, so thanks very much for this and you're
hard work for all of us non-programmer gentoo users, it is much appreciated!

I guess Lennart was just using words that I read the wrong way... even
now if I re-read his posts, it sounds to me like he is saying 'no more
separate udev without systemd ultimately'... and I know for sure he has
made exactly this comments in the past, but that was admittedly 1 year
or two ago...

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Walter Dnes]

On Mon, Nov 10, 2014 at 05:48:49PM +0200, Samuli Suominen wrote

> 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.

  What worries me is that Lennart has been able to get modifications
done to the kernel, e.g. kdbus.  I know this'll sound paranoid, but how
long before he pushes a patch that requires systemd to run the linux
kernel?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Samuli Suominen]

On 11/11/14 07:20, Walter Dnes wrote:
> On Mon, Nov 10, 2014 at 05:48:49PM +0200, Samuli Suominen wrote
>
>> 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.
>   What worries me is that Lennart has been able to get modifications
> done to the kernel, e.g. kdbus.  I know this'll sound paranoid, but how
> long before he pushes a patch that requires systemd to run the linux
> kernel?
>

I expect systemd-udevd to be migrated into kdbus, which means libudev,
libgudev-1.0 and the
systemd-udevd binary itself will likely need the libsystemd-bus library,
which we will then package
and ship together with sys-fs/udev
Or if systemd-udevd binary starts requiring a running service of some of
the systemd services,
then we will make those available as well and run the from the
udev-init-scripts, or possibly
even adjust sys-apps/openrc to compensate for the inadequaties

Just trying to say, that even with kdbus pending, I'm not worried at all

- Samuli

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Canek Peláez Valdés]

On Mon, Nov 10, 2014 at 11:20 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Mon, Nov 10, 2014 at 05:48:49PM +0200, Samuli Suominen wrote
>
>> 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.
>
>   What worries me is that Lennart has been able to get modifications
> done to the kernel, e.g. kdbus.  I know this'll sound paranoid, but how
> long before he pushes a patch that requires systemd to run the linux
> kernel?

Then you can take the very last commit to Linus' Git repository before
that hypothetical change, and fork the Linux kernel into whatever
direction your crazy heart desires.

Business as usual in the Free Software world.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Rich Freeman]

On Tue, Nov 11, 2014 at 12:20 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Mon, Nov 10, 2014 at 05:48:49PM +0200, Samuli Suominen wrote
>
>> 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.
>
>   What worries me is that Lennart has been able to get modifications
> done to the kernel, e.g. kdbus.  I know this'll sound paranoid, but how
> long before he pushes a patch that requires systemd to run the linux
> kernel?

Apologies if this comes across a bit agro, but:

1.  kdbus isn't in the kernel (though that seems likely to happen at some point)
2.  it does sound paranoid
3.  if he pushes a patch that requires systemd I'd be shocked if Linus merged it

Can you find one example of any situation where the linux kernel has
ever required any specific implementation of anything in userspace as
a matter of policy in its 23 year history?  I'm sure you could find
some examples of cases where there just happened to be one de-facto
implementation of something, but even that might be tough with all the
diversity in the linux world.

Linus himself has articulated some of the reasons why kdbus is likely
to get merged.  It fills in a gap in Linux as compared to many
competing operating systems, and it is logical to implement at the
kernel level.  That is generally the criteria for getting stuff into
the kernel, and is basically good software design.  The linux kernel
is all about stable userspace ABIs - if there is only one
implementation of something it is probably because nobody was bothered
enough to write another.

--
Rich

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Walter Dnes]

On Tue, Nov 11, 2014 at 07:18:30AM -0500, Rich Freeman wrote
> On Tue, Nov 11, 2014 at 12:20 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> >
> >   What worries me is that Lennart has been able to get modifications
> > done to the kernel, e.g. kdbus.  I know this'll sound paranoid, but how
> > long before he pushes a patch that requires systemd to run the linux
> > kernel?
> 
> Apologies if this comes across a bit agro, but:
> 
> 1.  kdbus isn't in the kernel (though that seems likely to happen at some point)
> 2.  it does sound paranoid
> 3.  if he pushes a patch that requires systemd I'd be shocked if Linus merged it
> 
> Can you find one example of any situation where the linux kernel has
> ever required any specific implementation of anything in userspace as
> a matter of policy in its 23 year history?  I'm sure you could find
> some examples of cases where there just happened to be one de-facto
> implementation of something, but even that might be tough with all the
> diversity in the linux world.

  It might not be an official official requirement, but if the upstream
gets rolled into systemd, then we depend on the "goodwill" of systemd
devs not to go and break anybody else's userspace implementation.
Lennart and "goodwill" do not belong in the same sentence.  How's
systemd-shim working out for Debian???  I'm old enough to remember the
OS/2-versus-Windows wars.  At one point, IBM had Windows 3.1 running
inside of OS/2.  Then Microsoft issued "a minor update" (Windows 3.11)
and it no longer ran inside OS/2.  It took a while for IBM to get
Windows 3.11 running inside OS/2.  That's the kind of hostility that
non-Lennart userspace software faces.
 
> Linus himself has articulated some of the reasons why kdbus is likely
> to get merged.  It fills in a gap in Linux as compared to many
> competing operating systems, and it is logical to implement at the
> kernel level.  That is generally the criteria for getting stuff into
> the kernel, and is basically good software design.  The linux kernel
> is all about stable userspace ABIs - if there is only one
> implementation of something it is probably because nobody was bothered
> enough to write another.

  We Gentoo folks got our wakeup call ( literally
http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html )
from the guy who signs himself as "Lennart Poettering, Red Hat"
(nuff said).

  I don't know how long udev will run standalone without systemd.  My
desktop PC is running mdev.  See https://wiki.gentoo.org/wiki/Mdev and
https://wiki.gentoo.org/wiki/Mdev/Automount_USB

  eudev is also an option.  Hopefully, device management doesn't get
forced into systemd.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: udev (viable) alternatives ?

[Tom H]

On Thu, Nov 13, 2014 at 12:08 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Tue, Nov 11, 2014 at 07:18:30AM -0500, Rich Freeman wrote
>>
>> Can you find one example of any situation where the linux kernel has
>> ever required any specific implementation of anything in userspace as
>> a matter of policy in its 23 year history? I'm sure you could find
>> some examples of cases where there just happened to be one de-facto
>> implementation of something, but even that might be tough with all the
>> diversity in the linux world.
>
> It might not be an official official requirement, but if the upstream
> gets rolled into systemd, then we depend on the "goodwill" of systemd
> devs not to go and break anybody else's userspace implementation.
> Lennart and "goodwill" do not belong in the same sentence. How's
> systemd-shim working out for Debian?

Do you have any reason to think that it isn't working out?

The systemd-shim and cgmanager developers have to play catch up but
I'm using both on Debian and Ubuntu and they're OK.