public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Chris Gianelloni <wolf31o2@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Kernel sources thread
Date: Wed, 21 Jul 2004 16:40:10 -0400	[thread overview]
Message-ID: <1090442410.11373.139.camel@localhost> (raw)
In-Reply-To: <200407210634.21992.lv@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 2584 bytes --]

On Wed, 2004-07-21 at 06:34, Travis Tilley wrote:
> 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.

Most of those drivers are not sysfs-aware and simply have not been
updated by the various authors.  Most of them are non-kernel modules,
such as VMware.

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

Perhaps the next stable kernel version, if what I've been reading holds
true.

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

Agreed, we will have to maintain support for some time to come.

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

I find the flexibility it gives me to be much better than devfs, and I
enjoy having the "standard" Linux device naming that we're all used to
having from before devfs.  Currently, I use it to create custom /dev/
entries for specific pieces of hardware, like /dev/usbkey and
/dev/archos, along with the "standard" device nodes for those devices,
so I could setup hotplug.d with a script to automatically mount them
upon them being plugged into my machine.  I find it to be far superior
to using devfs+supermount, since there's nothing "fooling" the kernel
into thinking a device is always mounted.

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

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2004-07-21 20:13 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-16 22:30 [gentoo-dev] Kernel sources thread Joel Konkle-Parker
2004-07-16 23:36 ` Grant Goodyear
2004-07-16 23:45   ` Ciaran McCreesh
2004-07-17  0:06     ` Greg KH
2004-07-17  0:32       ` Ciaran McCreesh
2004-07-18 17:53         ` Dylan Carlson
2004-07-18 18:10           ` Ciaran McCreesh
2004-07-18 19:18             ` Dylan Carlson
2004-07-21  5:32               ` Greg KH
2004-07-18 21:23             ` Georgi Georgiev
2004-07-21  5:38               ` Greg KH
2004-07-21  5:59                 ` Georgi Georgiev
2004-07-21 13:29                 ` Paul Varner
2004-07-22  6:55                   ` Greg KH
2004-07-25 16:14                     ` Paul Varner
2004-07-25 16:55                       ` Ciaran McCreesh
2004-07-25 17:51                         ` Paul Varner
2004-07-26 14:26                       ` Chris Gianelloni
2004-07-26 21:25                         ` Donnie Berkholz
2004-07-26 23:27                           ` Georgi Georgiev
2004-07-27 12:38                           ` Chris Gianelloni
2004-07-21 20:29                 ` Chris Gianelloni
2004-07-21  5:29             ` Greg KH
2004-07-18 22:53           ` Travis Tilley
2004-07-18 23:22             ` Ciaran McCreesh
2004-07-19  0:00             ` Martin Schlemmer
2004-07-21  5:28             ` Greg KH
2004-07-21  7:24               ` Travis Tilley
2004-07-21 10:34                 ` Travis Tilley
2004-07-21 11:04                   ` Carsten Lohrke
2004-07-22  7:40                     ` [gentoo-dev] " Duncan
2004-07-22 10:44                       ` Carsten Lohrke
2004-07-21 14:47                   ` [gentoo-dev] " Georgi Georgiev
2004-07-21 18:16                   ` Greg KH
2004-07-21 19:46                     ` Ciaran McCreesh
2004-07-22 19:05                       ` Martin Schlemmer
2004-07-24  4:09                       ` Greg KH
2004-07-21 20:40                   ` Chris Gianelloni [this message]
2004-07-22 19:06                     ` Martin Schlemmer
2004-07-22 20:11                       ` Mike Frysinger
2004-07-22 20:42                         ` [gentoo-dev] RFC: factoring logic for selection of "safe" gcc -O flags in ebuilds (uclibc users take note) Gavin
2004-07-23  4:51                           ` Andrew Ross
2004-07-22 21:44                         ` [gentoo-dev] Kernel sources thread Martin Schlemmer
2004-07-23  3:31                       ` Georgi Georgiev
2004-07-24 16:27                         ` Martin Schlemmer
2004-07-25  1:43                           ` Georgi Georgiev
2004-07-25  6:44                           ` Norberto Bensa
2004-07-25 17:56                           ` Georgi Georgiev
2004-07-21 16:04                 ` Norberto Bensa
2004-07-21 18:07                 ` Greg KH
2004-07-21  5:42         ` Greg KH
2004-07-17  5:33 ` Wade Nelson
2004-07-17  6:19   ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1090442410.11373.139.camel@localhost \
    --to=wolf31o2@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox