> [ sorry for any typos and lack of clarity, but i'm in a hurry and i
> thought this needed to be replied to asap.]
> 
Well, I do not plan to rush anything in, "a couple of days" means for 
me 2-3 weeks :-)

> 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'...
> 
No, it's to extract the device name and put it into the devfs, if wished.
It's unneccessary if you're only going to register a device and not want/
want special entries in devfs.
The devfs parts is a chapter for itself.

> 
> 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.
> 
This requires that it is generated when compiling a kernel. I want
to keep this away from dependencies of statically linked kernels.
The ideal solution would be a LKM system that talks with the "normal"
autoconf stuff and fixes this. Humm, it might be an idea... :-)

> 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...)
> 
The only situation I know of where this is used is for ra disks in Ultrix,
which only have 16 bit dev_t and can have up to 255 disks of the same type.
I can't think of any situation where we will encounter this problem while
using 20 bits for minor device.

> 
> > 	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 *')
> 
That _is_ a much better way of doing it, indeed.  I'll rethink this.

> 
> really, sounds like the a good solution might be to bury this all in
> the existing configuration machinery....
> 
Yes, it is.
This gave me lots of new ideas! Great! I'll rethink this and come up
with a new proposal. This was the perfect type of followup :-)

-- Ragge