strict weak aliases
Sometimes it is important that the type of an object matches the
type of its weak alias. See the attached patch that both adds a
type-safe __weak_alias() called __strict_weak_alias(), and fixes a buggy
__weak_alias() that __strict_weak_alias() would have caught during
compilation.
Thanks to Taylor R. Campbell for the incantation that was key
to making this work,
__unused static typeof(alias) *__weak_alias_##alias = sym;
Does this look ok to commit?
Dave
--
David Young OJC Technologies
dyo...@ojctech.com Urbana, IL * (217) 344-0444 x24
Index: sys/sys/cdefs.h
===
RCS file: /cvsroot/src/sys/sys/cdefs.h,v
retrieving revision 1.86
diff -u -p -r1.86 cdefs.h
--- sys/sys/cdefs.h 23 Jun 2011 12:16:03 - 1.86
+++ sys/sys/cdefs.h 21 Jul 2011 19:04:12 -
@@ -63,6 +63,14 @@
#include sys/cdefs_aout.h
#endif
+#ifdef __GNUC__
+#define__strict_weak_alias(alias,sym)
\
+ __unused static typeof(alias) *__weak_alias_##alias = sym; \
+ __weak_alias(alias,sym)
+#else
+#define__strict_weak_alias(alias,sym) __weak_alias(alias,sym)
+#endif
+
/*
* Optional marker for size-optimised MD calling convention.
*/
Index: sys/kern/kern_stub.c
===
RCS file: /cvsroot/src/sys/kern/kern_stub.c,v
retrieving revision 1.34
diff -u -p -r1.34 kern_stub.c
--- sys/kern/kern_stub.c6 Jul 2011 18:24:26 - 1.34
+++ sys/kern/kern_stub.c21 Jul 2011 19:04:13 -
@@ -82,7 +82,8 @@ __KERNEL_RCSID(0, $NetBSD: kern_stub.c,
#include sys/userconf.h
bool default_bus_space_is_equal(bus_space_tag_t, bus_space_tag_t);
-bool default_bus_space_handle_is_equal(bus_space_handle_t, bus_space_handle_t);
+bool default_bus_space_handle_is_equal(bus_space_tag_t, bus_space_handle_t,
+bus_space_handle_t);
/*
* Nonexistent system call-- signal process (may want to handle it). Flag
@@ -137,8 +138,9 @@ __weak_alias(bus_space_reservation_map,
__weak_alias(bus_space_reservation_unmap, voidop);
__weak_alias(bus_space_tag_create, eopnotsupp);
__weak_alias(bus_space_tag_destroy, voidop);
-__weak_alias(bus_space_is_equal, default_bus_space_is_equal);
-__weak_alias(bus_space_handle_is_equal, default_bus_space_handle_is_equal);
+__strict_weak_alias(bus_space_is_equal, default_bus_space_is_equal);
+__strict_weak_alias(bus_space_handle_is_equal,
+default_bus_space_handle_is_equal);
__weak_alias(userconf_bootinfo, voidop);
__weak_alias(userconf_init, voidop);
__weak_alias(userconf_prompt, voidop);
@@ -277,7 +279,8 @@ nullop(void *v)
}
bool
-default_bus_space_handle_is_equal(bus_space_handle_t h1, bus_space_handle_t h2)
+default_bus_space_handle_is_equal(bus_space_tag_t t,
+bus_space_handle_t h1, bus_space_handle_t h2)
{
return memcmp(h1, h2, sizeof(h1)) == 0;
Multiple device attachments
/sys/device.h -- seems to indicate that a device driver can attach to multiple parent drivers (e.g. busses, controllers, …) /* * Devices can have multiple configuration attachments if they attach * to different attributes (busses, or whatever), to allow specification * of multiple match and attach functions. There is only one configuration * driver per driver, so that things like unit numbers and the device * structure array will be shared. */ Does anyone know how this is done in practice? Frank
Re: Multiple device attachments
/sys/device.h -- seems to indicate that a device driver can attach to multiple parent drivers (e.g. busses, controllers, ?) Does anyone know how this is done in practice? device wdc: ata, wdc_common attach wdc at isa with wdc_isa attach wdc at isapnp with wdc_iaspnp attach wdc at ofisa with wdc_ofisa attach wdc at pcmcia with wdc_pcmcia com is another example. So is le. I'm sure there are plenty of others. In some cases they don't even need the with stuff, I think. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Multiple device attachments
Hello, On Thu, 21 Jul 2011 14:44:04 -0500 Frank Zerangue frank.zeran...@gmail.com wrote: /sys/device.h -- seems to indicate that a device driver can attach to multiple parent drivers (e.g. busses, controllers, ?) /* * Devices can have multiple configuration attachments if they attach * to different attributes (busses, or whatever), to allow specification * of multiple match and attach functions. There is only one configuration * driver per driver, so that things like unit numbers and the device * structure array will be shared. */ Does anyone know how this is done in practice? You split the driver in bus-dependent and bus-independent portions - the former does stuff like match attach, find and map registers etc., the latter is the actual driver. There are plenty examples in the source tree: - hme, gem exist as pci and sbus variants - le, esp, com have lots of different bus backends ( Try to find a 1990s UNIX workstation that has neither an le nor an esp. Suns used both as sbus devices, others used their own buses or had them embedded in custom IO chips. ) - chipsfb and igsfb supports both pci and ofbus ( actually vlb with OpenFirmware glue, see arch/shark/ofw/chipsfb_ofbus.c, igsfb_ofbus.c ) have fun Michael -- Michael macal...@netbsd.org
Re: Multiple device attachments
Thanks -- On Jul 21, 2011, at 3:18 PM, Michael wrote: Hello, On Thu, 21 Jul 2011 14:44:04 -0500 Frank Zerangue frank.zeran...@gmail.com wrote: /sys/device.h -- seems to indicate that a device driver can attach to multiple parent drivers (e.g. busses, controllers, ?) /* * Devices can have multiple configuration attachments if they attach * to different attributes (busses, or whatever), to allow specification * of multiple match and attach functions. There is only one configuration * driver per driver, so that things like unit numbers and the device * structure array will be shared. */ Does anyone know how this is done in practice? You split the driver in bus-dependent and bus-independent portions - the former does stuff like match attach, find and map registers etc., the latter is the actual driver. There are plenty examples in the source tree: - hme, gem exist as pci and sbus variants - le, esp, com have lots of different bus backends ( Try to find a 1990s UNIX workstation that has neither an le nor an esp. Suns used both as sbus devices, others used their own buses or had them embedded in custom IO chips. ) - chipsfb and igsfb supports both pci and ofbus ( actually vlb with OpenFirmware glue, see arch/shark/ofw/chipsfb_ofbus.c, igsfb_ofbus.c ) have fun Michael -- Michael macal...@netbsd.org
Re: Multiple device attachments
The examples you site seem to indicate that for example the le device may attach to many alternative devices (e.g. pci, tc, …), but only one attachment is made when autoconf is complete. I may have read the code examples incorrectly -- please pardon me if I did; but what I want to know is -- can a device have multiple attachments (more than one parent device) when autoconf is complete. Thanks, Frank On Jul 21, 2011, at 3:18 PM, Michael wrote: Hello, On Thu, 21 Jul 2011 14:44:04 -0500 Frank Zerangue frank.zeran...@gmail.com wrote: /sys/device.h -- seems to indicate that a device driver can attach to multiple parent drivers (e.g. busses, controllers, ?) /* * Devices can have multiple configuration attachments if they attach * to different attributes (busses, or whatever), to allow specification * of multiple match and attach functions. There is only one configuration * driver per driver, so that things like unit numbers and the device * structure array will be shared. */ Does anyone know how this is done in practice? You split the driver in bus-dependent and bus-independent portions - the former does stuff like match attach, find and map registers etc., the latter is the actual driver. There are plenty examples in the source tree: - hme, gem exist as pci and sbus variants - le, esp, com have lots of different bus backends ( Try to find a 1990s UNIX workstation that has neither an le nor an esp. Suns used both as sbus devices, others used their own buses or had them embedded in custom IO chips. ) - chipsfb and igsfb supports both pci and ofbus ( actually vlb with OpenFirmware glue, see arch/shark/ofw/chipsfb_ofbus.c, igsfb_ofbus.c ) have fun Michael -- Michael macal...@netbsd.org
Re: Multiple device attachments
Hello, On Thu, 21 Jul 2011 16:24:11 -0500 Frank Zerangue frank.zeran...@gmail.com wrote: The examples you site seem to indicate that for example the le device may attach to many alternative devices (e.g. pci, tc, ?), but only one attachment is made when autoconf is complete. I may have read the code examples incorrectly -- please pardon me if I did; but what I want to know is -- can a device have multiple attachments (more than one parent device) when autoconf is complete. What do you mean - several instances of the same driver with different bus backends in the same kernel? Sure, there is absolutely nothing to prevent it. have fun Michael
Re: Multiple device attachments
On Thu, 21 Jul 2011, Michael wrote: The examples you site seem to indicate that for example the le device may attach to many alternative devices (e.g. pci, tc, ?), but only one attachment is made when autoconf is complete. I may have read the code examples incorrectly -- please pardon me if I did; but what I want to know is -- can a device have multiple attachments (more than one parent device) when autoconf is complete. What do you mean - several instances of the same driver with different bus backends in the same kernel? Sure, there is absolutely nothing to prevent it. Yes, there can be multiple instances of a driver, with each instance attached to a different attribute. However, each single instance can be attached to only one parent. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: Multiple device attachments
The examples you site seem to indicate that for example the le device may attach to many alternative devices (e.g. pci, tc, ?), but only one attachment is made when autoconf is complete. For any particular instance of le, yes. I may have read the code examples incorrectly -- please pardon me if I did; but what I want to know is -- can a device have multiple attachments (more than one parent device) when autoconf is complete. A device can in the sense that, for example, ne0 and ne1 might not attach to the same parent, or even the same kind of parent (eg, one ISA and one PCMCIA). But a single node, a single instance of a driver (eg, ne0), always has at most one parent (exactly one, I think, except for the autoconf root most ports call mainbus). To put it another way, the autoconf tree is a tree, not a dag. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Dutch keymap not imported into NetBSD :p
Hello. Broke my Thinkpad X30 keyboard while being in Germany. Found in a shop a brand new keyboard, told it was German. Turns out it's not German, it's Dutch. On the X30 I got NetBSD-5.1 and there is no nl keymap. Google pointed me to NetBSD problem report number 35473. Could Spanny patch be included into NetBSD-current ? I have downloaded thru CVS the NetBSD-current sources, and applied Spanny patch. Recompiled kernel, reboot and now the keyboard keymap is working perfectly. It's 4 years old and it seems to be minor and quite useful :-) jru...@netbsd.org proposed in June 2011 to has this commited. Please do : it works. Problem report with patch is at : http://gnats.netbsd.org/35473 -- Gilbert Fernandes
Re: Dutch keymap not imported into NetBSD :p
On the X30 I got NetBSD-5.1 and there is no nl keymap. Google pointed me to NetBSD problem report number 35473. Could Spanny patch be included into NetBSD-current ? Yes, I will commit it shortly. - Jukka.
