Subject: Re: Ideas about the cdevsw/bdevsw structs.
To: Anders Magnusson <ragge@ludd.luth.se>
From: Chris G. Demetriou <cgd@netbsd.org>
List: tech-kern
Date: 05/16/1999 17:00:46
[ sorry for any typos and lack of clarity, but i'm in a hurry and i
thought this needed to be replied to asap.]

Anders Magnusson <ragge@ludd.luth.se> writes:

> Idea: 
> 	All devices are registered when they are attached. The attach
> 	(or similar) function calls a register function with a syntax
> 	like:
> 
> 		int devsw_register(struct device *,
> 		    struct bdevsw *, struct cdevsw *);
> 
> 	The devsw ptr's can be NULL if it isn't applicable (like for
> 	tty devices no block device). The device struct is used for
> 	registering the device name in a (future) devfs, and is NULL
> 	otherwise. The chrtoblk table is maintained from this function.
> 
> 	Returns zero on success, and some errno otherwise (E2BIG, EEXIST, ...).

It's not clear what use the 'struct device *' actually is, unless it's
your intent to add functions to 'struct cfdriver' for a 'devfs'...


Also, i think this is a bit flawed.  you want the devsw entries to be
common to all instances of a single device type, and you don't really
represent that in this interface.

really, what you probably want is to have the 'struct cfdriver's for
devices which needs device switch entries to just have pointers to the
switch entries in them, then do this all under the covers.

The only place where you might lose there is if a device needs
multiple c or b devsw entries, but really, the interface you've
proposed doesn't seem to cope well with that case as-is.  (not sure if
it's necessary, but if it is...)


> 	Similar, a function:
> 
> 		int devsw_unregister(struct bdevsw *, struct cdevsw *);
> 
> 	is called to detach a device.

uh, probably much better to have register provide a cookie that can be
used to unregister the device.

or maybe just "store it in the 'struct device', then if register
returns OK you can unregister."  (and call unregister with 'struct
device *')


> 	The devsw* functions can be in kern_subr if noone has a better
> 	idea. They are rather small.

If the intent is that they modify things in struct device, and are
used as part of 'autoconfiguration,' subr_autoconf is probably better.


> 	config(8) is changed to include and use this defines in swapnetbsd.c
> 	instead of getting the majors out of the "files" file. No need to
> 	duplicate info :-)

uh, you can probably do the right things to 'config' (use device name
in swapnetbsd.c) to get rid of the needs for 'major' anyway.


really, sounds like the a good solution might be to bury this all in
the existing configuration machinery....


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.