Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Discussing vdev from Devuan Project
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3, 4  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
KuroNeko
n00b
n00b


Joined: 08 Oct 2014
Posts: 23

PostPosted: Mon Jan 05, 2015 10:54 pm    Post subject: Discussing vdev from Devuan Project Reply with quote

I think most of you already took notice of vdev.
I think its configuration syntax is rather easy to read, might worth to check it out:
https://github.com/jcnelson/vdev/commit/e82e98eb1991a853d81327426519d6be024b1eff

It also looks rather nice, because it would make (almost completely) logind useless and could be used on different kernels beside linux. What do you think about it?

Neko

Split from systemd or openrc - which one do you use? as it deserves its own topic. — JRG
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


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

PostPosted: Tue Jan 06, 2015 1:45 pm    Post subject: Reply with quote

KuroNeko wrote:
I think most of you already took notice of vdev.
I think its configuration syntax is rather easy to read, might worth to check it out

Thanks the project looks interesting.
Quote:
It also looks rather nice, because it would make (almost completely) logind useless and could be used on different kernels beside linux. What do you think about it?

Unfortunately it's in C++. There are parts that are in C, but personally I wouldn't want to try and convert the whole project. I realise it says "Since vdev is a filesystem, it exposes its API as a directory hierarchy instead." (so C library and dbus are not needed) and "vdev will ship with a udev compatibility library." However I'm not happy with C++ in core-system, so would want to pursue a different course, even if that were just stealing mostly ;)

I'm not even sure atm that we need to replace eudev, though I'm certainly glad someone is working on a more-portable project. Personally I don't see any reason why apps should be udev-aware. The most that needs to be aware of devices is the DE, not individual programs.
Back to top
View user's profile Send private message
judecn
n00b
n00b


Joined: 07 Jan 2015
Posts: 17

PostPosted: Wed Jan 07, 2015 4:00 am    Post subject: Reply with quote

Quote:
Unfortunately it's in C++. There are parts that are in C, but personally I wouldn't want to try and convert the whole project. I realise it says "Since vdev is a filesystem, it exposes its API as a directory hierarchy instead." (so C library and dbus are not needed) and "vdev will ship with a udev compatibility library." However I'm not happy with C++ in core-system, so would want to pursue a different course, even if that were just stealing mostly ;)

I'm not even sure atm that we need to replace eudev, though I'm certainly glad someone is working on a more-portable project. Personally I don't see any reason why apps should be udev-aware. The most that needs to be aware of devices is the DE, not individual programs.


Hi steveL, vdev author here.

You aren't the first to feel discouraged about my use of C++ for vdev ;). However, I would like to point out that I'm taking extra care to avoid the nasty parts of the language--the only part C++ I'm using in any serious capacity is the STL. Both vdev and its dependencies are otherwise very C-like in structure and have C linkage, so you won't find yourself needing to recompile everything from scratch on each upgrade.

I totally agree with you that apps should not need to be aware of the device manager. To meet this goal, vdev exposes all the information you might need to query via libudev as files, directories, and extended attributes. You shouldn't even need a udevadm-like tool; all that is needed to get the same information is a basic understanding of vdev's filesystem layout (which will be extensively documented when all is said and done).

I also appreciate the need for scriptable behavior, but in a way that strikes a balance between mdev's and udev's approaches (i.e. don't make the user do everything, but don't create an inner platform either). vdev takes care of matching a device event to one or more scripts to run (i.e. the user supplies matching criteria as key/value pairs), and the scripts take care of performing device renaming and any device-specific initialization or teardown. vdev guarantees a that set of OS-agnostic matching criteria will always be present (i.e. name-matching regex, major/minor number, etc.), but it also allows the OS-specific back-end to supply additional matching criteria if desired (i.e. subsystem, sysfs attributes, firmware name, etc.).

To ease the transition, I'm shipping vdev with a set of action definitions, helper programs, and scripts that will provide a /dev layout on Linux that is as close to what udev provides as possible, and eventually we'll have a tool that will compile udev rules into vdev action definitions and scripts. At some point, we'll also have a libudev-compat and libgudev-compat to satisfy legacy application dependencies on udev.

