Mailing List Archive

On Sat, 2005-07-09 at 02:44 +0200, Michiel de Bruijne wrote:
> On Saturday 09 July 2005 01:35, Martin Schlemmer wrote:
> > I think people is under a misconception about this option and ... you
> > really only need to enable this for a driver that is not sysfs aware
> > (nvidia comes to mind - any others?)
>
> nvidia is also sysfs-aware and /dev-entries are created with udev, I have
> RC_DEVICE_TARBALL="no" set on all machines I maintain and a few of them have
> a nvidia-card. Works perfectly.

Hmm, what driver version? The earlier versions used to have a patch I
wrote to get the support and then they did their own code. The last two
or so releases however did not support this as far as I know (could be
wrong, but do not look that way .. or with 2.6.11/12+ and 1.0.7* at
least):

-----
lycan ~ # grep nvidia /dev/.udevdb/*
lycan ~ # bzcat /lib64/udev-state/devices.tar.bz2 | tar -t
nvidiactl
nvidia0
lycan ~ #
-----


Regards,

--
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa

maillog: 08/07/2005-10:12:52(-0700): Greg KH types
> --- 50-udev.rules.orig 2005-07-08 10:10:24.000000000 -0700
> +++ 50-udev.rules 2005-07-08 10:11:16.000000000 -0700
> @@ -139,9 +139,9 @@
> # tty devices
> KERNEL=="console", NAME="%k", GROUP="tty", MODE="0600"
> KERNEL=="tty", NAME="%k", GROUP="tty", MODE="0666"
> -KERNEL=="tty[0-9]*", NAME="vc/%n", SYMLINK+="%k", GROUP="tty"
> -KERNEL=="ttyS[0-9]*", NAME="tts/%n", SYMLINK+="%k", GROUP="tty"
> -KERNEL=="ttyUSB[0-9]*", NAME="tts/USB%n", GROUP="tty", MODE="0660"
> +KERNEL=="tty[0-9]*", NAME="%k", GROUP="tty"
> +KERNEL=="ttyS[0-9]*", NAME="%k", GROUP="tty"
> +KERNEL=="ttyUSB[0-9]*", NAME="%k", GROUP="tty", MODE="0660"
> KERNEL=="ippp0", NAME="%k", GROUP="tty"
> KERNEL=="isdn*" NAME="%k", GROUP="tty"
> KERNEL=="dcbri*", NAME="%k", GROUP="tty"
> @@ -149,14 +149,14 @@
>
> # pty devices
> KERNEL=="ptmx", NAME="%k", GROUP="tty", MODE="0666"
> -KERNEL=="pty[p-za-e][0-9a-f]*", NAME="pty/m%n", SYMLINK+="%k", GROUP="tty"
> -KERNEL=="tty[p-za-e][0-9a-f]*", NAME="pty/s%n", SYMLINK+="%k", GROUP="tty"
> +KERNEL=="pty[p-za-e][0-9a-f]*", NAME="%k", GROUP="tty"
> +KERNEL=="tty[p-za-e][0-9a-f]*", NAME="%k", GROUP="tty"
>
> # vc devices
> -KERNEL=="vcs", NAME="vcc/0", SYMLINK+="%k", GROUP="tty"
> -KERNEL=="vcs[0-9]*", NAME="vcc/%n", SYMLINK+="%k", GROUP="tty"
> -KERNEL=="vcsa", NAME="vcc/a0", SYMLINK+="%k", GROUP="tty"
> -KERNEL=="vcsa[0-9]*", NAME="vcc/a%n", SYMLINK+="%k", GROUP="tty"
> +KERNEL=="vcs", NAME="%k", GROUP="tty"
> +KERNEL=="vcs[0-9]*", NAME="%k", GROUP="tty"
> +KERNEL=="vcsa", NAME="%k", GROUP="tty"
> +KERNEL=="vcsa[0-9]*", NAME="%k", GROUP="tty"
>
> # memory devices
> KERNEL=="random", NAME="%k", MODE="0666"

I've been trying to get this for a while, but isn't it OK to omit
NAME="%k" since that's the default anyway? Or is there some other idea,
related to those last-rule processed things. I think it's prettier to
not specify redundand stuff and only specify what you want to have
*changed*.

