Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
kdbus in the kernel
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 5, 6, 7 ... 25, 26, 27  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Fri Jan 16, 2015 9:06 pm    Post subject: Reply with quote

Naib wrote:
v3 is out

http://lkml.iu.edu/hypermail/linux/kernel/1501.2/00487.html


Maybe by v50 or so they'll get it right :lol:
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
Shamus397
Apprentice
Apprentice


Joined: 03 Apr 2005
Posts: 218
Location: Ur-th

PostPosted: Wed Jan 21, 2015 5:21 pm    Post subject: Reply with quote

Bleah.
Theodore T'so wrote:
I have to agree with Michael here; it's really, **really** disengenuous to say that that if you don't want kdbus, you can just #ifconfig it out. The fact that it systemd will be using it means that it will very shortly become a core kernel feature which is absolutely mandatory. Sure, maybe it can be configured out for "tiny kernels", just as in theory we can configure out the VM system for really tiny embedded systems. But we should be treating this as something that is not optional, because the reality is that's the way it's going to be in very short order.

Seen here.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Wed Jan 21, 2015 5:50 pm    Post subject: Reply with quote

It seems like they're still not having easy sailing, getting through the kernel dev (well, except for GKH :roll: )

I would like to see it's status be like reiser4, if you want it get the patches and apply them,
but when something breaks in the kernel because of it, don't come and yell at the kernel devs.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3505

PostPosted: Wed Jan 21, 2015 6:37 pm    Post subject: Reply with quote

Anon-E-moose wrote:
It seems like they're still not having easy sailing, getting through the kernel dev (well, except for GKH :roll: )

I would like to see it's status be like reiser4, if you want it get the patches and apply them,
but when something breaks in the kernel because of it, don't come and yell at the kernel devs.


Remember the old proverb, "Be careful what you ask for, because you may get it." Did we really want World Domination? That meant a massive influx of Windows users and developers, and that has brought us to systemd. I've been coming to the opinion that any significant / rapid growth was going to do something like this. The old guard is just too small to educate all of the newcomers, especially the incoming developers, fast enough.

What will be interesting will be the dynamics of the old-guard non-systemd distributions over time, and how they relate to the systemd distributions. I've seen signs that more of the old guard are waking to this, and are if not as strident about it as some here, certainly as firm. The interesting thing to watch will be the server market, where the old guard has tended to work.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Wed Jan 21, 2015 7:22 pm    Post subject: Reply with quote

World domination = monoculture = bad. No, I don't want that.

But we don't need to worry about that happening in RedHat's brave new world — their OS software stack has no user-serviceable parts inside and the GUI is a bad knockoff of OS X; if GNOME3 ever got a marketshare that mattered, they'd be nuked into oblivion by Apple's lawyers while their snubbed ex-users break out a set of World's Smallest Violins.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3505

PostPosted: Wed Jan 21, 2015 7:56 pm    Post subject: Reply with quote

Ant P. wrote:
World domination = monoculture = bad. No, I don't want that.

World Domination has been an ongoing goal/joke for some time now, even Linus has used it.
Ant P. wrote:
... their OS software stack has no user-serviceable parts inside and the GUI is a bad knockoff of OS X

Windows users don't generally want user-servicable parts inside - they're used to not having or needing them anyway. To be fair, Linux hasn't done the best job of having user-servicable parts, either. Default configurations tend to be incomplete or have other problems, and it frequently seems that "user-servicable" means that "user MUST service" parts inside. (Example... If dmix had shipped with better defaults and perhaps a GUI configuration tool, pulseaudio might never have gotten off the ground, much less survived past its first horrible incarnation.) (Alternate example, XOrg has done a really good job of working out-of-the-box, but leaving the ability to tweak intact.)

As for "bad knockoff of OS/X", some call Windows that, anyway.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3505

PostPosted: Thu Jan 22, 2015 2:23 pm    Post subject: Reply with quote

The kdbus 3.0 inclusion debate continues, and an interesting turn has emerged. The kdbus developers have considered it to be an add-on, and were therefore seeking to use ioctl() calls to run it. One of the major characters on this round sees that kdbus will likely quickly become a non-optional (or normally-required) core part, and therefore should have syscalls instead of ioctl() calls.

