Date: Tue, 20 Jul 1999 21:15:16 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Alfred Perlstein <bright@rush.net> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/dev/vn vn.c src/sys/kern kern_conf.c vfs_subr.c src/sys/miscfs/specfs spec_vnops.c specdev.h src/sys/sys conf.h param.h types.h vnode.h src/sys/ufs/mfs mfs_vfsops.c Message-ID: <21804.932498116@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 20 Jul 1999 14:34:24 EDT." <Pine.BSF.3.96.990720142949.27774F-100000@cygnus.rush.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.3.96.990720142949.27774F-100000@cygnus.rush.net>, Alfred P
erlstein writes:
>Any other reasons?
Yes, several in fact.
The primary goal is to get us to the point where we can have a
daemon running which handles dynamic devices. You have already
seen how much noise a pccard ethernet can make in the mailing lists
when it comes to what should happen when it is plugged in, but that
is only the beginning. In short we want to be able to run a "devd"
which can be instructed to do what we want to happen when devices
are attached or disappear on the fly.
Another major goal is to get beyond the #define NFOO limitation
for device drivers. Most device drivers can absorb any number of
devices, but we have this "struct softc {...} sc[NFOO];" thing all
over the place, and weird "devtofoo()" macros to unravel the minor
device number into whatever is encoded there. The next step in
this little operation will allow device drivers to do something
like:
foo_probe(...)
{
struct softc *sc;
dev_t dev;
peek;
poke;
check;
if (!found)
return nothing;
MALLOC(sc, ...)
sc->this = something;
sc->that = something_else;
dev = create_dev(DEV_CMAJ, my_unit * 8, "foo%d", my_unit);
dev->driver1 = (void *) sc;
dev->driver2 = (void *) 0;
dev = create_dev(DEV_CMAJ, my_unit * 8, "foo%d.ctl", my_unit);
dev->driver1 = (void *) sc;
dev->driver2 = (void *) 1;
dev = create_dev(DEV_CMAJ, my_unit * 8, "foo%d.reset", my_unit);
dev->driver1 = (void *) sc;
dev->driver2 = (void *) 2;
my_unit++
}
foo_open(dev_t dev, ...)
{
struct softc *sc;
int subdev;
sc = dev->driver1;
subdev = dev->driver2;
switch (subdev) {
case 0: /* The real thing */
...
case 1: /* Control device */
...
case 2: /* Reset device */
...
}
...
}
At this point Alert readers have already looked at the devfs_add_devswf()
calls and have started to mumble things I'm sure: And yes, that is
the next place we can go with this. The fundamental design error
in DEVFS was to "bolt it onto the side" (of something that's bolted
onto the side of something that's...)
I have not decided how to tackle this in details, but the one thing
which is quite certain is that some kind of message passing when
devices are created/destroyed will be needed to keep a user-land
agent/daemon abreast with developments. I don't think we need to
copy the entire route-table "protocol" approach, a less heavy-duty
mechanism will do.
But apart from that a some obvious overall cleanups presents
themselves now that we have a central "per device" structure in
the system:
The tty pointer could be put there, and devtotty can go
away.
Pointers to disk slice/label data can be put there and much
of the ds*() calls can leave the disk drivers and be put
entirely at a generic level.
I havn't looked (I'll leave that to others) but maybe the
VM system (the device-pager ?) may want to hang a thing or
two off the specinfo structure.
We can implement a dev->name translating sysctl, and printfs
in the kernel can print a canonical device name rather than
some cryptic numbers.
In the long run, block-devices can go away (seen from userland
at least).
if somebody wants to tackle any of these bits or other that they see,
the field is open to everybody.
--
Poul-Henning Kamp FreeBSD coreteam member
phk@FreeBSD.ORG "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21804.932498116>