Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Announce: just another one udev fork
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 6, 7, 8 ... 12, 13, 14  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
hcaulfield57
Tux's lil' helper
Tux's lil' helper


Joined: 13 Mar 2012
Posts: 148

PostPosted: Thu Sep 27, 2012 4:35 pm    Post subject: Reply with quote

theBlackDragon wrote:

Oh right, I read that. I just interpreted that remark as him having literally said as much (though I guess that quote isn't all that far off)

Yes, I believe that was the implication of the quote, I know that many people probably suspected this from the beginning of the merge.
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Mon Oct 01, 2012 10:41 am    Post subject: Re: Announce: just another one udev fork Reply with quote

consus wrote:
Hello. I want to announce new udev fork... Not far ago we decided to make a standalone version, because of recent changes in project (udev <-> systemd integration) based on udev-182

In the early times of portage's udev > 179, I had noticed : KV_min=2.6.34
I did not follow the history of the developments achieved since early > 179 versions but, I can now read in all portage ebuilds : KV_min=2.6.39 8O

Having still a couple of 2.6.38 running, I'd be happy to read that your fork is still compatible with KV >= 2.6.34

BTW, I would be grateful if someone could point a link to any discussion supporting the increase of KV_min to 2.6.39.
_________________
Back to top
View user's profile Send private message
grey_dot
Tux's lil' helper
Tux's lil' helper


Joined: 15 Jul 2012
Posts: 142

PostPosted: Tue Oct 02, 2012 9:37 pm    Post subject: Re: Announce: just another one udev fork Reply with quote

aCOSwt wrote:
consus wrote:
Hello. I want to announce new udev fork... Not far ago we decided to make a standalone version, because of recent changes in project (udev <-> systemd integration) based on udev-182

In the early times of portage's udev > 179, I had noticed : KV_min=2.6.34
I did not follow the history of the developments achieved since early > 179 versions but, I can now read in all portage ebuilds : KV_min=2.6.39 8O

Having still a couple of 2.6.38 running, I'd be happy to read that your fork is still compatible with KV >= 2.6.34

BTW, I would be grateful if someone could point a link to any discussion supporting the increase of KV_min to 2.6.39.


It was the upstream guys decision, not ours. We haven't tested anything with pre 3.0 kernels, so we can't say for sure. However, if you try to run udev on 2.6.38, and it works, we'll decrease the required kernel number :)
Back to top
View user's profile Send private message
genstorm
Advocate
Advocate


Joined: 05 Apr 2007
Posts: 2467
Location: Austria

PostPosted: Wed Oct 03, 2012 7:36 pm    Post subject: Reply with quote

Are you guys all aware of that discussion? http://marc.info/?l=linux-kernel&m=134929242315036&w=2

;)
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Wed Oct 03, 2012 7:51 pm    Post subject: Reply with quote

genstorm wrote:
Are you guys all aware of that discussion? http://marc.info/?l=linux-kernel&m=134929242315036&w=2

If this is the one ending with Linus deciding to bypass udev for loading firmware... then... 8O There's going to be a real good reason for KV_min > 3.a_lot :evil:
_________________
Back to top
View user's profile Send private message
genstorm
Advocate
Advocate


Joined: 05 Apr 2007
Posts: 2467
Location: Austria

PostPosted: Wed Oct 03, 2012 8:16 pm    Post subject: Reply with quote

Linus' patch is getting various ACKs right now, seems it's almost done. That thing looks easily backportable, but I'd recommend you move up to at least 3.0 anyway. :)
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
jathlon
Tux's lil' helper
Tux's lil' helper


Joined: 26 Sep 2006
Posts: 89
Location: Canada

PostPosted: Wed Oct 03, 2012 9:08 pm    Post subject: Reply with quote

I got a warm fuzzy feeling from this statement by Al Viro;

Quote:
Looks sane. TBH, I'd still prefer to see udev forcibly taken over and put into
usr/udev in kernel tree - I don't trust that crowd at all and the fewer
critical userland bits they can play leverage games with, the safer we are.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


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

PostPosted: Wed Oct 03, 2012 9:30 pm    Post subject: Reply with quote

/me gets ready to drop Gnome when it pulls in systemd
_________________
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
grey_dot
Tux's lil' helper
Tux's lil' helper


Joined: 15 Jul 2012
Posts: 142

PostPosted: Wed Oct 03, 2012 10:22 pm    Post subject: Reply with quote