In that light, syscall APIs are generally much more carefully scrutnized for proper definition. A decent pointer into the discussion:
https://lkml.org/lkml/2015/1/22/180
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Thu Jan 22, 2015 9:12 pm    Post subject: Reply with quote

depontius wrote:
In that light, syscall APIs are generally much more carefully scrutinized for proper definition. A decent pointer into the discussion:
https://lkml.org/lkml/2015/1/22/180

Interesting thanks for the link. I found this a bit worrying:
Michael Kerrisk wrote:
the API is so big and hard to grok that it's hard to even begin to work out what's missing from the documentation.

That just says to me that it's ill-conceived. What we want is something like LADSPA, that does not sprawl.

As for this:
David Herrmann wrote:
We know, that our API will not be perfect, none is. But we will try hard to fix anything that comes up, as long as we can. And this effort will manifest in ABI-breaks.

No. You do not break userland. More generally, your consumer, but once an ABI is in the kernel it cannot be dropped.

That's why you do things in userland instead, and even there people use simple APIs like LADSPA, and hide the complexity instead of exposing everyone to it, as if that were clever instead of dumb.

I don't see this going well, given the encouraging noises being made toward the kdbus "developers".
Though again, we should be using TIPC.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Thu Jan 22, 2015 11:20 pm    Post subject: Reply with quote

steveL wrote:
As for this:
David Herrmann wrote:
We know, that our API will not be perfect, none is. But we will try hard to fix anything that comes up, as long as we can. And this effort will manifest in ABI-breaks.

No. You do not break userland. More generally, your consumer, but once an ABI is in the kernel it cannot be dropped.


I know that Linus has made that clear many times before.

Just because they wrote kdbus it doesn't mean they get a free hand in doing whatever they want, when and if it gets included into the mainline kernel. If it has warts then it will have warts the rest of it's life.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Thu Jan 22, 2015 11:27 pm    Post subject: Reply with quote

This just makes me want to shake my head

Quote:
The fact that there is no performance-critical application using DBus
is, imho, an argument *pro* kdbus. People haven't been capable of
making classic dbus1 fast enough for low-latency audio, thus, we
present kdbus.


What the hell is dbus being used for "audio". Use your bastard child pulseaudio

Quote:
Starting up 'gdm' sends ~5k dbus messages on my machine. It takes >1s
to transmit the messages alone. Each dbus1 message has to be copied 4
times for each direction.


This is just insane, 5k messages...for "gdm", and multiple copying of the messages. :roll:

Sounds like an ill thought out design (dbus).
Design it right and then there probably won't be a need for kdbus to speed it up :roll:
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1791

PostPosted: Fri Jan 23, 2015 4:00 am    Post subject: Reply with quote

I find this funny, that someone would assume that a group that has no clue what they are doing in linux pick DBUS for a good reason. This is going over the part of where the automotive group's software supposedly sends over 500k messages through dbus. If that group actualy knew what they were doing, after seeing dbus being so crappy and slow, they would have switched away from dbus where they would of had this problem.

http://lkml.iu.edu/hypermail/linux/kernel/1501.2/02263.html
Greg Kroah-Hartman wrote:
I tend to trust that they knew what they were doing, they wouldn't have
picked D-Bus for no good reason.


I liked Johannes Stezenbach responce (on next msg in the thread) in what the automative group actually would do.
Quote:
The automotive developers I had the pleasure to work with would
use anything which is available via a mouse click in the
commercial Embedded Linux SDK IDE of their choice :)
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Jan 23, 2015 5:25 am    Post subject: Reply with quote

YDIW wrote:
The fact that there is no performance-critical application using DBus is, imho, an argument *pro* kdbus.
People haven't been capable of making classic dbus1 fast enough for low-latency audio, thus, we present kdbus.

Anon-E-moose wrote:
This just makes me want to shake my head.

What the hell is dbus being used for "audio".

Yeah that's just dumbass, pure and simple. Use jack ffs.

Separate control from data, and put control down a reliable channel like message queues, which allow you to launch a thread when a message arrives on an empty queue, with no thread waiting to service the request, as well as to prioritise should the application need it.
Quote:
Use your bastard child pulseaudio

Lul. "You couldn't do audio right, so now you want to shove it in the kernel instead?" Same as the rest..

YDIW wrote:
Starting up 'gdm' sends ~5k dbus messages on my machine.
It takes >1s to transmit the messages alone.
Each dbus1 message has to be copied 4 times for each direction.

