Re: [gentoo-dev] Kernel sources thread

[Travis Tilley]

On Wednesday 21 July 2004 03:24 am, Travis Tilley wrote:
> On Wednesday 21 July 2004 01:28 am, Greg KH wrote:
> > On Sun, Jul 18, 2004 at 06:53:29PM -0400, Travis Tilley wrote:
> > If you have _any_ issues with udev, please let the developers and the
> > linux-hotplug-devel mailing list know about it.  Otherwise it will not
> > get fixed, and you will never be happy.
>
> just dont -force- udev on me and i'll be happy.
>
> > Oh, and that reminds me to go make up a "delete devfs" kernel patch to
> > send off to lkml, just to force the issue :)
>
> heh.

ok, trying to be just a bit more constructive. :)

1) udev is either ready or it isnt. the fact that you need to use a device 
tarball for entries udev doesnt support shows me that it isnt ready. what's 
the point of using a device management system if you're going to just dump a 
bunch of extra dev entries in there anyway? if udev were ready, this wouldnt 
be necessary.

2) 
ayanami portcvs # ldd `which udevd`
        libc.so.6 => /lib/libc.so.6 (0x0000002a9566d000)
        /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 
(0x0000002a95556000)
ayanami portcvs # emerge udev -pv | grep static
ayanami portcvs #

having a userspace dev management system seems flaky enough to me to begin 
with, but that's an opinion. having it non-static just means it's easier for 
me to break... usually when i accidentally break glibc or userspace in 
general (dont laugh... i found out the hard way that gcc 3.4 nuked stack 
smashing protection waaay back in the early revisions and it made every 
binary built with hardened gcc 3.3.x break after i recompiled glibc), i can 
just boot with init=/bin/sash or what have you and have things fixed in a 
handful of minutes... in similar situations of accidental breakage that are 
inevitable when you play with gcc/glibc i would like to have working device 
management. :P

i would also like the option to staticly link against a non-glibc c library, 
but that's more of a request than a need.

3) devfs isnt going away any time soon, and there will be people like me who 
dont think it's a good idea to risk bugs for no apparent benefit.

4) it makes sense to keep supporting devfs even after it's ripped out of the 
kernel, which i think isnt until after the /next/ stable kernel series. since 
we still support 2.4 as the default (on a few archs anyways) i think even 
when it is ripped out, people will be using a kernel series that still has it 
for a -while-. if it werent for this tendency to not use the latest stable 
kernel, i wouldnt have had to move the 2.6 linux-headers into their own 
package just to support nptl properly on archs other than amd64.


bah, i've been suckered into installing udev... so i might as well keep it 
until something breaks. i disabled the tarball hack since it was making /dev 
ugly and cluttered... though i admit it seems to be more ready than i thought 
it was. at least for now i can have both and always make devfs mount on 
boot... please dont think seriously about removing support for that. at least 
not until after we all move over to 2.10 anyways. :/

-- 

Travis Tilley <lv@g.o>

--
gentoo-dev@g.o mailing list