--
() Georgi Georgiev () People that can't find something to live ()
() chutz@gg3.net () for always seem to find something to die ()
() +81(90)2877-8845 () for. The problem is, they usually want the ()
() ------------------- () rest of us to die for it too. ()
--
gentoo-dev@gentoo.org mailing list

On Sat, Jul 09, 2005 at 01:35:58AM +0200, Martin Schlemmer wrote:
> On Fri, 2005-07-08 at 15:25 -0700, Greg KH wrote:
> > On Fri, Jul 08, 2005 at 07:49:34PM +0200, Michiel de Bruijne wrote:
> > > I.o.w. is it still necessary to have RC_DEVICE_TARBALL="yes" as a
> > > default or can we move to a pure udev system and change the default to
> > > "no".
> >
> > I've been running my boxes successfully with "no" since the option
> > showed up just fine :)
> >
>
> I think people is under a misconception about this option and ... you
> really only need to enable this for a driver that is not sysfs aware
> (nvidia comes to mind - any others?), or if you have some custom nodes
> in /dev that you cannot do via udev ... And I am pretty sure (correct
> me if I am wrong) that all (or most?) in-kernel drivers are sysfs aware,
> and only a handful outside are not.

Only think in-kernel that I know of that do not work with udev is isdn.
Supposidly those developers are working on it...

As for nvidia, they will not be supporting udev due to licensing issues
with their kernel code. I've worked with their developers and they have
switched back to the way that vmware does it, their startup scripts just
manually creates the device nodes, which works just fine with udev.

So yes, I don't think that anyone (unless you have isdn), needs this
option.

thanks,

greg k-h
--
gentoo-dev@gentoo.org mailing list

On Sat, Jul 09, 2005 at 10:00:31AM +0900, Georgi Georgiev wrote:
> > # vc devices
> > -KERNEL=="vcs", NAME="vcc/0", SYMLINK+="%k", GROUP="tty"
> > -KERNEL=="vcs[0-9]*", NAME="vcc/%n", SYMLINK+="%k", GROUP="tty"
> > -KERNEL=="vcsa", NAME="vcc/a0", SYMLINK+="%k", GROUP="tty"
> > -KERNEL=="vcsa[0-9]*", NAME="vcc/a%n", SYMLINK+="%k", GROUP="tty"
> > +KERNEL=="vcs", NAME="%k", GROUP="tty"
> > +KERNEL=="vcs[0-9]*", NAME="%k", GROUP="tty"
> > +KERNEL=="vcsa", NAME="%k", GROUP="tty"
> > +KERNEL=="vcsa[0-9]*", NAME="%k", GROUP="tty"
> >
> > # memory devices
> > KERNEL=="random", NAME="%k", MODE="0666"
>
> I've been trying to get this for a while, but isn't it OK to omit
> NAME="%k" since that's the default anyway? Or is there some other idea,
> related to those last-rule processed things. I think it's prettier to
> not specify redundand stuff and only specify what you want to have
> *changed*.

Yes, it should work just fine without the NAME="%k", but it's safe to
put it there. It helps others when reading the rules and learning how
to write their own.

thanks,

greg k-h
--
gentoo-dev@gentoo.org mailing list

John Mylchreest wrote:
>
> No objections here. I've been waiting fort his move for a little while
> now. The only real problems will be with those 2.4 (devfs) users who
> refuse to move, maybe this is good enough incentive.

Just to make sure on a few things, we're talking x86 users here being the
hardcore 2.4 types, right?

While I'm all for 2.6, mips-side, we've still got some issues on IP22
(Indy/Indigo2) systems that forces me to keep a 2.4.31 ebuild around. Sparc is
also in a similar, although much bigger boat, where a whole lot of 2.6.x
releases just don't work for various systems, thus they have to stick with 2.4.x
as well.

Any of these changes that may affect 2.4/devfs usage need to keep this in mind
that some of us who still use 2.4/devfs may not be doing so out of choice,
simply because it's the only option we have.


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands
do them because they must, while the eyes of the great are elsewhere." --Elrond
--
gentoo-dev@gentoo.org mailing list

On Fri, Jul 08, 2005 at 11:56:30PM -0400, Kumba wrote:
> John Mylchreest wrote:
> >
> >No objections here. I've been waiting fort his move for a little while
> >now. The only real problems will be with those 2.4 (devfs) users who
> >refuse to move, maybe this is good enough incentive.
>
> Just to make sure on a few things, we're talking x86 users here being the
> hardcore 2.4 types, right?

Yes.

> While I'm all for 2.6, mips-side, we've still got some issues on IP22
> (Indy/Indigo2) systems that forces me to keep a 2.4.31 ebuild around.
> Sparc is also in a similar, although much bigger boat, where a whole lot of
> 2.6.x releases just don't work for various systems, thus they have to stick
> with 2.4.x as well.

I understand that other arches need to stay at 2.4 for various reasons.
Hopefully those issues will be fixed so that this situation doesn't stay
that way for much longer.

I am supprised that Sparc64 is stuck with 2.4, as the main kernel
developers of that tree work on 2.6 everyday. As for mips, I thought
the recent (few kernel versions ago) merge brought you all up to speed?

Anything that I can do to help this, please let me know.

> Any of these changes that may affect 2.4/devfs usage need to keep this in
> mind that some of us who still use 2.4/devfs may not be doing so out of
> choice, simply because it's the only option we have.

You do have the static /dev option :)

Anyway, no, I don't want to break your boxes at all, that's why I want
to stay with the LSB naming scheme, which the default devfs config also
supports.

thanks,

greg k-h
--
gentoo-dev@gentoo.org mailing list

Greg KH wrote:
>
> I understand that other arches need to stay at 2.4 for various reasons.
> Hopefully those issues will be fixed so that this situation doesn't stay
> that way for much longer.

You're not the only one hoping they're fixed soon :)


> I am supprised that Sparc64 is stuck with 2.4, as the main kernel
> developers of that tree work on 2.6 everyday. As for mips, I thought
> the recent (few kernel versions ago) merge brought you all up to speed?
>
> Anything that I can do to help this, please let me know.

Yeah, it's a bit surprising really. It depends heavily on the machine, and upon
certain options in the machine. I run a Blade 100 with 1 IDE and 1 SCSI drive,
and 2.6.7 is the last "good" kernel for me. 2.6.8.1 -> early 2.6.11 apparently
had something nasty that buggered up the scsi subsystem to the point where heavy
disk activity brought a system to its knees in minutes. I haven't tested
anything newer as I usually wait for a grsec release before building a new
kernel for my non-mips systems (and they haven't released anything for 2.6.12 yet).

The current issue going on, I haven't followed too closely, but it appears to
cause various issues on several machines. In one case, a Netra 1450 with 4x
CPUs keels over on 2.6.1 and up within several minutes of doing anything on it.
squash is going to go back and test all the 2.5.x kernels to try and find the
point at which it all started happening.

The thread regarding all of this (and has davem participating in) started here:
http://marc.theaimsgroup.com/?l=gentoo-sparc&m=111967071008611&w=2

As for mips, the only system gentoo-supported that still has a link to 2.4 are
the old IP22 (SGI Indy/SGI Indigo2 R4x00) systems. When I run ~2.6.10 on it, I
can usually hang the box after a couple hours of building something (like
glibc), whereas geoman can run his Indy for days on 2.6.x w/o incident. Likely,
there's probably some tricky bugs left that hinge on a specific CPU revision,
and I just happen to have the one revision that causes the bug. I just haven't
fired the system up and really taken a good look at it.


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands
do them because they must, while the eyes of the great are elsewhere." --Elrond
--
gentoo-dev@gentoo.org mailing list

>>>I.o.w. is it still necessary to have RC_DEVICE_TARBALL="yes" as a
>>>default or can we move to a pure udev system and change the default to
>>>"no".
>>>
>>>
>>I've been running my boxes successfully with "no" since the option
>>showed up just fine :)
>>
>>
>>
>
>I think people is under a misconception about this option and ... you
>really only need to enable this for a driver that is not sysfs aware
>(nvidia comes to mind - any others?), or if you have some custom nodes
>in /dev that you cannot do via udev ... And I am pretty sure (correct
>me if I am wrong) that all (or most?) in-kernel drivers are sysfs aware,
>and only a handful outside are not.
>
>
>

Well, I do have a small issue with the software RAID (md) driver, in
that when autodetection is not performed by the driver (due to either
being a module or booting the system through an initramfs), no sysfs
entries or device nodes are created.

