From: "C. Brewer" <cbrewer@stealthaccess.net>
To: gentoo-dev@gentoo.org
Subject: [gentoo-dev] udev implementation
Date: Mon, 20 Oct 2003 22:56:19 -0700 [thread overview]
Message-ID: <200310202256.34889.cbrewer@stealthaccess.net> (raw)
[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2556 bytes --]
I tried out the 0.2 version of udev today, and I realize that its way rough
so early in the development, but I must say I was disappointed with it's
current implementation ( and the lousy attitude of the udev FAQ "if you don't
like it stick with devfs" didn't help). Currently I have some small concerns
about adopting this as a whole ( somewhere on down the line)-
1)The present package consists of a tarball with just about every device node
you could make (excepting small things like sound, ppp, more than 4 ttyS*'s)
Is this going to be a standard, or will some form of intuitive /dev entries be
imp'd? IIRC, the tarball is about 1.4k device nodes, and I think I need 100
on the outside.
2) Since this won't automatically create these nodes ( unless a hotplug event
occurs), or load the dependent modules, doesn't this seem like a step back to
the old system, but with a name-mapping steroided hotplug?
3) Don't get me wrong..I'm not flaming the package,and I realize devfs is crap
as well..but the score is devfsd( crap but makes nodes and loads mods on the
fly) and udev (maps names and supposedly does stuff with hotplugging that
hotplug never amounted to.( and is dev'd by the hotplug peeps?ironic)). All
that aside, what is udev going to do for the desktop? I have devices I could
swap(USB) but with most comps coming with like 6 usb ports, I cant see more
than some pendrive swapping at user level. Yeah, I know theres peeps out
there with 80 pendrives and 8 hot-swappable hdd's, but is this the majority
of users? For the likely many of us who dont need to swap and have had the
same hardware on the same nodes that dont ever change..what does udev bring
to the table?
Forgive me if I've gone delusional.. I was just under the impression that udev
was going to do everything that devfsd does now _and_ add name mapping, and
apparently I was wrong. I'm just planning for the future since seeing the
udev changes going into our init system.. we got no choice about the devfs
and I feel it's going the same way for udev. I'm not trying to slight the
obviously hard work that was put into it, but what about choice? to devfs or
not to devfs? to udev or not to udev? Or is it merely choice with package
selection, and not with the overall package that is Gentoo?
Criticism appreciated, discussion welcomed, craziness and flames- please pipe
to /dev/null:)
--
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2003-10-21 5:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-21 5:56 C. Brewer [this message]
2003-10-21 6:17 ` [gentoo-dev] udev implementation Jon Portnoy
2003-10-21 15:14 ` C. Brewer
2003-10-21 17:09 ` Jon Portnoy
2003-10-21 7:43 ` Christian Birchinger
2003-10-21 7:49 ` Jon Portnoy
2003-10-21 8:01 ` Ernst Herzberg
2003-10-21 20:36 ` Martin Schlemmer
2003-10-21 21:45 ` C. Brewer
2003-10-22 2:33 ` Mike Frysinger
2003-10-22 2:50 ` C. Brewer
2003-10-22 4:27 ` Martin Schlemmer
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=200310202256.34889.cbrewer@stealthaccess.net \
--to=cbrewer@stealthaccess.net \
--cc=gentoo-dev@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