Originally posted by asdfblah
View Post
Announcement
Collapse
No announcement yet.
Using Udev Without Systemd Is Going To Become Harder
Collapse
X
-
-
Originally posted by gens View Postagain, check out the protocols
netlink IS simpler and since it is not buffered it is, theoretically, lower overhead (and since it is not buffered it supports "mmaped" IPC, and there is no faster IPC then direct memory sharing)
firmware is just a bunch of bytes that the kernel sends to a device
how you get it to the kernel is another topic (in most cases the kernel gets it itself and that's why firmware is in /lib/firmware/, a path hardcoded in the kernel)
if you ask me there is nothing wrong with sending it over netlink
further more netlink is the standard to talk low level to device drivers
if i am wrong feel free to tell me why (and no "future" please, i like science more)
The firmware was never sent over netlink (only the request was), and it will never be sent over kdbus. Anyway, what you are talking about here is userspace-kernelspace communication, where there is no plans to introduce kdbus.
Comment
-
Originally posted by tomegun View Postkdbus also does "mmaped" IPC, but without the limitations (multithreading is ok) and security problems (sealing) of netlink.
The firmware was never sent over netlink (only the request was), and it will never be sent over kdbus. Anyway, what you are talking about here is userspace-kernelspace communication, where there is no plans to introduce kdbus.
shm kdbus doesn't thou, guess that is an extension
... still doesn't, guess i'l have to go back to reading the protocol (unless it changed much for kdbus)
so if netlink was made to replace ioctl in userspace - driver comunication then why use kdbus ?
i find netlink so-so simple and effective, guess that's just me
Comment
-
Originally posted by Delgarde View PostWell, if you live in a perfect world, perhaps. But practically speaking, we don't. Modularity is a useful tool, but nothing more, and it's a hindrance as often as a help. All those little modules, all those separated concerns - they need to talk to each other, and that's a big piece of complexity right there. What happens if the requirements change, and one module needs extra information from another one? So you add that extra information to the interfaces? That's great, but then you find that someone else has provided a different implementation of those interfaces, and your changes have broken that implementation, and you don't have the ability to fix it. Now what?
See, don't get me wrong - modularity is a useful tool. But all that extra structure that goes with it - that's extra complexity, and you pay the price for having it.
so we have:
IFoo{
MemberA();
}
IBar:IFoo{
MemberA();
//some purpose
MemberB();
}
IBaz:IFoo{
MemberA();
//some completely different purpose
MemberB();
}
and then you cast to the expected behavior.
Ideally yes you wouldn't have that redundancy but an interface is a promise, and if they're doing incompatible things they're not the same interface.
Comment
-
Originally posted by gens View Postabout the firmware loading, now that you say it makes sense
shm kdbus doesn't thou, guess that is an extension
... still doesn't, guess i'l have to go back to reading the protocol (unless it changed much for kdbus)
so if netlink was made to replace ioctl in userspace - driver comunication then why use kdbus ?
i find netlink so-so simple and effective, guess that's just me
Comment
-
Originally posted by asdfblah View PostRead this: http://lkml.iu.edu/hypermail/linux/k...4.0/01331.html . From this, you can infer that Kay *WAS* writting (alongside Greg) KDBus, and it seems to be the case: https://github.com/gregkh/kdbus/graphs/contributors .
Comment
-
Originally posted by tomegun View PostYou want to look up "memfd". They are used when the data being transfered is bigger than a certain size (otherwise doing a copy is faster).
They are used for different things. kdbus is userspace to userspace, netlink is userspace to kernelspace. It is possible to use netlink for userspace to userspace, but it is not really nice (which is what udev is currently doing, and why we want to move that to kdbus).
Yeah, it is very simple, but probably too simple in some respects. It is also not very efficient, at least not for rtnetlink (which is what I have worked with), as there is a global lock on the kernel side which means that the interface is essentially synchronous. That would not happen with kdbus (had the kernel been ported to use that for userspace-kernelspace communication, which of course it will not be).
from what i see it's shm fd with toggleable owner, will check more when i get time
so kdbus won't be used to tell the kernel anything ?
its just for userspace coordination ?
netlink is a RAW/DGRAM based protocol
so how i see it, it can't be slower then an OO based protocol unless parsing on one side takes too long
can't say why would interacting with the routing tables be any faster using a buffered protocol instead of a synchronous one, netlink like a normal socket can send gigabytes per sec
unless the kernel side is poll based instead of event based, but even then
can you dump a bunch of commands at once, and if you can you could over a netlink multipart msg
too much idk here
Comment
-
Originally posted by Teho View PostTo fix what for him? You do understand that this change is only problematic to non-systemd user and I doubt he cares if non-systemd do nothing about it (like they usually don't)? You don't need to fix anything but if you want to have up-to-date udev you have do some work for once. Also Lennart isn't the one working on udev, Kay Sievers is.The udev built from the systemd source tree will stay compatible with
non-systemd init systems for a long time. This change is mostly a
detail of the build scheme, rather than a change of direction or
interfaces. Accordingly, the libudev API is untouched by these build
infrastructure changes. For us, compatibility is key.
Apparently, a long time is for him a little more than two years, and apparently compatibility is not key anymore.
Seriously, a sentence from Poettering like "Gentoo folks, this is your wakeup call." in reality comes down to: "The Gentoo people are actually the only ones of the non-systemd distros that have the manpower to handle this change in a proactive way, all other non-systemd distros better bow to us or keep using outdated udev forever. Now that Debian and Ubuntu have decided to change to our side we can show our real intentions and start with the small distros that can't handle the changes due to lack of manpower. Resistance is futile!"
Don't get me wrong, I actually like systemd and its concepts, but it is its developers attitudes and actions like this that prevent me from using it.
Comment
-
Originally posted by gens View Postmemfd looks good
from what i see it's shm fd with toggleable owner, will check more when i get time
so kdbus won't be used to tell the kernel anything ?
its just for userspace coordination ?
netlink is a RAW/DGRAM based protocol
so how i see it, it can't be slower then an OO based protocol unless parsing on one side takes too long
can't say why would interacting with the routing tables be any faster using a buffered protocol instead of a synchronous one, netlink like a normal socket can send gigabytes per sec
unless the kernel side is poll based instead of event based, but even then
can you dump a bunch of commands at once, and if you can you could over a netlink multipart msg
too much idk here
The way rtnetlink works is that your sendmsg() call will only return after the message has been fully processed (i.e., not only parsed, but the kernel will have finished changing your mac addresses or configuring your routing table before sendmsg() returns). If you only ever want to send one synchronous message, that is fine, but if you (as I do) want to send lots of unrelated asynchronous messages from a single-threaded application, it sort of sucks.
Comment
Comment