Mailing List Archive

On Wed, Jul 06, 2005 at 03:46:51PM -0700, Greg KH wrote:
> [3] HAL needs a patch to be able to handle this. It's posted on the
> hal development mailing lists and will be checked in real-soon-now.

Here it is, if any of the "Gentopia" developers want to add it to our
package:
http://lists.freedesktop.org/archives/hal/2005-July/002683.html

thanks,

greg k-h
--
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].
>

> [2] devfs vs. udev flames will dutifully be ignored. Give up, it will do
> You no good to argue.

My understanding was that we still support old 2.2 kernels for SPARC
users as eradictor (iirc) posted a patch that only allowed iproute2
support if the kernel supported it. 2.6 kernels support it by default -
were require /proc/net/netlink for iproute2.

baselayout supports (and probably will indefinitely) ifconfig/net-tools
et all

This has absolutely zero to do with udev, but the point is that devfs vs
udev "flames" cannot be ignored until non udev supported kernels from
all arches are removed from the tree.

SPARC may have udev supported kernels supported now - I don't know. But
what I do know is that we have to support the lowest thing we have.

Thanks

Roy

--
gentoo-dev@gentoo.org mailing list

On Thu, Jul 07, 2005 at 12:06:04AM +0100, Roy Marples wrote:
>
> This has absolutely zero to do with udev, but the point is that devfs vs
> udev "flames" cannot be ignored until non udev supported kernels from
> all arches are removed from the tree.

It also has nothing to do with the naming scheme we use in /dev, as the
network stuff you mention don't care about /dev, right?

So, changing the udev naming scheme should not break SPARC, as I am
trying to migrate back to the standard LSB naming scheme.

After we get there, then I'll add the persistant naming symlinks that
it's looking like all distros are going to be agreeing apon in a few
months...

thanks,

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

On Wednesday 06 July 2005 07:06 pm, Roy Marples wrote:
> 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].
> >
> >
> > [2] devfs vs. udev flames will dutifully be ignored. Give up, it will do
> > You no good to argue.
>
> My understanding was that we still support old 2.2 kernels for SPARC
> users as eradictor (iirc) posted a patch that only allowed iproute2
> support if the kernel supported it. 2.6 kernels support it by default -
> were require /proc/net/netlink for iproute2.

and eventually i'd like to get m68k into the 2.2 kernels ...

> This has absolutely zero to do with udev, but the point is that devfs vs
> udev "flames" cannot be ignored until non udev supported kernels from
> all arches are removed from the tree.

i dont see how 2.2 kernels matter since they dont even support devfs ?
-mike
--
gentoo-dev@gentoo.org mailing list

On Wed, 2005-07-06 at 15:46 -0700, Greg KH wrote:
> So, anyone have any objections to me changing the default udev naming
> scheme in this manner?

I'm all for the move - I always disable the devfs naming scheme in udev
anyways.

> Next up, that loony block device naming scheme (more on that later...)

W00t :)

./Brix
--
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

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?
>

Fine with me. I assume we will need to keep the rcscript support for
those die-hard 2.4 users still, but hopefully we can eventually drop
that as well.

> Next up, that loony block device naming scheme (more on that later...)
>

Heh. I hope that we will still at least just do the cdsymlinks stuff
(just the /dev/cdrom, /dev/dvd, etc stuff) as that do make things a bit
easier for multimedia stuff.


> [3] HAL needs a patch to be able to handle this. It's posted on the
> hal development mailing lists and will be checked in real-soon-now.

I just think we need to make sure this is in first ...


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"

--- (default rule) ---
KERNEL="dm-[0-9]*", NAME=""
----------------------

I am assuming (without having looked at the code) that because NAME is
set to "", whatever code that should drop it as it have NAME, does not
kick in?


Thanks,

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

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?

> 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?

None here. Anything that gives us more usable RAM even after we've
snatched some for the initrd and for /dev and for the tmpfs of the
LiveCD/InstallCD is fine by me.

--
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

maillog: 06/07/2005-15:46:51(-0700): Greg KH types
> 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/

Ah, that will break /etc/init.d/halt.sh

Particularly the stuff around here:

