Subject: Re: More Device Properties
To: None <,>
From: None <>
List: tech-kern
Date: 02/20/2001 07:24:34
	On 16 Feb 2001 wrote:
	> The second phase will separate the `struct device' from the device's softc.
	> config_create(9) will create the true device node, which config_found*(9) will
	> attach to the device tree.  If the device probes successfully,
	> config_attach(9) will allocate a separate device softc structure and link it
	> to `struct device'.  If devices are detached, the `struct device' will remain
	> with all its properties but the softc will be destroyed.  This change will
	> cause breakage in practically all existing device drivers, so it will be
	> relegated to some future date.

	  Going a little further in this direction, how about using ioctl for
	properties?  Many of the properties could be interesting to userland as
	well, and ioctl already has a type mechanism.

I thought that something more akin to sysctl() would be a better
match.  The problem with ioctl() is that it requires an open device
node.  Many devices don't have device nodes, such as bus controllers.
I expect them to have at least as many interesting properties as 
the devices that do have device nodes.

	  To do this, the driver entry points need to be made accessable from the
	struct device.  This is also the fist step in removing the internal use of
	major numbers.

I don't see how that follows.  What do you need the device entry
points if you have a pointer to the device itself.  If you use
an ioctl() the device is already open so you go through the device's
entry point.  If you use a different mechanism then you bypass
the driver entirely and don't need its entry points.

Anyway, I think this will end up being a much bigger change than 
just device properties.  Getting rid of major/minor requires 
changing the entire concept of a device node.  How do you link 
an inode on a disk to an in-memory structure that's created 
anew each boot?  Pointers certainly wouldn't work.

sysctl also has issues, since it uses a static namespace and
does not have facilities for probing it.  I hate to say this,
but probably the most straight-forward way to provide access
to device properties would be through a devfs.