devfs
[Top] [All Lists]

Re: devfs1.3.10

To: Jeremy Brown <mee@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: devfs1.3.10
From: Richard Gooch <rgooch@xxxxxxxxxxxxxxx>
Date: Fri, 4 Aug 2000 08:10:20 +0200
Cc: Xuan Baldauf <xuan--reiserfs@xxxxxxxxxxx>, devfs@xxxxxxxxxxx
In-reply-to: <398602B3.7B0D499D@engr.sgi.com>
References: <39821840.41C1F3E1@baldauf.org> <3984CB3F.23AF646C@engr.sgi.com> <3985221F.CE066AC2@baldauf.org> <398602B3.7B0D499D@engr.sgi.com>
Sender: owner-devfs@xxxxxxxxxxx
Jeremy Brown writes:
> Xuan Baldauf wrote:
> > 
> > Jeremy Brown wrote:
> [cut]
> > > I have experienced exactly the same behavior on TurboLinux 6.0 with
> > > modutils 2.3.11-1. Do you also see a stream of "Cannot locate module
> > > /dev/<something>" at boot?
> > 
> > I do this too, but also when placing "include /etc/modules.conf" to the top
> > of /etc/modules.devfs. But I'm sure this time the remaining problem is
> > somewhere in the init scripts, a process wants to access /dev/xconsole where
> > no xconsole is. I have to track it down.
> 
> It seems to me to be coming from the autoload functionality of devfs,
> because the messages go away when I comment that line out. My guess is
> that devfs is attempting a modprobe of every device that appears in
> /dev, so that it can build a database of modules that it will need to
> load when those devices are accessed. REG, is this pretty close to the
> truth? Is there a way to suppress those warnings?

No, devfs doesn't try to autoload every possible device. All autoloads
are triggered by non-devfsd user-space processes. So check your boot
scripts and any daemons that are started up at boot time.

                                Regards,

                                        Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current:   rgooch@xxxxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>