public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Bradley W. Allen" <ULMO@Q.NET>
To: linux-kernel@vger.kernel.org
Cc: ulmo@q.net
Subject: Re:  DevFS vs. udev
Date: Tue, 23 Dec 2003 03:51:58 -0800	[thread overview]
Message-ID: <E1AYl4w-0007A5-R3@O.Q.NET> (raw)

DevFS was written by an articulate person who solved a lot of
problems.  udev sounds more like a thug who's smug about winning,
not explaining himself, saying things like "oh, the other guy
disappeared, so who cares, you have to use my code, too bad it sucks".

Just by what the udev people have said I have decided never to use it,
and to return to DevFS.  Thank god for linux-kernel archives.

A few points:

*  User space is slow, causing all sorts of extra work for device
   accesses.
*  Another layer of filesystem for udev to have to interact with
   is also slow, especially if it has to be disk based with all sorts
   of extra caches, and also if it's with buggy tmpfs code and layers.
*  Most of the interesting devices I have now are character devices,
   and have multiple potential /dev entries per device.  I've heard
   that udev can't even handle that requirement!
   Udev has lots of other problems, like something called an anonymous
   device, and it not being fully implemented, however, that's OK for
   development.  We're in 2.6.0, now, so that's not OK!  DevFS has been
   solid for over half a decade, so it belongs in stable kernels.
*  Many times a broken record comes out with claims.  Here are a few:
   "... there are still unfixable devfs bugs in the code." without
   any examples, so I don't believe him (Greg K-H).  Others have looked
   and not found that.
*  Userspace is not the proper place for kernel device drivers or
   anything they need to work.
*  We do not need the same old maintainer for devfs.  We can create
   new code, and maintain old code, as a group, ourselves.
*  Greg K-H (what that dash is for I can't imagine) claims that DevFS
   is experimental and proof of concept; well, it has been in production
   use for over half a decade, which in the life of Linux is pretty long.
   It's certainly not just some experiment any more.
*  Greg K-H refers to "hahahaha" and "the OLS paper" and "sysfs",
   things that most Linux kernel compilers, linux-kernel readers, and
   DevFS users (including lots of admins) have probably never ever
   heard of except the bad attitude of the hahaha part.
*  Someone named viro said "the latter had stayed, period" refering to
   udev, which means absolutely nothing, but expected it to mean
   something.
*  Viro also said that devfs had been "shoved" into the tree, and
   that it "had stayed around for many months".  It's been stable for
   many *YEARS*, for most of a *DECADE*.

I've spent two hours on this problem, and that's absurd; stable shouldn't
be doing this sort of thing to us.  Yes, we know there are things that
happen during transition from development to stable, but to have some
terrorist hijack part of the kernel and destroy it right at the begin-
ing of stable is simply criminal thinking.  Luckily, this is just
software, so we can do what we want with it, but organizationally it
is conceptually just as bad.

             reply	other threads:[~2003-12-23 11:52 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-23 11:51 Bradley W. Allen [this message]
2003-12-23 12:06 ` DevFS vs. udev Duncan Sands
2003-12-23 12:12 ` Xavier Bestel
2003-12-23 12:37   ` Marcelo Bezerra
2003-12-23 13:02     ` Ed Tomlinson
2003-12-25 12:11     ` Kai Henningsen
2003-12-23 14:30 ` Paul Dickson
2003-12-23 23:23   ` Bradley W. Allen
2003-12-23 23:46     ` Brett
2003-12-24  4:01     ` alex.g.goddard.1
2003-12-23 16:19 ` Ian Kent
2003-12-23 17:34   ` Mark Mielke
2003-12-23 22:02     ` Greg KH
2003-12-23 22:13       ` Tomasz Torcz
2003-12-24  0:45       ` Martin Schlemmer
2003-12-24  1:07         ` Greg KH
2003-12-24  1:22           ` memory mapping help - oracle stack dumps Paul
2003-12-27 21:13             ` Francois Romieu
2003-12-24  1:28           ` DevFS vs. udev Martin Schlemmer
2003-12-23 21:59 ` Greg KH
2003-12-24  1:52   ` Ian Kent
2003-12-24  2:03     ` Rob Love
2003-12-24  2:21       ` Ian Kent
2003-12-24  2:22         ` Rob Love
2003-12-24  2:32           ` Stan Bubrouski
2003-12-24  2:39             ` Rob Love
2003-12-24  2:38     ` Andrew Morton
2003-12-24  3:41       ` viro
2003-12-24 11:33         ` Witukind
2003-12-24  4:13 ` Rusty Russell
2003-12-24  4:38   ` Stan Bubrouski
2003-12-24 11:15     ` Xavier Bestel
2003-12-24 13:44       ` Ian Soboroff
2003-12-24 14:17         ` Xavier Bestel
  -- strict thread matches above, loose matches on Subject: below --
2003-10-07 12:38 devfs " Måns Rullgård
2003-10-07 13:41 ` Andreas Jellinghaus
2003-10-07 14:07   ` Måns Rullgård
2003-10-07 14:23     ` Robert L. Harris
2003-10-07 14:29       ` Måns Rullgård
2003-10-07 16:06       ` Andreas Jellinghaus
2003-10-07 16:11         ` Måns Rullgård
2003-10-07 16:14         ` Robert L. Harris
2003-10-07 16:54         ` Hugo Mills
2003-10-07 17:19           ` Måns Rullgård
2003-10-07 17:47             ` Greg KH
2003-10-07 17:49           ` Greg KH
2003-10-07 17:58             ` Hugo Mills
2003-10-07 18:10               ` Greg KH
2003-10-09 13:43             ` Ian Kent
2003-10-09 20:54               ` Greg KH
2003-10-07 17:55     ` Greg KH
2003-10-14 13:51     ` Ian Kent
2003-10-17  4:34       ` Greg KH
2003-10-07 17:54   ` Greg KH
2003-10-07 14:01 ` tabris
2003-10-07 17:53 ` Greg KH
2003-10-07 18:24   ` viro

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=E1AYl4w-0007A5-R3@O.Q.NET \
    --to=ulmo@q.net \
    --cc=linux-kernel@vger.kernel.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