jathlon wrote:
I got a warm fuzzy feeling from this statement by Al Viro;

Quote:
Looks sane. TBH, I'd still prefer to see udev forcibly taken over and put into
usr/udev in kernel tree - I don't trust that crowd at all and the fewer
critical userland bits they can play leverage games with, the safer we are.


Not a bad idea after all, but methinks this is unlikely to happen.
Back to top
View user's profile Send private message
genstorm
Advocate
Advocate


Joined: 05 Apr 2007
Posts: 2467
Location: Austria

PostPosted: Wed Oct 03, 2012 10:54 pm    Post subject: Reply with quote

Someone just called for a udev fork if they won't fix it :D
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
The Doctor
Veteran
Veteran


Joined: 27 Jul 2010
Posts: 1468

PostPosted: Wed Oct 03, 2012 11:23 pm    Post subject: Reply with quote

genstorm wrote:
Someone just called for a udev fork if they won't fix it :D


Wait... Isn't that what we have here? :wink:

By the way, its working great with a separate /usr (and /var), root on lvm, and (almost) complete disk encryption. The only minor irritation is that udev-190 is still trying to start alsactl before /usr is mounted. It would be nice if there was something we could do about that, like maybe alter a udev rule or make a package that fixes the rule whenever alsa is re-installed or something?

Anyway, great work on the fork guys. I really appreciate not having upstream try to dictate my partition scheme or try to push me into systemd.
_________________
First things first, but not necessarily in that order.
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Thu Oct 04, 2012 6:48 am    Post subject: Reply with quote

The Doctor wrote:
The only minor irritation is that udev-190 is still trying to start alsactl before /usr is mounted. It would be nice if there was something we could do about that

Formally speaking :
a/ it is not udev which is responsible for starting alsactl before /usr is mounted, it is you!
b/ /usr is not that much responsible for the irritating problem you see, it's /var !

I do not personally understand why I would need alsasound to be set at the boot run level.
OK, I know, the official handbook instructs to do so, but really... I cannot figure out why.

What I did under my system was to remove it from the boot run level and declare it in the default run level.
That way, alsactl is not required to run when /var is not yet mounted.
Code:
# rc-update delete alsasound
# rc-update add alsasound default

And the problem, (that has been irritating me too :wink: ) went away ! 8)
_________________
Back to top
View user's profile Send private message
The Doctor
Veteran
Veteran


Joined: 27 Jul 2010
Posts: 1468

PostPosted: Thu Oct 04, 2012 7:14 am    Post subject: Reply with quote

aCOSwt wrote:
That way, alsactl is not required to run when /var is not yet mounted.
Code:
# rc-update delete alsasound
# rc-update add alsasound default

And the problem, (that has been irritating me too :wink: ) went away ! 8)


I did try that already. It seems that did not work for me. :?
I wonder what difference is between our setups. The only time I have not noticed this occurring is when an fscheck comes up, then I actually specifically noticed its not being started until /usr is mounted.

As I indicated before I am running udev-190. Are you one of the brave souls testing udev-9999?
_________________
First things first, but not necessarily in that order.
Back to top
View user's profile Send private message
grey_dot
Tux's lil' helper
Tux's lil' helper


Joined: 15 Jul 2012
Posts: 142

PostPosted: Thu Oct 04, 2012 9:59 pm    Post subject: Reply with quote

aCOSwt wrote:

Formally speaking :
a/ it is not udev which is responsible for starting alsactl before /usr is mounted, it is you!
b/ /usr is not that much responsible for the irritating problem you see, it's /var !

I do not personally understand why I would need alsasound to be set at the boot run level.
OK, I know, the official handbook instructs to do so, but really... I cannot figure out why.

What I did under my system was to remove it from the boot run level and declare it in the default run level.
That way, alsactl is not required to run when /var is not yet mounted.
Code:
# rc-update delete alsasound
# rc-update add alsasound default

And the problem, (that has been irritating me too :wink: ) went away ! 8)


Well, actually it's udev. Or the rules brought by alsa.
Code:

> grep -R usr /lib/udev/rules.d
/lib/udev/rules.d/90-alsa-restore.rules:        RUN+="/usr/sbin/alsactl restore $attr{number}"


I've already wrote several pages before that this isn't required during boot stage because /etc/init.d/alsasound does the same.
Back to top
View user's profile Send private message
The Doctor
Veteran
Veteran


Joined: 27 Jul 2010
Posts: 1468

PostPosted: Thu Oct 04, 2012 11:19 pm    Post subject: Reply with quote

grey_dot wrote:
I've already wrote several pages before that this isn't required during boot stage because /etc/init.d/alsasound does the same.


So to clarify, it is safe to remove these rules? (While making backup, of course.)

I ask because the last time I tried to get cleaver I ended re-installing after a misplaced rm command.
_________________
First things first, but not necessarily in that order.
Back to top
View user's profile Send private message
grey_dot
Tux's lil' helper
Tux's lil' helper


Joined: 15 Jul 2012
Posts: 142

PostPosted: Thu Oct 04, 2012 11:48 pm    Post subject: Reply with quote

The Doctor wrote:

So to clarify, it is safe to remove these rules? (While making backup, of course.)

I ask because the last time I tried to get cleaver I ended re-installing after a misplaced rm command.


Yes, unless you use a hotplugable soundcard. Otherwise you'll end with running `/etc/init.d/alsasound restart` everytime you plug it in.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


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

PostPosted: Fri Oct 05, 2012 4:46 am    Post subject: Reply with quote

Just to echo everyone else, and say well done to consus, greydot and khayyam for working on this.
The Doctor wrote:
By the way, its working great with a separate /usr (and /var), root on lvm, and (almost) complete disk encryption. The only minor irritation is that udev-190 is still trying to start alsactl before /usr is mounted. It would be nice if there was something we could do about that, like maybe alter a udev rule or make a package that fixes the rule whenever alsa is re-installed or something?

Going forward, that might be an issue with other things: it's the reason udev upstream started to insist udev be started after /usr et al are mounted, since rules are allowed to call on binaries or libs from any file-system, including /usr or /var (under this model, you can't have a split /usr or if you do you must run an initramfs, and deal with the same problem there instead.)