Normally my RAID system is brought up inside my initramfs with static
nodes, so this really only affects my recovery CD, where I need to run:

for d in 0 1 2 3; do
/sbin/mdadm --assemble --config=partitions --auto=md
--super-minor=$d /dev/md$d >/dev/null 2>&1
done

Maybe something similar will be required in /sbin/rc, like you currently
do for LVM and the device mapper? It isn't a critical problem
though...I am pretty sure there are only a few Gentoo users who will
ever see this...maybe as few as 1!!!

-Richard

--
gentoo-dev@gentoo.org mailing list

Richard Fish wrote:
>>>>I.o.w. is it still necessary to have RC_DEVICE_TARBALL="yes" as a
>>>>default or can we move to a pure udev system and change the default to
>>>>"no".
>>>>
>>>I've been running my boxes successfully with "no" since the option
>>>showed up just fine :)
>>
>>I think people is under a misconception about this option and ... you
>>really only need to enable this for a driver that is not sysfs aware
>>(nvidia comes to mind - any others?), or if you have some custom nodes
>>in /dev that you cannot do via udev ... And I am pretty sure (correct
>>me if I am wrong) that all (or most?) in-kernel drivers are sysfs aware,
>>and only a handful outside are not.
>>
> Well, I do have a small issue with the software RAID (md) driver, in
> that when autodetection is not performed by the driver (due to either
> being a module or booting the system through an initramfs), no sysfs
> entries or device nodes are created.
>
> Normally my RAID system is brought up inside my initramfs with static
> nodes, so this really only affects my recovery CD, where I need to run:
>
> for d in 0 1 2 3; do
> /sbin/mdadm --assemble --config=partitions --auto=md
> --super-minor=$d /dev/md$d >/dev/null 2>&1
> done
>
> Maybe something similar will be required in /sbin/rc, like you currently
> do for LVM and the device mapper? It isn't a critical problem
> though...I am pretty sure there are only a few Gentoo users who will
> ever see this...maybe as few as 1!!!
>

This might explain why this problem wasn't seen for the missing md
devices in /lib/udev-state/devices.tar.bz2... I obviously don't use
genkernel, nor initrd... I now add myself these devices by hand in the
tar ball.



--
gentoo-dev@gentoo.org mailing list

On Sat, 2005-07-09 at 20:34 +0200, Richard Fish wrote:
> >>>I.o.w. is it still necessary to have RC_DEVICE_TARBALL="yes" as a
> >>>default or can we move to a pure udev system and change the default to
> >>>"no".
> >>>
> >>>
> >>I've been running my boxes successfully with "no" since the option
> >>showed up just fine :)
> >>
> >>
> >>
> >
> >I think people is under a misconception about this option and ... you
> >really only need to enable this for a driver that is not sysfs aware
> >(nvidia comes to mind - any others?), or if you have some custom nodes
> >in /dev that you cannot do via udev ... And I am pretty sure (correct
> >me if I am wrong) that all (or most?) in-kernel drivers are sysfs aware,
> >and only a handful outside are not.
> >
> >
> >
>
> Well, I do have a small issue with the software RAID (md) driver, in
> that when autodetection is not performed by the driver (due to either
> being a module or booting the system through an initramfs), no sysfs
> entries or device nodes are created.
>
> Normally my RAID system is brought up inside my initramfs with static
> nodes, so this really only affects my recovery CD, where I need to run:
>
> for d in 0 1 2 3; do
> /sbin/mdadm --assemble --config=partitions --auto=md
> --super-minor=$d /dev/md$d >/dev/null 2>&1
> done
>
> Maybe something similar will be required in /sbin/rc, like you currently
> do for LVM and the device mapper? It isn't a critical problem
> though...I am pretty sure there are only a few Gentoo users who will
> ever see this...maybe as few as 1!!!
>

Mike, what do you think? This viable? We could maybe add an init addon
for md, and move the lvm/whatever stuff to that as well?


--
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa

On Monday 11 July 2005 03:47 am, Martin Schlemmer wrote:
> On Sat, 2005-07-09 at 20:34 +0200, Richard Fish wrote:
> > >>>I.o.w. is it still necessary to have RC_DEVICE_TARBALL="yes" as a
> > >>>default or can we move to a pure udev system and change the default to
> > >>>"no".
> > >>
> > >>I've been running my boxes successfully with "no" since the option
> > >>showed up just fine :)
> > >
> > >I think people is under a misconception about this option and ... you
> > >really only need to enable this for a driver that is not sysfs aware
> > >(nvidia comes to mind - any others?), or if you have some custom nodes
> > >in /dev that you cannot do via udev ... And I am pretty sure (correct
> > >me if I am wrong) that all (or most?) in-kernel drivers are sysfs aware,
> > >and only a handful outside are not.
> >
> > Well, I do have a small issue with the software RAID (md) driver, in
> > that when autodetection is not performed by the driver (due to either
> > being a module or booting the system through an initramfs), no sysfs
> > entries or device nodes are created.
> >
> > Normally my RAID system is brought up inside my initramfs with static
> > nodes, so this really only affects my recovery CD, where I need to run:
> >
> > for d in 0 1 2 3; do
> > /sbin/mdadm --assemble --config=partitions --auto=md
> > --super-minor=$d /dev/md$d >/dev/null 2>&1
> > done
> >
> > Maybe something similar will be required in /sbin/rc, like you currently
> > do for LVM and the device mapper? It isn't a critical problem
> > though...I am pretty sure there are only a few Gentoo users who will
> > ever see this...maybe as few as 1!!!
>
> Mike, what do you think? This viable? We could maybe add an init addon
> for md, and move the lvm/whatever stuff to that as well?

i dont see the point ... ive already fixed raidtools / mdadm to generate
device nodes before running since udev doesnt do it correctly/at all
-mike
--
gentoo-dev@gentoo.org mailing list

On Tue, 2005-07-12 at 18:08 -0400, Mike Frysinger wrote:
> On Monday 11 July 2005 03:47 am, Martin Schlemmer wrote:
> > On Sat, 2005-07-09 at 20:34 +0200, Richard Fish wrote:
> > > >>>I.o.w. is it still necessary to have RC_DEVICE_TARBALL="yes" as a
> > > >>>default or can we move to a pure udev system and change the default to
> > > >>>"no".
> > > >>
> > > >>I've been running my boxes successfully with "no" since the option
> > > >>showed up just fine :)
> > > >
> > > >I think people is under a misconception about this option and ... you
> > > >really only need to enable this for a driver that is not sysfs aware
> > > >(nvidia comes to mind - any others?), or if you have some custom nodes
> > > >in /dev that you cannot do via udev ... And I am pretty sure (correct
> > > >me if I am wrong) that all (or most?) in-kernel drivers are sysfs aware,
> > > >and only a handful outside are not.
> > >
> > > Well, I do have a small issue with the software RAID (md) driver, in
> > > that when autodetection is not performed by the driver (due to either
> > > being a module or booting the system through an initramfs), no sysfs
> > > entries or device nodes are created.
> > >
> > > Normally my RAID system is brought up inside my initramfs with static
> > > nodes, so this really only affects my recovery CD, where I need to run:
> > >
> > > for d in 0 1 2 3; do
> > > /sbin/mdadm --assemble --config=partitions --auto=md
> > > --super-minor=$d /dev/md$d >/dev/null 2>&1
> > > done
> > >
> > > Maybe something similar will be required in /sbin/rc, like you currently
> > > do for LVM and the device mapper? It isn't a critical problem
> > > though...I am pretty sure there are only a few Gentoo users who will
> > > ever see this...maybe as few as 1!!!
> >
> > Mike, what do you think? This viable? We could maybe add an init addon
> > for md, and move the lvm/whatever stuff to that as well?
>
> i dont see the point ... ive already fixed raidtools / mdadm to generate
> device nodes before running since udev doesnt do it correctly/at all

Ok, great .. just wanted to check ... Guess that is still in ~ ?


--
Martin Schlemmer

On Wednesday 13 July 2005 05:00 am, Martin Schlemmer wrote:
> On Tue, 2005-07-12 at 18:08 -0400, Mike Frysinger wrote:
> > i dont see the point ... ive already fixed raidtools / mdadm to generate
> > device nodes before running since udev doesnt do it correctly/at all
>
> Ok, great .. just wanted to check ... Guess that is still in ~ ?

no, it's in stable since it works with baselayout-1.11.x
-mike
--
gentoo-dev@gentoo.org mailing list

Mike Frysinger wrote:

>On Monday 11 July 2005 03:47 am, Martin Schlemmer wrote:
>
>
>>On Sat, 2005-07-09 at 20:34 +0200, Richard Fish wrote:
>>
>>
>>> for d in 0 1 2 3; do
>>> /sbin/mdadm --assemble --config=partitions --auto=md
>>>--super-minor=$d /dev/md$d >/dev/null 2>&1
>>> done
>>>
>>>Maybe something similar will be required in /sbin/rc, like you currently
>>>do for LVM and the device mapper? It isn't a critical problem
>>>though...I am pretty sure there are only a few Gentoo users who will
>>>ever see this...maybe as few as 1!!!
>>>
>>>
>>Mike, what do you think? This viable? We could maybe add an init addon
>>for md, and move the lvm/whatever stuff to that as well?
>>
>>
>
>i dont see the point ... ive already fixed raidtools / mdadm to generate
>device nodes before running since udev doesnt do it correctly/at all
>-mike
>
>

Oh, yes, I see that now. Sorry for the noise.

-Richard


--
gentoo-dev@gentoo.org mailing list

On Wed, 2005-07-06 at 15:46 -0700, Greg KH wrote:
> Ok, now that devfs is removed from the 2.6 kernel tree[1], I think it's
> time to start to revisit some of the /dev naming rules that we currently
> are living with[2].
>
> To start with, the 061 version of udev offers a big memory savings if
> you use the "default" kernel name of a device[3]. If you do that, it does
> not create a file in its database in /dev/.udevdb/
>
> If we can move away from some of our devfs-like names, we stand to
> reclaim a lot of memory from everyone's machines. As an example, if we
> drop all of the tty/pts/vc/vcc symlinks, and just go with the default
> kernel name, we save 2.5Mb of space in tempfs/ramfs. I've done this on
> my machines and everything seems to work just fine (it looks like
> everything that was trying to use a tty node was just using the symlink
> anyway.)
>
> So, anyone have any objections to me changing the default udev naming
> scheme in this manner?
>
> Next up, that loony block device naming scheme (more on that later...)
>
> thanks,
>
> greg k-h

Sorry to only reply to this now, but i saw a mail of you talking about
ndevfs. will that go into 2.6.13? not that i use devfs, 'cause i don't,
i'm just curious.

On Sat, Jul 16, 2005 at 12:37:52AM +0100, Carlos Silva wrote:
>
> Sorry to only reply to this now, but i saw a mail of you talking about
> ndevfs. will that go into 2.6.13? not that i use devfs, 'cause i don't,
> i'm just curious.

No, ndevfs was written in a bout of temporary insanity. I will not
submit it to go into the main kernel tree, and apologize for ever
writing it in the first place.

thanks,

greg k-h
--
gentoo-dev@gentoo.org mailing list

On Fri, Jul 08, 2005 at 10:12:52AM -0700, Greg KH wrote:
> On Thu, Jul 07, 2005 at 10:18:12AM -0400, Chris Gianelloni wrote:
> > On Wed, 2005-07-06 at 15:46 -0700, Greg KH wrote:
> > > To start with, the 061 version of udev offers a big memory savings if
> > > you use the "default" kernel name of a device[3]. If you do that, it does
> > > not create a file in its database in /dev/.udevdb/
> >
> > So if we were to switch to udev 061 in genkernel, it would shrink memory
> > usage in our initrd/initramfs, provided we made everything use the LSB
> > device names/nodes, versus the devfs ones, correct?
>
> Not in the initrd/initramfs, but in the tmpfs partition that udev uses
> to create the /dev entries. Well, I guess you could say the
> "initrd/initramfs" if that is where udev is mounted on early startup (I
> haven't looked at how genkernel does this in a long time, sorry.)
>
> And yes, the memory savings is there, if we use the LSB names only vs
> the devfs name and the symlink like we currently do.
>
> To see this, look at how much space /dev/.udevdb/ takes up right now
> with 062 udev. Then change the following rules in
> /etc/udev/rules.d/50-udev.rules with the diff at the end of this email.
> Then reboot and look at the size of the /dev/.udevdb/ directory again.
> I think you will notice a huge space savings.

<snip>

Ok, 064-r1 version of udev does this for tty and console devices. The
old devfs names are now gone. Because of this, and some other config
file tweaks, starting udev now only takes .5 seconds on my old, slow
laptop, instead of 5 seconds. Hopefully others will also see such an
increase.

Now to implement the persistent block device names that we showed
everyone at OLS...

thanks,

greg k-h
--
gentoo-dev@gentoo.org mailing list

Greg KH wrote:
> Ok, 064-r1 version of udev does this for tty and console devices. The
> old devfs names are now gone. Because of this, and some other config
> file tweaks, starting udev now only takes .5 seconds on my old, slow
> laptop, instead of 5 seconds. Hopefully others will also see such an
> increase.
>
> Now to implement the persistent block device names that we showed
> everyone at OLS...

Does this happen to also fix the bus error on sparc mentioned in Bug #99290? I
see in the Changelog a reference to a sparc fix, but the bug hasn't been updated
regarding the status.


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands
do them because they must, while the eyes of the great are elsewhere." --Elrond
--
gentoo-dev@gentoo.org mailing list

On Mon, Aug 01, 2005 at 07:23:32PM -0400, Kumba wrote:
> Greg KH wrote:
> >Ok, 064-r1 version of udev does this for tty and console devices. The
> >old devfs names are now gone. Because of this, and some other config
> >file tweaks, starting udev now only takes .5 seconds on my old, slow
> >laptop, instead of 5 seconds. Hopefully others will also see such an
> >increase.
> >
> >Now to implement the persistent block device names that we showed
> >everyone at OLS...
>
> Does this happen to also fix the bus error on sparc mentioned in Bug
> #99290? I see in the Changelog a reference to a sparc fix, but the bug
> hasn't been updated regarding the status.

Oops, yes, the 064 release fixed that. Sorry for not updateing the
bugzilla entry. That is now taken care of.

thanks,

greg k-h
--
gentoo-dev@gentoo.org mailing list

Greg KH wrote:
>
> Oops, yes, the 064 release fixed that. Sorry for not updateing the
> bugzilla entry. That is now taken care of.

Just out of curiosity, know what happened to cause that?


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands
do them because they must, while the eyes of the great are elsewhere." --Elrond
--
gentoo-dev@gentoo.org mailing list

On Mon, Aug 01, 2005 at 07:40:03PM -0400, Kumba wrote:
> Greg KH wrote:
> >
> >Oops, yes, the 064 release fixed that. Sorry for not updateing the
> >bugzilla entry. That is now taken care of.
>
> Just out of curiosity, know what happened to cause that?

Unaligned data accesses. Was fixed by:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=commit;h=422d5becc339304805bbe1e359f6389633036a98

thanks,

greg k-h
--
gentoo-dev@gentoo.org mailing list

Martin Schlemmer posted <1120744545.6560.18.camel@lycan.lan>, excerpted
below, on Thu, 07 Jul 2005 15:55:45 +0200:

> Lastly on an unrelated note ... I have a rule:
>
> -----
> # cat /etc/udev/rules.d/40-dm.rules
> KERNEL="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="mapper/%c", SYMLINK="%c"
> -----
>
> And in theory it should be the last rule to set the name ... however the
> default one in 50-udev.rules overrides it, and I have to add
> OPTIONS="last_rule"

Why would a rule applied in 40-x.rules be expected to stick when
50-x.rules runs after it and has a conflicting rule?

Change the 40- to 60- and it should work. Of course, you are already
using another alternative, the last_rule option.

There's a third option that /might/ work, as well, according to the
documentation (which is fresh in my mind due to bug 98175, udev-061's
user/group mixups, today). You could try replacing the NAME= with NAME:=.
According to the documentation, the := assignment cannot be overwritten,
so that should make your name stick, with newer udevs, anyway. I think
that functionality is rather new, tho, and may not be in stable versions.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list

Martin Schlemmer posted <1120766792.27435.17.camel@lycan.lan>, excerpted
below, on Thu, 07 Jul 2005 22:06:32 +0200:

> According to the manpage:
>
> -----
> NAME The name of the node to be created, or the name, the network
> interface should be renamed to. Only one rule can set the a name, all
> later rules with a NAME key will be ignored.

Indeed. I guess /that/ part of the documentation was /not/ fresh on my
mind, due to today's owner/group bug. =8^(

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list