Subject: Re: Ideas about the cdevsw/bdevsw structs.
To: Chris G. Demetriou <firstname.lastname@example.org>
From: Anders Magnusson <email@example.com>
Date: 05/17/1999 02:34:13
> [ 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 <firstname.lastname@example.org> 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 :-)