public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ed Sweetman <safemode@speakeasy.net>
To: Alexander Viro <viro@math.psu.edu>
Cc: "Barry K. Nathan" <barryn@pobox.com>, linux-kernel@vger.kernel.org
Subject: Re: devfs
Date: 18 Aug 2002 19:15:49 -0400	[thread overview]
Message-ID: <1029712550.3331.43.camel@psuedomode> (raw)
In-Reply-To: <Pine.GSO.4.21.0208181852450.3920-100000@weyl.math.psu.edu>

On Sun, 2002-08-18 at 19:03, Alexander Viro wrote:
> 
> 
> On 18 Aug 2002, Ed Sweetman wrote:
> 
> > This has nothing to do with not mounting devfs and still using devfs to
> > work with devices.   If devfs is not mounted but you're still using
> > devfs, you shouldn't need anything in /dev.   The documentation says you
> > can use devfs without mounting and This is what i'm saying is
> > problematic and doesn't seem possible in normal usage.   It's an
> > optional config so are we using devfs when we dont mount it or not?  
> > and if not, then why make not mounting it an option ? 
> 
> What?  If program calls open("/dev/zero",...) and there's no such file,
> how the fuck would having devfs enabled help you?
> 
> Come on, use common sense - devfs provides a tree with some device nodes.
> You can mount it wherever you want (or not mount it anywhere).  Just as
> with any other filesystem.
> 
> If you mount it on /dev - well, duh, you see that tree on /dev.  If you
> do not - you see whatever is in /dev on underlying fs.
> 
> If program wants to access a device, it opens that device.  Just as any
> other file.  By name.  There is nothing magical about names that begin
> with /dev/ - it's just a conventional place for device nodes.
> 
> devfs "mount" option is an idiotic kludge that makes _kernel_ mount
> it on /dev after the root fs had been mounted.  Why it had been
> introduced is a great mistery, since the normal way is to have a
> corresponding line in /etc/fstab and have userland mount whatever
> it needs.
> 
> Said option is, indeed, not required for anything - in a sense that
> it does nothing that system wouldn't be perfectly capable of in regular
> ways.
> 
> But you _do_ need stuff in /dev, no matter what filesystem it comes
> from.  Kernel doesn't need it, but userland programs expect to find
> it there.  If you had deleted device nodes from underlying /dev and
> do not care to mount something on top of it - well, there won't be
> anything in that directory.
> 

Ok, that all makes sense.  I removed the dev entries because they
weren't needed by me anymore but I suppose it doesn't hurt anything to
just keep them there anyways so I've fixed all that.   Either way,
removing devfs did nothing but apparently it was asked to be done to
allow better testing and/or debugging to be done.  But i've yet to get
any reason why I removed devfs to investigate promise ide controller's
dma related memory failures.  I've removed devfs and replaced the old
/dev entries, no problem.  I'm not getting off topic about that.  It's
all done so i'm waiting for the next step here.  


  reply	other threads:[~2002-08-18 23:11 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-18  6:44 cerberus errors on 2.4.19 (ide dma related) Ed Sweetman
2002-08-18  7:15 ` Ed Sweetman
2002-08-18  9:19   ` Andre Hedrick
2002-08-18 18:11     ` Ed Sweetman
2002-08-18 18:31     ` Ed Sweetman
2002-08-18  7:26 ` Ed Sweetman
2002-08-18  9:00   ` Barry K. Nathan
2002-08-18  9:13     ` Ed Sweetman
2002-08-18 17:50   ` Jonathan Lundell
2002-08-18 18:04     ` Ed Sweetman
2002-08-18  9:10 ` Alexander Viro
2002-08-18  9:16   ` Ed Sweetman
2002-08-18 18:10     ` Ed Sweetman
2002-08-18 18:20       ` Sean Neakums
2002-08-18 18:29         ` Ed Sweetman
2002-08-18 18:36           ` Sean Neakums
2002-08-18 21:53             ` Barry K. Nathan
2002-08-18 22:26               ` devfs Ed Sweetman
2002-08-18 22:47                 ` devfs Sean Neakums
2002-08-18 23:03                 ` devfs Alexander Viro
2002-08-18 23:15                   ` Ed Sweetman [this message]
2002-08-21  4:49                     ` devfs Richard Gooch
2002-08-21  5:03                       ` devfs Ed Sweetman
2002-08-19  1:06                   ` devfs Olivier Galibert
2002-08-19  2:01                     ` devfs Greg KH
2002-08-18 23:18                 ` devfs Barry K. Nathan
2002-08-18 22:41           ` cerberus errors on 2.4.19 (ide dma related) Andrew Rodland
2002-08-18 22:55             ` Ed Sweetman
2002-08-19 21:46               ` Ed Sweetman
2002-08-18 19:53       ` Ed Sweetman
2002-08-18 20:07         ` Andre Hedrick
2002-08-18 20:29           ` Ed Sweetman
2002-08-23  0:03             ` Samuel Flory
2002-08-19  0:06       ` Denis Vlasenko
  -- strict thread matches above, loose matches on Subject: below --
2002-11-12  9:32 devfs Ian Molton
2002-11-12  9:43 ` devfs Xavier Bestel
2002-11-12  9:49   ` devfs john slee
2002-11-12 10:01     ` devfs Sean Neakums
2002-11-12 12:51       ` devfs Oliver Neukum
2002-11-12 10:05     ` devfs Xavier Bestel
2002-11-12 10:04   ` devfs Alexander Viro
2002-11-12 10:25     ` devfs Ian Molton
2002-11-12 10:46       ` devfs Dave Jones
2002-11-12 11:08         ` devfs Ian Molton
2002-11-12 11:24         ` devfs Rando Christensen
2002-11-12 13:30           ` devfs Alexander Viro
2002-11-12 14:53         ` devfs Alan Cox
2002-11-12 15:37           ` devfs Ian Molton
2002-11-12 11:29     ` devfs Helge Hafting
2002-11-12 15:40   ` devfs 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=1029712550.3331.43.camel@psuedomode \
    --to=safemode@speakeasy.net \
    --cc=barryn@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@math.psu.edu \
    /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