Quote:
This is just insane, 5k messages...for "gdm", and multiple copying of the messages.
Sounds like an ill thought out design (dbus).
Design it right and then there probably won't be a need for kdbus to speed it up

Absolutely. That's just nuts.

From the school of YDIW.. no thanks.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3505

PostPosted: Fri Jan 23, 2015 12:39 pm    Post subject: Reply with quote

steveL wrote:

As for this:
David Herrmann wrote:
We know, that our API will not be perfect, none is. But we will try hard to fix anything that comes up, as long as we can. And this effort will manifest in ABI-breaks.

No. You do not break userland. More generally, your consumer, but once an ABI is in the kernel it cannot be dropped.

That's why you do things in userland instead, and even there people use simple APIs like LADSPA, and hide the complexity instead of exposing everyone to it, as if that were clever instead of dumb.

I don't see this going well, given the encouraging noises being made toward the kdbus "developers".
Though again, we should be using TIPC.


It's clear that Linus doesn't care about userspace much, as shown by his easy acceptance of systemd. He has also made some of the "World Domination" remarks from time to time, and may well see the linkage between systemd and that. Now with kdbus, systemd is about to hit him where he lives.

A few weeks back when I finally got around to removing *kit from my own system I also set USE="-dbus", then put entries in package.use as needed, though I may revisit this at some point and try harder to get rid of it. In the meantime I'm barely dependent on it. (This has prompted me to look harder att his topic - I really rather like "notification", which is probably what now drives dbu for me, and may be an acceptable use/role for it.)

Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show. (Hot chocolate and an added blanket might be more appropriate for this time of year.) I believe Linus' easy acceptance of systemd is about to get challenged as they try to shove not just their code, but their methodology and philosophy, into the kernel.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
tclover
Guru
Guru


Joined: 10 Apr 2011
Posts: 516

PostPosted: Fri Jan 23, 2015 1:28 pm    Post subject: Reply with quote

depontius wrote:
A few weeks back when I finally got around to removing *kit from my own system I also set USE="-dbus", then put entries in package.use as needed, though I may revisit this at some point and try harder to get rid of it. In the meantime I'm barely dependent on it. (This has prompted me to look harder att his topic - I really rather like "notification", which is probably what now drives dbu for me, and may be an acceptable use/role for it.)


Exactly! ... barely depending on it for... guess... JACK: *notification* to start a server when need be. I don't usually start JACK server myself, even if I could do it manually and simply. I just leave it to LADI to handle it when need be: start a particular studio with clients & connect clients to the server in a portable manner... JACK died? restart the same studio with the client connections and possibly new client connections not saved in the *studio*. Can you imagine that pain in the arse to do this kind of repetitive task again and again? I'd rather use my sparse time for meaningful things instead. Barely depending on it for this particular usage... and barely stand it for its cluster fuck & buggy implementation. Checkout this hilarious post (Patrick's Playground Blog): http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt

So, I am curious to see what the kernel maintainers would threw at it and what the kDbus folks will do.

I am not in the least interested in the 5K gdm's start up message madness... but having a sane/simple & low latency implementation IPC (--I realize that, this is not exactly their plan, but the review could do something... maybe I am wishing too much--) would surely serves something... like getting rid of D-Bus. It's feel like a cat bitting its tails, right? Anyway, I am following the review.

I could go on in a similar manner for udev. I can pretty much manage quick migration with mdev, and this might necessary in a near future rather than later because eudev is not so much of a fork... with lack of dev manpower. But, I still need device hotplug in X session. LVM2 (hard) dependency is not an issue... could get rid of it completely with GPT partitioned disks.

depontius wrote:
Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show. (Hot chocolate and an added blanket might be more appropriate for this time of year.) I believe Linus' easy acceptance of systemd is about to get challenged as they try to shove not just their code, but their methodology and philosophy, into the kernel.


Sure... funny times awaits the more adventurous ones... right? Well, maybe not with such people & methodology.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3505

PostPosted: Fri Jan 23, 2015 2:28 pm    Post subject: Reply with quote

tclover wrote:

depontius wrote:
Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show. (Hot chocolate and an added blanket might be more appropriate for this time of year.) I believe Linus' easy acceptance of systemd is about to get challenged as they try to shove not just their code, but their methodology and philosophy, into the kernel.


Sure... funny times awaits the more adventurous ones... right? Well, maybe not with such people & methodology.


I'm more thinking of watching the sparks once it become apparent that the kdbus developers want to churn the design in-kernel. In the discussion thread we've been watching, they just stated that as an express reason why they went for ioctl instead of syscall. They plan on churning kdbus. I'm sure that one will sit well. The question will be whether Linus has noticed that comment before first inclusion, or if the fight happens when the churn starts.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
tclover
Guru
Guru


Joined: 10 Apr 2011
Posts: 516

PostPosted: Fri Jan 23, 2015 3:53 pm    Post subject: Reply with quote

depontius wrote:
I'm more thinking of watching the sparks once it become apparent that the kdbus developers want to churn the design in-kernel. In the discussion thread we've been watching, they just stated that as an express reason why they went for ioctl instead of syscall. They plan on churning kdbus. I'm sure that one will sit well. The question will be whether Linus has noticed that comment before first inclusion, or if the fight happens when the churn starts.


Maybe not... but he should now. The guy who tried to justify the choice ioctl vs. syscal just kept throwing random stuff after another without providing any _real_ logical reasons to do so... but "we're doing this way... (wait why already? somebody noticed... wait)". Well, let's hope nobody followed this one.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Fri Jan 23, 2015 6:04 pm    Post subject: Reply with quote

This particular person seems to be taking them to task, so to speak over the design.

Quote:
So, I'm thinking about things such as the following:

* The odd choice of ioctl() as the API mechanism for what should become
a key user-space API. (BTW, which other widely used IPC API ever
took the approach of ioctl() as the mechanism?)

* Weak justifications for unconventional API design choices such
as the 'kernel_flags' above.

* Thin documentation that doesn't provide nearly enough detail,
has no worked examples of the use of the APIs (when it should
contain a multitude of such examples), and has no rationale
for the API design choices [1].

* An API design that consists of 16 ioctl() requests and 20+
structures exchanged between user and kernel space being called
"simple". (Clearly it is not.)

Given a list of points like that, I worry that not nearly enough
thought has been put into design of the API, and certainly would be
very concerned to think that it might be merged into mainline
in the near future.

At this point, I think the onus is on the kdbus developers to
provide strong evidence that they have a good API design, one that
will well serve the needs of thousands of user-space programmers for
the next few decades. Such evidence would include at least:

* Detailed documentation that fully described all facets of the API
* A number of working, well documented example programs that start
(very) simple, and ramp up to demonstrate more complex pieces
of the API.
* Documented rationale for API design choices.

To date, much of that sort of evidence is lacking, and I worry that
the job of proper API design will be left to someone else, someone
who devises a user-space library that provides a suitable
abstraction on top of the current ioctl() API (but may be forced to
make design compromises because of design failings in the underlying
kernel API).


http://lkml.iu.edu/hypermail/linux/kernel/1501.2/05080.html


Edit to add: GKH seems to have gotten hurt feelings here http://lkml.iu.edu/hypermail/linux/kernel/1501.2/05249.html :roll:

Quite frankly I still wonder what his payoff will be for getting kdbus into the kernel.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3505

PostPosted: Fri Jan 23, 2015 6:21 pm    Post subject: Reply with quote

Anon-E-moose wrote:
This particular person seems to be taking them to task, so to speak over the design.

Quote:
So, I'm thinking about things such as the following:

* The odd choice of ioctl() as the API mechanism for what should become
a key user-space API. (BTW, which other widely used IPC API ever
took the approach of ioctl() as the mechanism?)

* Weak justifications for unconventional API design choices such
as the 'kernel_flags' above.

* Thin documentation that doesn't provide nearly enough detail,
has no worked examples of the use of the APIs (when it should
contain a multitude of such examples), and has no rationale
for the API design choices [1].

* An API design that consists of 16 ioctl() requests and 20+
structures exchanged between user and kernel space being called
"simple". (Clearly it is not.)

Given a list of points like that, I worry that not nearly enough
thought has been put into design of the API, and certainly would be
very concerned to think that it might be merged into mainline
in the near future.

At this point, I think the onus is on the kdbus developers to
provide strong evidence that they have a good API design, one that
will well serve the needs of thousands of user-space programmers for
the next few decades. Such evidence would include at least:

* Detailed documentation that fully described all facets of the API
* A number of working, well documented example programs that start
(very) simple, and ramp up to demonstrate more complex pieces
of the API.
* Documented rationale for API design choices.

To date, much of that sort of evidence is lacking, and I worry that
the job of proper API design will be left to someone else, someone
who devises a user-space library that provides a suitable
abstraction on top of the current ioctl() API (but may be forced to
make design compromises because of design failings in the underlying
kernel API).


http://lkml.iu.edu/hypermail/linux/kernel/1501.2/05080.html


Edit to add: GKH seems to have gotten hurt feelings here http://lkml.iu.edu/hypermail/linux/kernel/1501.2/05249.html :roll:

Quite frankly I still wonder what his payoff will be for getting kdbus into the kernel.


The guy who has been doing most of the challenging is a name I don't recognize, not that I recognize very many. Ted Tso did make one comment in the thread, to the tune that this is going to be a mainstream API, kind of shooting a hole in the ioctl() justification.

As for Greg KH having hurt feelings :
http://cs.boisestate.edu/~amit/teaching/552/old/handouts/ols_2006_keynote_files/ols_2006_keynote_21.jpg
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Fri Jan 23, 2015 6:39 pm    Post subject: Reply with quote

LoL

And to add, GKH says that the kdbus devs know what they're doing as they've been at it for 2+ years.

Well, in the world I'm from, constantly changing api's doesn't give a warm fuzzy that they know that they're doing.

And we're seeing justifications all over the place for it, from audio usage to multi kilo messages to well that's the way we designed it, tuff.

They are not going to be able to churn the code if and when it gets included in the kernel, they better think it out properly first.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Sat Jan 24, 2015 3:07 am    Post subject: Reply with quote

depontius wrote:
Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show.

depontius ... that depends on who's driving the train :)

best ... khay
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Jan 24, 2015 6:21 am    Post subject: Reply with quote

steveL wrote:
You do not break userland. More generally, your consumer, but once an ABI is in the kernel it cannot be dropped.

depontius wrote:
It's clear that Linus doesn't care about userspace much, as shown by his easy acceptance of systemd. He has also made some of the "World Domination" remarks from time to time, and may well see the linkage between systemd and that. Now with kdbus, systemd is about to hit him where he lives.

I believe Linus' easy acceptance of systemd is about to get challenged as they try to shove not just their code, but their methodology and philosophy, into the kernel.

Well there's two strands there. I don't expect Torvalds to care about userspace; he's not meant to. He's supposed to stick with the attitude that it can do all kinds of crazy things, as that's the only way for a kernel-side coder to think.

As such he might tut from time to time when he comes up for air, but it's not his problem (and we don't him to lose his focus on the kernel.)

Except as you say, when changes are being pushed into the kernel (the second strand) to paper over userland madness, instead of telling userland to go back to the drawing-board.
Quote:
A few weeks back when I finally got around to removing *kit from my own system I also set USE="-dbus", then put entries in package.use as needed, though I may revisit this at some point and try harder to get rid of it. In the meantime I'm barely dependent on it. (This has prompted me to look harder att his topic - I really rather like "notification", which is probably what now drives dbu for me, and may be an acceptable use/role for it.)

Heh it's funny you should mention that, as I got to this page about inotify following links given above. I rather liked this comment (it made me smile;):
neilbrown wrote:
I wonder what other, possibly less common, use cases there are.

One of my favourites is as a publish/subscribe (aka 'multicast') IPC mechanism. It is a bit clunky, but it can be made to work.
Who needs dbus when you can muck about with files and dnotify :-)
(or inotify, or fanotify? nowadays.)
I just like the idea of eg a simple file with the number of new emails (for instance) which we could watch for modification if we wanted to, a bit like we could watch a /proc directory or file.

At least for the simple cases, keep them simple.

depontius wrote:
Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show. (Hot chocolate and an added blanket might be more appropriate for this time of year.)

Hehe indeed. Though it's also nice to get into the technical stuff as a downtime thing. The other comments on that page are quite interesting, for instance:
wahern wrote:
With kqueue+EVFILT_VNODE you never have to worry about overflow because the kernel always has a place to store the event.
.. OS X Finder does just fine with EVFILT_VNODE. And OS X has the O_EVTONLY descriptor flag, which permits the kernel to unmount volumes with open descriptors.

