From: Oliver Neukum <oliver@neukum.org>
To: Steven Dake <sdake@mvista.com>
Subject: Re: [PATCH] udev enhancements to use kernel event queue
Date: Fri, 13 Jun 2003 00:27:09 +0200
User-Agent: KMail/1.5.1
References: <3EE8D038.7090600@mvista.com>
In-Reply-To: <3EE8D038.7090600@mvista.com>
Cc: linux-kernel@vger.kernel.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200306130027.09288.oliver@neukum.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1693
Lines: 59


> If it works for you or doesn't or you like the idea or don't, I've love
> to hear about it

+	default:
+		result = -EINVAL;
+		break;
+	}
+	return (result);

Must return ENOTTY.

+static int sdeq_open (struct inode *inode, struct file *file)
+{
+	MOD_INC_USE_COUNT;
+
+	return 0;
+}
+
+static int sdeq_release (struct inode *inode, struct file *file)
+{
+	MOD_DEC_USE_COUNT;
+
+	return (0);
+}

Wrong. release does not map to close()


Aside from that, what exactly are you trying to do?
You are not solving the fundamental device node reuse race,
yet you are making necessary a further demon.
You are not addressing queue limits. The current hotplug
scheme does so, admittedly crudely by failing to spawn
a task, but considering the small numbers of events in
question here, for the time being we can live with that.

You can just as well add load control and error detection
to the current scheme. You fail to do so in your scheme.
You cannot queue events forever in unlimited numbers.

As for ordering, this is a real problem, but not fundamental.
You can make user space locking work. IMHO it will not be
pretty if done with shell scripts, but it can work.
There _is_ a basic problem with the kernel 'overtaking'
user space in its view of the device tree, but you cannot solve
that _at_ _all_ in user space.

In short, if you feel that the hotplug scheme is inadequate
for your needs, then write industry strength devfs2.

	Regards
		Oliver

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/