There used to be two stages to the udev bring-up, and one could explicitly call the second stage after localmount (that's what udev-postmount is for.) That was the usage-model that was deprecated last year.

Thinking about it, the patches to udev initscripts here would go nicely with this setup, since there's already patches applied to the initscripts. That gives you an initramfs option in udev.conf (defaults to "yes"). Setting it to "no" means udev is configured for startup immediately after localmount (you have to switch its run-level to boot, and add sysfs and udev-mount to sysinit.) It's been working here with official udev since last August, but that setup doesn't allow for use-cases that have traditionally required an initrd (like root-fs on lvm or encrypted.)

What it does mean, though is that /usr /var /tmp etc are mounted before udev starts, and it simply replays events ("coldplug") whenever it does start. The only difference I've noticed is the nvidia module blinks the screen when udev comes up.
_________________
creaker wrote:
systemd. It is a really ass pain

update - "a most excellent portage wrapper"

#friendly-coders -- We're still here for you™ ;)
Back to top
View user's profile Send private message
gerard82
Advocate
Advocate


Joined: 04 Jan 2004
Posts: 2228
Location: Netherlands

PostPosted: Sat Oct 06, 2012 3:30 pm    Post subject: Reply with quote

A big Thank You to grey_dot,consus,khayyam et al.
I installed from overlay,everything works out of the box after running revdep-rebuild.
Printer,scanner,wacom tablet,mice (I have 2,wired),sound.
No problem having /usr and /var on separate partitions.

Maybe some native speaker could write a howto.

Anyway thanks again.
Gerard.
_________________
To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2244

PostPosted: Sat Oct 06, 2012 5:20 pm    Post subject: Reply with quote

gerard82 wrote:
A big Thank You to grey_dot, consus, khayyam et al.

I seem to be getting kudos where its undeserved, I'm just a user and early adopter, and my contribution has been more in terms of providing feedback and helping out those who run into issues. I'm not directly involved with the fork, grey_dot and consus should recieve full credit for that.

Truth be told I'm actually a little nervous about the whole thing, as I don't think the project is well managed. If udev-standalone is going to be a viable alternative to systemd-udev then more needs to be done to make this happen, and currently this isn't happening. There is no bug open on b.g.o and there is no liason/discussion between gentoo devs and udev-standalone devs as to how the project should proceed and what needs to happen for the project to move from overlay status to virtual/dev-manager status, or even, what issues might stand in the way of this.

I tried to broach this subject some weeks back, but as yet there has been no responce. I know it has been discussed in dev circles and it seems that (for reasons related to soname changes, and/or if udev-standalone can actually function as a "drop-in replacement") opinions seem to be that udev-standalone isn't viable. Some of this may just be lack of communication between the various parties ... which brings me full circle.

steveL wrote:
Thinking about it, the patches to udev initscripts here would go nicely with this setup, since there's already patches applied to the initscripts

steveL ... I'll look at intergrating these into udev-init-scripts in my overlay ...

best ... khay
Back to top
View user's profile Send private message
gerard82
Advocate
Advocate


Joined: 04 Jan 2004
Posts: 2228
Location: Netherlands

PostPosted: Sat Oct 06, 2012 5:47 pm    Post subject: Reply with quote

Thanks for the warning khayyam.
Well you contributed a lot I think so that's why I mentioned you.
If this peters out I'll go back to udev-176.
I for one will not have systemd forced down my throat.
Never used initram,why complicate things.
Gerard
_________________
To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download
Back to top
View user's profile Send private message
genstorm
Advocate
Advocate


Joined: 05 Apr 2007
Posts: 2467
Location: Austria

PostPosted: Sat Oct 06, 2012 5:51 pm    Post subject: Reply with quote

erm, what's that udev-176 thing people keep talking about? As far as I can see, 171-r6 is the highest pre-180 version in portage.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
gerard82
Advocate
Advocate


Joined: 04 Jan 2004
Posts: 2228
Location: Netherlands

PostPosted: Sat Oct 06, 2012 6:22 pm    Post subject: Reply with quote

@genstorm,
AFAIK 176-r6 is the highest version that allows you to have /usr & /var on separate partitions w/o an initram.
Gerard.
_________________
To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download
Back to top
View user's profile Send private message
hcaulfield57
Tux's lil' helper
Tux's lil' helper


Joined: 13 Mar 2012
Posts: 148

PostPosted: Sat Oct 06, 2012 8:28 pm    Post subject: Reply with quote

khayyam wrote:

Truth be told I'm actually a little nervous about the whole thing, as I don't think the project is well managed.


I have to find myself in agreement. I have no doubts regarding the quality of the fork, consus and grey_dot have done a great job, and everything works well, but I feel the fork needs to receive wider adoption. I don't know what this issue is with sonames, although I have heard it mentioned before. I was under the impression that the fork had resolved that issue. I'm surprised that this doesn't have official status within Gentoo, because many Gentoo devs have expressed their desire in some sort of solution, well here's a solution to the problem. I think it's unlikely that extracting udev from systemd will be a long-term solution to the problem.

There are also other players at stake here. Slackware is very anti-systemd and would probably be interested in this fork, and a number of people on the linux-kernel mailing list have expressed desire for a fork. Keep up the good work guys, I'm glad this exists and is working well.

EDIT: Please note, I was not so much saying that the maintainership is bad for the forked udev, but that it's a shame this does not have official status within Gentoo as a virtual. Hopefully this will soon change.
Back to top
View user's profile Send private message
grey_dot
Tux's lil' helper
Tux's lil' helper


Joined: 15 Jul 2012
Posts: 142

PostPosted: Mon Oct 08, 2012 4:16 am    Post subject: Reply with quote

gerard82 wrote:
@genstorm,
AFAIK 176-r6 is the highest version that allows you to have /usr & /var on separate partitions w/o an initram.
Gerard.


Nope. I tested with 182 and it worked.
Back to top
View user's profile Send private message
grey_dot
Tux's lil' helper
Tux's lil' helper


Joined: 15 Jul 2012
Posts: 142

PostPosted: Mon Oct 08, 2012 4:27 am    Post subject: Reply with quote

khayyam wrote:

I tried to broach this subject some weeks back, but as yet there has been no responce. I know it has been discussed in dev circles and it seems that (for reasons related to soname changes, and/or if udev-standalone can actually function as a "drop-in replacement") opinions seem to be that udev-standalone isn't viable. Some of this may just be lack of communication between the various parties ... which brings me full circle.


Sorry, I had been quite busy with my.. errrr.. life. Doesn't matter though.

https://bugs.gentoo.org/show_bug.cgi?id=437570

I've just submitted a bug to bugzilla. Lets wait :)
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 ... 6, 7, 8 ... 12, 13, 14  Next
Page 7 of 14

 
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