ebegin "Saving device nodes"
...
cd /dev
# Find all devices
find . -xdev -type b -or -type c -or -type l | cut -d/ -f2- > \
"${devices_real}"
# Figure out what udev created
eval $(grep '^[[:space:]]*udev_db=' /etc/udev/udev.conf)
if [[ -d ${udev_db} ]]; then
# New udev_db is clear text ...
udevinfo=$(cat "${udev_db}"/*)
else
# Old one is not ...
udevinfo=$(udevinfo -d)
fi
# This basically strips 'S:' and 'N:' from the db output, and then
# print all the nodes/symlinks udev created ...
...

The script will be unable to figure out what device is being handled by
udev, and what is not.

--
| Georgi Georgiev | I read the newspaper avidly. It is my one |
| chutz@gg3.net | form of continuous fiction. -- Aneurin |
| +81(90)2877-8845 | Bevan |
--
gentoo-dev@gentoo.org mailing list

On Wed, 2005-07-06 at 15:46 -0700, Greg KH wrote:
> 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?

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.

On Thu, 2005-07-07 at 12:44 -0700, Duncan wrote:
> 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.
>

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.
-----


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

On Thu, Jul 07, 2005 at 08:52:20PM +0100, John Mylchreest wrote:
> On Wed, 2005-07-06 at 15:46 -0700, Greg KH wrote:
> > 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?
>
> 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.

As the default devfs configuration in gentoo is to use the LSB naming
scheme, only people who will have customized their devfs configuration
would have issues.

Oh, and there seem to be some people that rely on the devfs naming
scheme for block devices in /etc/fstab, for some odd reason.

Anyway, I don't think this will break any devfs usages, they can keep
using 2.4 and devfs all they want, the rest of the world will move on :)

thanks,

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

On Thu, Jul 07, 2005 at 03:55:45PM +0200, Martin Schlemmer wrote:
> 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?
> >
>
> Fine with me. I assume we will need to keep the rcscript support for
> those die-hard 2.4 users still, but hopefully we can eventually drop
> that as well.

What rcscript support?

> > Next up, that loony block device naming scheme (more on that later...)
> >
>
> Heh. I hope that we will still at least just do the cdsymlinks stuff
> (just the /dev/cdrom, /dev/dvd, etc stuff) as that do make things a bit
> easier for multimedia stuff.

Yes, I don't see us dropping that, as it's just too useful :)

> > [3] HAL needs a patch to be able to handle this. It's posted on the
> > hal development mailing lists and will be checked in real-soon-now.
>
> I just think we need to make sure this is in first ...

The HAL patch? It's now in HAL's cvs tree, don't know when they will do
a new release.

> 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"

Yes.

Want me to just change the default rule to yours?

thanks,

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

On Thu, 2005-07-07 at 13:52 -0700, Greg KH wrote:
> On Thu, Jul 07, 2005 at 03:55:45PM +0200, Martin Schlemmer wrote:
> > 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?
> > >
> >
> > Fine with me. I assume we will need to keep the rcscript support for
> > those die-hard 2.4 users still, but hopefully we can eventually drop
> > that as well.
>
> What rcscript support?
>

Err, sorry, all the crap in /sbin/rc ...

> > > Next up, that loony block device naming scheme (more on that later...)
> > >
> >

> > > [3] HAL needs a patch to be able to handle this. It's posted on the
> > > hal development mailing lists and will be checked in real-soon-now.
> >
> > I just think we need to make sure this is in first ...
>
> The HAL patch? It's now in HAL's cvs tree, don't know when they will do
> a new release.
>

Well, you did provide the patch, so hopefully foser or somebody else
will just add it. Foser ping ...

> > 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"
>
> Yes.
>
> Want me to just change the default rule to yours?
>

I do not think that will work, as that is not distributed with either
udev or device-mapper, but multipath-tools (sorda silly if you ask me,
as I think it would have been more appropriate with device-mapper, but
what the hey).

Anyhow, I'll see if I can hack a patch or something up so that NAME=""
will also be seen as as a rule that 'set the name' ....


Thanks,

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

On Fri, Jul 08, 2005 at 01:22:24AM +0200, Martin Schlemmer wrote:
> On Thu, 2005-07-07 at 13:52 -0700, Greg KH wrote:
> > On Thu, Jul 07, 2005 at 03:55:45PM +0200, Martin Schlemmer wrote:
> > > 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?
> > > >
> > >
> > > Fine with me. I assume we will need to keep the rcscript support for
> > > those die-hard 2.4 users still, but hopefully we can eventually drop
> > > that as well.
> >
> > What rcscript support?
> >
>
> Err, sorry, all the crap in /sbin/rc ...

Heh, yes. While looking in there, I was wondering if anyone would
object to splitting the udev and devfs stuff out of the main rc script,
like other parts have been split out? That way I could bundle the udev
portions in the udev package and then keep them up to date (like the
"save modified device nodes logic") ?

thanks,

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

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.

thanks,

greg k-h

--- 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"
--
gentoo-dev@gentoo.org mailing list

On Fri, Jul 08, 2005 at 02:39:51AM +0900, Georgi Georgiev wrote:
> maillog: 06/07/2005-15:46:51(-0700): Greg KH types
> > 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/
>
> Ah, that will break /etc/init.d/halt.sh
>
> Particularly the stuff around here:
>
> ebegin "Saving device nodes"
> ...
> cd /dev
> # Find all devices
> find . -xdev -type b -or -type c -or -type l | cut -d/ -f2- > \
> "${devices_real}"
> # Figure out what udev created
> eval $(grep '^[[:space:]]*udev_db=' /etc/udev/udev.conf)
> if [[ -d ${udev_db} ]]; then
> # New udev_db is clear text ...
> udevinfo=$(cat "${udev_db}"/*)
> else
> # Old one is not ...
> udevinfo=$(udevinfo -d)
> fi
> # This basically strips 'S:' and 'N:' from the db output, and then
> # print all the nodes/symlinks udev created ...
> ...
>
> The script will be unable to figure out what device is being handled by
> udev, and what is not.

Ugh, why do people care about tarballs of device nodes... :)

Anyway, yes, this will break that, but only in the way that it will save
more device nodes than it needed to, right? Which isn't really a bad
thing, as stuff will still work properly. But it's not the nicest.

Also, mind if I move this stuff out into the udev package itself? That
will let me keep it up to date with any udev changes (I wasn't even
aware that this checked for different versions of udev database info)
much easier.

thanks,

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

On Thursday 07 July 2005 00:46, 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/

Are there any ebuilds in the tree that are not sysfs/udev-aware? 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".
--
gentoo-dev@gentoo.org mailing list

On Fri, 8 Jul 2005 10:06:45 -0700
Greg KH <gregkh@gentoo.org> wrote:

> Heh, yes. While looking in there, I was wondering if anyone would
> object to splitting the udev and devfs stuff out of the main rc
> script, like other parts have been split out? That way I could
> bundle the udev portions in the udev package and then keep them up to
> date (like the "save modified device nodes logic") ?

I've been trying to get spanky to do this for a while now. If you
could help annoy him enough that he actually does it I would be happy.
--
gentoo-dev@gentoo.org mailing list

On Fri, 2005-07-08 at 19:16 +0100, Stephen Bennett wrote:
> On Fri, 8 Jul 2005 10:06:45 -0700
> Greg KH <gregkh@gentoo.org> wrote:
>
> > Heh, yes. While looking in there, I was wondering if anyone would
> > object to splitting the udev and devfs stuff out of the main rc
> > script, like other parts have been split out? That way I could
> > bundle the udev portions in the udev package and then keep them up to
> > date (like the "save modified device nodes logic") ?
>
> I've been trying to get spanky to do this for a while now. If you
> could help annoy him enough that he actually does it I would be happy.

If I remember correctly, you had to show your updated /sbin/rc first so
that we could see what is duplicate and what not :P


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

On Fri, 2005-07-08 at 10:06 -0700, Greg KH wrote:
> On Fri, Jul 08, 2005 at 01:22:24AM +0200, Martin Schlemmer wrote:
> > On Thu, 2005-07-07 at 13:52 -0700, Greg KH wrote:
> > > On Thu, Jul 07, 2005 at 03:55:45PM +0200, Martin Schlemmer wrote:
> > > > 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?
> > > > >
> > > >
> > > > Fine with me. I assume we will need to keep the rcscript support for
> > > > those die-hard 2.4 users still, but hopefully we can eventually drop
> > > > that as well.
> > >
> > > What rcscript support?
> > >
> >
> > Err, sorry, all the crap in /sbin/rc ...
>
> Heh, yes. While looking in there, I was wondering if anyone would
> object to splitting the udev and devfs stuff out of the main rc script,
> like other parts have been split out? That way I could bundle the udev
> portions in the udev package and then keep them up to date (like the
> "save modified device nodes logic") ?
>

Hmm, the udev stuff should be fine, as we can probably do that via
addons. The devfs stuff might be more of an issue, except if I leave
the devfsd restart stuff where it is (don't think it should be an
issue).

I'll whip something up over the weekend ...


Thanks,

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

On Fri, Jul 08, 2005 at 07:49:34PM +0200, Michiel de Bruijne wrote:
> On Thursday 07 July 2005 00:46, 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/
>
> Are there any ebuilds in the tree that are not sysfs/udev-aware?

Not that I am aware of. Anyone else know of any?

> 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 :)

thanks,

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

On Saturday 09 July 2005 00:25, Greg KH 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 :)

Same over here on all boxes maintained by me (21 with different hardware).
Using the tarball creates a lot of unnecessary clutter in /dev

If all ebuilds/enough ebuilds don't need to have the tarball, I would say
change the default and let all users enjoy the pure udev ride.
--
gentoo-dev@gentoo.org mailing list

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:
> > On Thursday 07 July 2005 00:46, 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/
> >
> > Are there any ebuilds in the tree that are not sysfs/udev-aware?
>
> Not that I am aware of. Anyone else know of any?
>

Neither. Or rather, I do not know about anything that should not work
with LSB /dev ...

> > 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.


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

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.
--
gentoo-dev@gentoo.org mailing list

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