[PATCH] was: mdev doesn't remove devices

Rob Landley rob at landley.net
Tue Aug 29 20:53:55 UTC 2006


On Tuesday 29 August 2006 3:06 pm, Jason Schoon wrote:
> On 8/29/06, Rob Landley <rob at landley.net> wrote:
> >
> > On Monday 28 August 2006 5:21 pm, Jason Schoon wrote:
> > > Since we're on the topic of mdev already, I have a patch I had to create
> > > today that I thought I would run by the list.
> > >
> > > I am using mdev with a mdev.conf to launch a script file in certain
> > cases
> > > (basically it enables hotplugging on USB flash devices for me).
> > >
> > > In that script, I happened to add a line that sends its output to
> > /dev/null
> > > (i.e. 2>/dev/null).  Well, this just so happens to create an empty file,
> > > which then causes mknod of /dev/null to fail with an "already exists."
> >
> > You're calling this from a hotplug script that's called before /dev/null
> > exists.  This really sounds like pilot error to me.
> >
> > > So, my solution was to either make sure that my hotplug script never,
> > ever
> > > talks to a dev file (a poor assumption I feel),
> >
> > You're creating your devices via hotplug and you want to assume that
> > random
> > devices have already been created?
> >
> > > or to patch mdev to check if
> > > something is a regular file, and delete it.  Attached is a patch that
> > > accomplishes just that.  If someone else thinks that is a sane thing to
> > do,
> > > please apply.
> >
> > Isn't this really a special case for /dev/null?  Why not mknod /dev/null
> > from
> > your init script if your hotplug scripts are going to assume it exists
> > before
> > the hotplug scripts have been called?
> >
> > If you don't want to build in mknod, you can get mdev to do it:
> >
> >   ACTION=add DEVPATH=/sys/class/mem/null mdev
> >
> > Rob
> >
> 
> /dev/null already exists.

If that was the case, the file wouldn't get created.  You have a sequencing 
problem.

> I call mdev -s at system startup to populate my 
> initial set of devices.  The real problem is that in my mdev.conf I call out
> to a script that redirects some output to /dev/null.  Everytime mdev -s
> executed, it recreated a bogus /dev/null, and then when the mdev code itself
> tried to do the mknod, it returns an EEXIST.

Redirecting output to /dev/null doesn't cause a problem if /dev/null exists, 
it's only causing a problem if you've got stuff out of order and /dev/null 
doesn't exist yet so it creates a file instead.

That's why I suggested explicitly creating /dev/null, before the normal 
mdev -s run (which creates devices in an arbitrary order).

If the mdev.conf script creates this file on the actual call to /dev/null 
(rather than debris from some other device that's created first), then 
either:

A) Add an explicit rule for null that gets matched first, so it doesn't do 
that.

B) If you still want to run the script on null itself, you can control whether 
the script runs before or after the device gets created.  Run it _after_ 
creating it.

> There are a lot of other ways I can prevent the problem.  I couldn't think
> of a valid reason for a regular file to exist in /dev though, so I thought
> this could be a generic sledgehammer fix, at the cost of a call to stat().

I take the approach of not being able to think of a valid reason for a regular 
file to exist in /dev and going "so why add a permanent check for something 
that only exists if the person putting the system together screwed up"?

Is it mdev's job to guard against pilot error?  Goal #1 is to be small...

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list