Fix nagging make_dev() warnings
Frank W. Josellis
frank at dynamical-systems.org
Fri Sep 8 01:26:41 PDT 2006
On Thu, 7 Sep 2006, Simon 'corecode' Schubert wrote:
> [...]
>
> i'm not sure if dev->si_ops->head.flags is the right place to add D_NAGGED,
> but something like this seems to be the right thing.
>
Let's recall that in kernel mode dev_t is a pointer to a struct specinfo
(defined in <sys/conf.h>), where the former struct cdevsw member from
FreeBSD has been replaced by a struct dev_ops for Dragonfly. With that in
mind it's not difficult to see where these flags should go. However, we
still need an explanation why the warning is issued at all, and meanwhile
I think that this becomes clear from inspecting the function spec_open()
in spec_vnops.c:
Here we deal with a dev_t dev obtained via udev2dev(), in which respect
Dragonfly behaves significantly different from FreeBSD. Indeed, from
sys/kern/kern_conf.c we see that udev2dev() calls hashdev(), and that for
the returned dev_t the member dev->si_name is *not* set as it could be
expected for FreeBSD 4.x. In particular, for the dev in question we expect
devtoname(dev) to return "consolectl" with FreeBSD 4.x, whereas we get
"#sc/255" with Dragonfly. But that's not a bug, that's a feature resulting
from using udev2dev(). You may wish to turn on some debugging output for
hashdev() to see what devtoname() actually returns for the various
devices.
So the problem appears to be solved by just dropping that obsolete
warning, it's completely useless now (patch below).
Regards,
Frank Josellis
--- patch begins here ---
--- sys/vfs/specfs/spec_vnops.c.orig 2006-08-12 02:25:58.000000000 +0200
+++ sys/vfs/specfs/spec_vnops.c 2006-09-08 08:21:33.000000000 +0200
@@ -266,13 +266,6 @@
dev->si_bsize_phys = DEV_BSIZE;
vinitvmio(vp, IDX_TO_OFF(INT_MAX));
}
- if ((dev_dflags(dev) & D_DISK) == 0) {
- cp = devtoname(dev);
- if (*cp == '#') {
- printf("WARNING: driver %s should register devices with make_dev() (dev_t = \"%s\")\n",
- dev_dname(dev), cp);
- }
- }
/*
* If we were handed a file pointer we may be able to install a
--- patch ends here ---
More information about the Bugs
mailing list