On 20 Feb 2001 eeh@netbsd.org wrote:
	> 	  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.

	  Give them device nodes.  This would be very easy with devfs.  Until then
	you could still use them in the kernel.

	  (I also think that sysctl should be converted to be ioctl on special
	devices, but that needs some changes to ioctl to deal with larger data.)

Solaris has done this, and boy, has it become a huge mess.  There
is a proliferation of device minor nodes, each with a screwey name.
To do many common operations you need to walk the /devices filesystem
and correlate different device nodes so you can make sure you're 
talking to the right one.  There are also huge libraries to handle
simple operations such as hot-swapping a disk, which may involve up
to a half dozen device nodes.  I don't think this is a good way to
implement things.

	>> 	  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.

	  The idea is that struct device eventually replaces dev_t and
	bdevsw/cdevsw go away (and the appropriate compatibility numbers appear in
	emulation code).  Also, you should not need to open the device to do an
	ioctl in the kernel.

	> Anyway, I think this will end up being a much bigger change than
	> just device properties.

	  It is a bigger change, but you do not need to do the major number
	removal now.  You would still have a driver flag day, but it would save
	adding yet another properties mechanism.

	> 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.

	  You need devfs before you can completely remove major numbers.  Use the
	permissions of the file of the same name as the device on the mount point
	(and do not allow access if it doesn't exist).  Being able to walk the
	device tree should make implementation of this fairly easy.

Once devfs is implemented, hooking something in to access property
information should be trivial.  Tell ya what: you implement devfs
and I'll add the property hooks to it.

Eduardo