I've published a detailed overview of vdev here, which covers the design, implementation, and development roadmap. Any/all feedback and criticism is welcome; I'd rather fix glaring problems now while there's still time to "design" them away instead of trying to hack them away after a few releases. Thanks!
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Wed Jan 07, 2015 11:15 am    Post subject: Reply with quote

steveL wrote:
I'm not even sure atm that we need to replace eudev, though I'm certainly glad someone is working on a more-portable project.


I'm glad there are alternatives, because I think that eudev is following udev just a touch too close, in other words not much difference between them, just look at the 2 versions to see this.

Nice post, judecn
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 4.4.6-zen, glibc-2.21, gcc-4.9.3, eudev
xorg-server-1.18.0 w/mesa-13.0, openbox, nouveau and radeon, oss4(2011)
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 5427

PostPosted: Wed Jan 07, 2015 12:05 pm    Post subject: Reply with quote

Code:
https://github.com/jcnelson/vdev/blob/master/Makefile
PREFIX ?= /usr
BINDIR ?= $(PREFIX)/bin
cp -a $(VDEV) $(BINDIR)

You randomly pickup that path or do you have some kind of "usrisbroken" link too?
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3110

PostPosted: Wed Jan 07, 2015 1:05 pm    Post subject: Reply with quote

Now that we're talking about vdev, and after having read the introduction, I've been mulling another perspective on systemd vs the world. It has been touched on in various ways on various forum threads. I may be rewording what has been said before, I'd prefer to think this is a condensation.

It comes down to this, where does policy reside?

Linus has been rather admant about keeping policy out of the kernel. Unforuntately policy has been something of a hot potato, largely because it's boring, unpopular work. Linus is right, in that policy should not be in the kernel, rather the mechanisms for implementing and enforcing it should be, but the policy itself should be in userspace. For the most part users don't want to fuss with it either, they just want policy that gives them a secure system and doesn't get in their way. Most of the time they also don't realize that those two goals are completely inconsistent. Thus far it seems that package owners usually don't want to own policy either, probably because it generates too many bugs, and you can't come up with one-size-fits-all - someone is always going to complain. So I suspect that by default policy ownership defaults to the distributions, and that policy actually ends up being a fairly significant distinguishing feature between distributions. It's also a rather thankless job, once again because nothing will satisfy everyone.

Enter systemd, which seems to embrace policy ownership. Since policy is so difficult to get right, and so thankless, it seems that most distrbutions are happy to let systemd have that piece of the pie. At the moment I don't think they've realized that they're also surrendering their differentiation as well - their reason to exist. There is also something really odd about the social networking situation surrounding systemd - if you don't like the systemd way, you're <insert deprecating adjective(s) here> and are just plain wrong. So far systemd is getting away with setting the default policy wherever it's used. I presume it's possible to change that default policy, but from what I can see it's harder to do than /etc/sudoers or /etc/pam.d/*.conf, takes a lot more learning, etc. So distributions are doing less of it, let alone end users.

I welcome vdev. I'm a little leery of C++ in that low-level a role, as are others. I would say that one of the most important things, along with all of the other most important things you've mentioned, will be some sample policies, for use as learning tools and pick-one-to-use.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
saellaven
Guru
Guru


Joined: 23 Jul 2006
Posts: 445

PostPosted: Wed Jan 07, 2015 3:16 pm    Post subject: Reply with quote

judecn wrote:

You aren't the first to feel discouraged about my use of C++ for vdev ;). However, I would like to point out that I'm taking extra care to avoid the nasty parts of the language--the only part C++ I'm using in any serious capacity is the STL. Both vdev and its dependencies are otherwise very C-like in structure and have C linkage, so you won't find yourself needing to recompile everything from scratch on each upgrade.


combined with krinn's observation that you're installing in /usr...

if you're using libstdc++ you are already a no-go for me as it's installed in /usr and I have /usr mounted separately for a reason.

If you want to be a device manager, you have to be prepared to use a minimal set of libraries (preferably none), particularly those found in /lib, or else you're doing one of the biggest things I object to regarding systemd - arrogantly assuming that the system is setup the way (and only the way) YOU want it to be setup. A device manager that depends on devices already being up isn't much of a device manager, it's more of a post-boot toy to make hotplugging easier.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


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

PostPosted: Wed Jan 07, 2015 7:38 pm    Post subject: Reply with quote

Quote:
Unfortunately it's in C++. There are parts that are in C, but personally I wouldn't want to try and convert the whole project. I realise it says "Since vdev is a filesystem, it exposes its API as a directory hierarchy instead." (so C library and dbus are not needed) and "vdev will ship with a udev compatibility library." However I'm not happy with C++ in core-system, so would want to pursue a different course, even if that were just stealing mostly ;)

judecn wrote:
You aren't the first to feel discouraged about my use of C++ for vdev ;).

Oh, I'm not discouraged. ;-) (And hi, good to see another gentoo user coding for early-init.)
Quote:
However, I would like to point out that I'm taking extra care to avoid the nasty parts of the language--the only part C++ I'm using in any serious capacity is the STL. Both vdev and its dependencies are otherwise very C-like in structure and have C linkage, so you won't find yourself needing to recompile everything from scratch on each upgrade.

I won't use it at all if it's in C++. Period.

Not expecting you to change anything, ofc; just don't expect me to change my stance, as it'd only be a waste of both our time.
Quote:
I totally agree with you that apps should not need to be aware of the device manager. To meet this goal, vdev exposes all the information you might need to query via libudev as files, directories, and extended attributes. You shouldn't even need a udevadm-like tool; all that is needed to get the same information is a basic understanding of vdev's filesystem layout (which will be extensively documented when all is said and done).

That sounds better, but it's still awareness of the device manager. And I don't see what for. Yes this sounds like a basic complaint, or a luddite appeal if you prefer, but I'd still like to know exactly why this is so important to anything more than a few low-level things which have nothing to do with applications. If someone thinks it's relevant at the desktop app level, as opposed to the DE (and its file-manager) level, all I'd say is "YDIW".
Quote:
I also appreciate the need for scriptable behavior, but in a way that strikes a balance between mdev's and udev's approaches (i.e. don't make the user do everything, but don't create an inner platform either). vdev takes care of matching a device event to one or more scripts to run (i.e. the user supplies matching criteria as key/value pairs), and the scripts take care of performing device renaming and any device-specific initialization or teardown. vdev guarantees a that set of OS-agnostic matching criteria will always be present (i.e. name-matching regex, major/minor number, etc.), but it also allows the OS-specific back-end to supply additional matching criteria if desired (i.e. subsystem, sysfs attributes, firmware name, etc.)

Sounds reasonable. As you say, it's all points on a curve that has already been explored, although the format isn't quite as nice as it could be (which is what I'm currently poking jrg about, if he'd deign to respond..;)

Main thing that annoys me intensely is XML in the base system. (Yes I realise the rules are compiled, for anyone who wants to poke holes.)
Quote:
At some point, we'll also have a libudev-compat and libgudev-compat to satisfy legacy application dependencies on udev.

Well personally I'd rather just remove the apps, but w/e floats your boat.

It does strike me that everyone's very quick to talk about "legacy" when I wouldn't call any of this anything that I'd expect to be around in 20 years. It's more "evolutionary dead-end" than "legacy", imo.
Quote:
I've published a detailed overview of vdev here, which covers the design, implementation, and development roadmap. Any/all feedback and criticism is welcome; I'd rather fix glaring problems now while there's still time to "design" them away instead of trying to hack them away after a few releases. Thanks!

Sure: imagine for a second that "multi-seat" is a dead-end (since to do it properly we use LTSP, and matching USB nodes isn't that hard in any case), and so is "equivocating" devices on behalf of processes (since that's the kernel's job, and we have namespaces so Linux has finally caught up with BSD.)
The design would be a lot simpler and cleaner, no?
Back to top
View user's profile Send private message
judecn
n00b
n00b


Joined: 07 Jan 2015
Posts: 17

PostPosted: Wed Jan 07, 2015 7:46 pm    Post subject: Reply with quote

krinn wrote:
Code:
https://github.com/jcnelson/vdev/blob/master/Makefile
PREFIX ?= /usr
BINDIR ?= $(PREFIX)/bin
cp -a $(VDEV) $(BINDIR)

You randomly pickup that path or do you have some kind of "usrisbroken" link too?


I'd like to support a separate /usr if at all possible. While there are a couple of library dependencies in /usr that can be removed from vdev (i.e. OpenSSL just for a SHA256 implementation, which is negotiable), the only other dependency on /usr being available when vdev starts is libstdc++. That's going to be harder to remove, but not impossible--the only STL classes I use are vector, pair, map, and queue (and I'm all ears for a C library that installs to /lib that can supply equivalent functionality).

Out of curiosity, is there a reason why libstdc++ normally isn't installed under /lib?
Back to top
View user's profile Send private message
tclover
Guru
Guru


Joined: 10 Apr 2011
Posts: 511

PostPosted: Wed Jan 07, 2015 9:01 pm    Post subject: Reply with quote

judecn wrote:

Out of curiosity, is there a reason why libstdc++ normally isn't installed under /lib?


It's part of gcc, so it's installed in `/usr/lib/gcc/$HOST/$VERSION'... not that easy to move because it's part of the toolchain.

I've read the README file on gihub... and was going to say nice... well, I was surprised with the implementation (FUSE).
Why not after all... but it will bring library dependencies in `/usr/lib' that pile up on the C++. I don't know what to say even if the features looks interesting, and then, maybe a little misplaced to have a neat/lean/efficient device manager.
_________________
home/:mkinitramfs-ll/:supervision(-scripts)/:e-gtk-theme/:(bar-)overlay/
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Wed Jan 07, 2015 9:26 pm    Post subject: Reply with quote

one could always statically link libstdc++ (it is A solution)
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 4.4.6-zen, glibc-2.21, gcc-4.9.3, eudev
xorg-server-1.18.0 w/mesa-13.0, openbox, nouveau and radeon, oss4(2011)
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 5427

PostPosted: Thu Jan 08, 2015 3:02 pm    Post subject: Reply with quote

judecn wrote:

I'd like to support a separate /usr if at all possible. While there are a couple of library dependencies in /usr that can be removed from vdev (i.e. OpenSSL just for a SHA256 implementation, which is negotiable), the only other dependency on /usr being available when vdev starts is libstdc++. That's going to be harder to remove, but not impossible--the only STL classes I use are vector, pair, map, and queue (and I'm all ears for a C library that installs to /lib that can supply equivalent functionality).

Out of curiosity, is there a reason why libstdc++ normally isn't installed under /lib?

Might be a hint why C++ isn't that nice for system tools. Anyway, even you may can't live without /usr/lib stuff link to your program, this doesn't prevent you from stopping this madness and get back to "sane practise" with pathname ; if your program cannot work because of some deps are in /usr/lib we may put blame on the libs and user may try himself to find what he consider a solve (static libs, symlink...), but at least, user will not have to fight with vdev design.
Don't forget "nix way": what appears impossible to do in vdev, could be magically made by vdev-ssl that need openssl while vdev-boot (sorry steveL i love to invent names) doesnt have any deps that belongs to /usr. vdev doesn't need to be a one tool with all deps in it.
Back to top
View user's profile Send private message
judecn
n00b
n00b


Joined: 07 Jan 2015
Posts: 17

PostPosted: Sat Jan 10, 2015 4:05 am    Post subject: Reply with quote

Thank you everyone for your feedback. It has given me some helpful insights into how to work on vdev going forward.

I should point out I'm coming from the Debian (and Devuan) community, and I'm motivated to create vdev because I need a long-term replacement for udev and parts of ConsoleKit/systemd-logind. This is a nights/weekends project for me; I use systemd at my $DAYJOB but for various reasons I'm not comfortable relying on it for my personal machines. Unfortunately, udev's eventual merger with systemd threatens to leave a lot of non-systemd Linux users wanting for dynamic device management, and it's not clear to me how the merger will affect the eudev project (but I think it's clear that udev upstream doesn't want to have to care). To avoid a repeat of the political fallout the merger is causing, I've been asking around the community to get a sense of what people currently expect from a device file manager *before* releasing it, so I can design vdev around its potential users' needs from the get-go.

That said, let me take a moment to address some of the concerns in this thread regarding vdev:

vdev relies on libraries installed to /usr, in particular libstdc++. (Thanks to saellaven, depontius, and krinn for bringing this up).

I'm embarrassed to admit it, but this did not occur to me when I started vdev, since all of my previous Linux, FreeBSD, and OpenBSD installs had /usr on the same physical disk as /. I didn't know it was a problem, and I apologize if I came off as arrogant for overlooking this. I will take steps in vdev to remove dependencies on /usr, including libstdc++ (as I mentioned earlier, the dependency is still small enough that removing it now is feasible).

Multi-seat setups and dependencies on a device manager are an evolutionary dead end. (Thanks to steveL for bring this up).

Regarding dependency on a device manager, I agree that dependency on a particular device manager implementation is a bad idea. This is why vdev's public API is the filesystem--regardless of what agent manages device nodes and the /dev directory structure (be it a program, a filesystem, or the administrator), the semantics of /dev will be defined independently of the implementation. The reasoning behind this design choices is that it would make coupling programs to vdev difficult, since neither I nor other userspace programmers get to control the semantics of the interface. Moreover, it looks to me like libudev API really just wraps functionality which can already be found in the VFS, so making a libudev-compat shouldn't be a big issue down the road (but to be fair, it seems that this is going to be more of an issue for binary distributions than source distributions like Gentoo, since the latter offer more freedom to compile out libudev dependencies).

Regarding multi-seat being a dead-end, I agree in principle--I think it's clear that with the cost of storage and computing falling as quickly as they are, multi-seat as we know it today (and probably LTSP) will be remembered historically as a stop-gap solution until there were enough cheap, reliable personal computers for everyone. Nevertheless, this need is still here today and I think it will be here for a while (and I personally find some aspects of it useful, particularly in the context of reasoning about policies governing device node access in containers). Fortunately, the functionality that implements per-process access control is well-isolated from the rest of vdev--there is already a plan to make it possible to compile this out if it isn't needed.

vdev doesn't need to be a one tool with all deps in it. (Quoting krinn directly).

I totally agree. Moreover, I never want users to feel like they have to fight vdev's design, nor would I ever want to compel the adoption of a bad design. I can add built targets for equivalents of vdev-boot and vdev-ssl or the like, to support multiple configurations (although I should point out that the ssl dependency lives in libpstat, not vdev, and compiling it out there will eventually be a supported compile-time option).

I've read the README file on gihub... and was going to say nice... well, I was surprised with the implementation (FUSE). (Thanks to tclover for pointing this out).

The key benefit of FUSE is that it can tell vdev which task is trying to access which device node, which is necessary for it to be able to hide device nodes from unprivileged processes. However, as mentioned above, this will be something that can be compiled out if it's not needed. Because the access control logic lives underneath the filesystem, other programs shouldn't break if it is missing since it doesn't affect POSIX filesystem semantics (but the user might need to take different steps to keep unprivileged programs from accessing privileged device nodes).

Again, thank you all for taking the time to give me useful feedback. If there are more concerns, please don't hesitate to let me know.
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2113

PostPosted: Sat Jan 10, 2015 4:18 am    Post subject: Reply with quote

judecn wrote:
it's not clear to me how the merger will affect the eudev project
The merge was a big reason why eudev was born.
_________________
First things first, but not necessarily in that order.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 36528
Location: 56N 3W

PostPosted: Sat Jan 10, 2015 9:44 am    Post subject: Reply with quote

The Doctor,

I think is more a question of how long eudev will be able to track udev by porting systemd-udev code.
At some point, to keep eudev alive it will need to reverse engineer systemd-udev functionality and reimplement it, or even diverge altogether. Thats much harder as eudev will also need to implement the functionality of systemd-udev bugs. Someone somewhere will write code that depends on the bugs. Ask AMD when they first made their own Intel compatible processor.

Personally, I don't see eudev as more than a stop gap and a way to keep the worst excesses of systemd in check, while eudev lives anyway.

judecn,

Being a bit of a dinosar, I have a static /dev. It all seems to work for me. I realise its not for everyone. I think its useful to keep the old ways alive because the day may come when its systemd or static.
I know which one I want, or maybe its choose the least worst.

Good luck with vdev and Devuan.
Debian missed an opportunity to stop the Red Hat rot. The choice was really drop Gnome or adopt systemd. They made the wrong choice for the entire FOSS community.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3110

PostPosted: Sat Jan 10, 2015 11:45 am    Post subject: Reply with quote

NeddySeagoon wrote:

I think is more a question of how long eudev will be able to track udev by porting systemd-udev code.
<snip>
Good luck with vdev and Devuan.
Debian missed an opportunity to stop the Red Hat rot. The choice was really drop Gnome or adopt systemd. They made the wrong choice for the entire FOSS community.


I don't see why eudev needs to track udev, necessarily. At some point the code base is necessarily going to diverge, if only because systemd is going to do something silly to udev. The key decision will be when to allow that divergence, and how much to attempt to pick up from systemd-udev after.

I liked the idea of Devuan, but am not happy that they appear to be shim-dependent. Personally, I'm in the "middle-shim" camp, meaning that I see shims as a way away from systemd-nonsense. There are others here in the no-shim-at-all / give-no-quarter camp. Devuan appears to be heading down the shim-forever path.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
jonathan183
Apprentice
Apprentice


Joined: 13 Dec 2011
Posts: 215

PostPosted: Sat Jan 10, 2015 3:17 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Being a bit of a dinosar, I have a static /dev. It all seems to work for me. I realise its not for everyone. I think its useful to keep the old ways alive because the day may come when its systemd or static.
I know which one I want, or maybe its choose the least worst.

Good luck with vdev and Devuan.
Debian missed an opportunity to stop the Red Hat rot. The choice was really drop Gnome or adopt systemd. They made the wrong choice for the entire FOSS community.

I'm going with mdev for the moment ... but if it comes to a systemd or static dev then I'll be using static.
I also think Debian made the wrong choice - but they need to live with it or change it ...
Back to top
View user's profile Send private message
szatox
Veteran
Veteran


Joined: 27 Aug 2013
Posts: 1155

PostPosted: Sat Jan 10, 2015 6:43 pm    Post subject: Reply with quote

I just wonder why would a device manager depend on openssl :roll:
Back to top
View user's profile Send private message
judecn
n00b
n00b


Joined: 07 Jan 2015
Posts: 17

PostPosted: Sat Jan 10, 2015 9:04 pm    Post subject: Reply with quote

szatox wrote:
I just wonder why would a device manager depend on openssl :roll:


Technically, it doesn't. One of its dependencies, libpstat, does. libpstat is a library I wrote for getting extra information about a running process in an OS-agnostic way. One tidbit of information it can get for you is the SHA256 of the process binary. I'm going to make it possible to compile this out, so libssl won't need to be installed for vdev to work.
Back to top
View user's profile Send private message
judecn
n00b
n00b


Joined: 07 Jan 2015
Posts: 17

PostPosted: Sat Jan 10, 2015 9:11 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Being a bit of a dinosar, I have a static /dev. It all seems to work for me. I realise its not for everyone. I think its useful to keep the old ways alive because the day may come when its systemd or static.
I know which one I want, or maybe its choose the least worst.


One feature request in the works is adding mdev-like functionality to vdev. It would be possible to run it once, and it would create all of the device nodes in /dev for devices that are currently plugged into your system and take any admin-supplied device-specific actions on them as they get discovered. You could also run it periodically, and vdev would remove unneeded device nodes, add new ones, and take device-specific actions for you. Would you and others that prefer static /dev find this useful?
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 3776
Location: UK

PostPosted: Sat Jan 10, 2015 11:53 pm    Post subject: Reply with quote

Don't blindly default to the worst possible option just because everyone else does it. I suspect there would've been less protests if not for the choice of library.
Code:
~ # for i in /var/db/pkg/dev-libs/{libsodium,openssl}-*; do echo "$(<$i/PF):"; awk '/obj \/usr\/lib.*.so[.0-9]+ / { print $2 }' $i/CONTENTS | xargs du -shc; done
libsodium-1.0.1:
328K   /usr/lib64/libsodium.so.13.0.3
328K   total
openssl-1.0.1k:
1.9M   /usr/lib64/libcrypto.so.1.0.0
424K   /usr/lib64/libssl.so.1.0.0
2.3M   total

_________________
Quantity is not quality.
overlay | runit-scripts
Back to top
View user's profile Send private message
Jaglover
Watchman
Watchman


Joined: 29 May 2005
Posts: 5217
Location: Saint Amant, Acadiana

PostPosted: Sun Jan 11, 2015 12:18 am    Post subject: Reply with quote

judecn wrote:
NeddySeagoon wrote:
Being a bit of a dinosar, I have a static /dev. It all seems to work for me. I realise its not for everyone. I think its useful to keep the old ways alive because the day may come when its systemd or static.
I know which one I want, or maybe its choose the least worst.


One feature request in the works is adding mdev-like functionality to vdev. It would be possible to run it once, and it would create all of the device nodes in /dev for devices that are currently plugged into your system and take any admin-supplied device-specific actions on them as they get discovered. You could also run it periodically, and vdev would remove unneeded device nodes, add new ones, and take device-specific actions for you. Would you and others that prefer static /dev find this useful?


Yes!
_________________
Please learn how to denote units correctly!
Back to top
View user's profile Send private message
judecn
n00b
n00b


Joined: 07 Jan 2015
Posts: 17

PostPosted: Sun Jan 11, 2015 4:01 am    Post subject: Reply with quote

Ant P. wrote:
Don't blindly default to the worst possible option just because everyone else does it. I suspect there would've been less protests if not for the choice of library.


I'm only using OpenSSL for its SHA256 implementation. I went with OpenSSL (soon to be LibreSSL) since it's more likely to be packaged than libsodium (AFAICT).

However, it seems I won't be able to rely on either libssl or libsodium anyway, since both are installed to /usr.
Back to top
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 8887
Location: Somewhere over Atlanta, Georgia

PostPosted: Sun Jan 11, 2015 4:33 am    Post subject: Reply with quote

judecn wrote:
Ant P. wrote:
Don't blindly default to the worst possible option just because everyone else does it. I suspect there would've been less protests if not for the choice of library.


I'm only using OpenSSL for its SHA256 implementation. I went with OpenSSL (soon to be LibreSSL) since it's more likely to be packaged than libsodium (AFAICT).

However, it seems I won't be able to rely on either libssl or libsodium anyway, since both are installed to /usr.
Also, there's
Code:
hal ~ # ls -l /usr/lib64/libmhash.so.2.0.1
-rwxr-xr-x 1 root root 174,400 Dec 28 10:22 /usr/lib64/libmhash.so.2.0.1
But frankly, if you think it's a compelling feature, SHA256 is a manageable amount of source code to incorporate from another project, even the OpenSSL project. You have a solvable problem on your hands.

- John
_________________
I can confirm that I have received between 0 and 999 National Security Letters.
Back to top
View user's profile Send private message
judecn
n00b
n00b


Joined: 07 Jan 2015
Posts: 17

PostPosted: Sun Jan 11, 2015 4:47 am    Post subject: Reply with quote

John R. Graham wrote:
But frankly, if you think it's a compelling feature, SHA256 is a manageable amount of source code to incorporate from another project, even the OpenSSL project. You have a solvable problem on your hands.


That's probably what I'll end up having to do for libpstat, since the SHA256 implementation can't live in /usr. I'm just not a fan of NIH syndrome, so I consider this to be an approach of last resort (but it looks like I'm there now).
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
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