The latter sounds useful, and one wonders why we can't do the same thing; after all the kernel must know what the fd is for.

Though by the sound of it, you're exploring the options for a dbus-free system much more intensely than most, already :)

Have you tried installing the TIPC kernel module? Just wondering how difficult it is to get that running, even if nothing's actually using it yet, for a testbed. (According to the site, it's part of kernel sources since Linux 2.6.39+, though the utils are downloaded from there.) I really must set aside a couple of days to getting up to date..

Have to say I'm quite impressed, checking out the programming docs, and the draft protocol. The former is loverly, lucid and to the point, and I especially like the tips and caveats ("THINGS TO NOTE" and "THINGS TO REMEMBER"), the latter from a higher-level design view.
TIPC goes back over 15 years, and is still being updated, so it's a live project, and an excellent candidate afaic.

Still, time for some lemonade.. ;-)
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Sat Jan 24, 2015 11:07 am    Post subject: Reply with quote

tclover wrote:
[...] I can pretty much manage quick migration with mdev, and this might necessary in a near future rather than later because eudev is not so much of a fork... with lack of dev manpower. But, I still need device hotplug in X session.

tclover ... device hotplugging does in fact work with mdev, mdev can be configured to react to events and so setup usb devices, etc, so for example:

/etc/mdev.conf
Code:
SUBSYSTEM=usb;DEVTYPE=usb_device;.* root:root 660 */opt/mdev/helpers/proc-bus-usb

/etc/X11/xorg.conf.d/30-mouse.conf
Code:
[...]
  # /dev/input/mice will provide support for hotpluging mouse.
  # Without the need to restart X server.
  option  "device"  "/dev/input/mice"
[...]

The only real issue that anyone might have with dbus removal is the hard dependencies of DE's and/or their expectation that the dbus service will be running (ie, when using consolekit). If you're not using a DE, consolekit, etc, then its quite easy to have everything work without dbus ... well, you have to wrangle with useflags, and setup xorg without evdev, but its fairly simple to do so.

steveL wrote:
Though by the sound of it, you're exploring the options for a dbus-free system much more intensely than most, already :)

What's dbus? :)

Code:
# qlop --gauge dbus | echo $?
0

best ... khay
Back to top
View user's profile Send private message
tclover
Guru
Guru


Joined: 10 Apr 2011
Posts: 516

PostPosted: Sat Jan 24, 2015 11:20 am    Post subject: Reply with quote

Thanks steveL for...
grep -i tipc /usr/src/linux/.config:
# CONFIG_TIPC is not set


I did not know that such an (in-kernel) IPC was available till your previous post about it.

(Could somebody give an overview (short or _high_ level) of it regarding perf/latency/message compared to the infamous D-Bus?

Just asking... because I happen to have requested multiple times "why depending on D-Bus at all?" on a few things I use. And then... "we need an IPC in order to set up a communication between processes and be able to control... & provide functionalities if _this_ or _that_ service is available; and do not want waste ridiculous amount of time doing a _custom_ IPC." No viable alternative to suggest? Well then... D-Bus then.)

EDIT: Anybody noticed this: nobody mentioned TIPC on the review? or did I miss it?
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/


Last edited by tclover on Sat Jan 24, 2015 11:29 am; edited 2 times in total
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Sat Jan 24, 2015 11:26 am    Post subject: Reply with quote

khayyam wrote:
depontius wrote:
Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show.

depontius ... that depends on who's driving the train :)

best ... khay


I read that yesterday, and just shook my head

Quote:
In the end, all is well, and I'm still confused why writing a config file needs dbus and xml and stuff.


It shouldn't need dbus or xml, but that's stuff being driven by...tada...RH

Quote:
But I guess that's called progress ...


Yeah :roll: progress


Re: dbus
I don't have it installed on my system, and don't need it.
Of course I'm running openbox not a full de, but even when I was running lxde I had it turned off.
I don't need notifications.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3505

PostPosted: Sat Jan 24, 2015 11:52 am    Post subject: Reply with quote

khayyam wrote:
depontius wrote:
Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show.

depontius ... that depends on who's driving the train :)

best ... khay


I just noticed - that was supposed to be "a train wreck might", not "a train might". Oops.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3 ... 5, 6, 7 ... 25, 26, 27  Next
Page 6 of 27

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum