Modularizing net80211 (was: link_set info needed)
Folks,
I would like to commit the attached patches to modularize the net80211
code. The changes include:
1. Protecting the inclusion of opt_inet.h with #ifdef _KERNEL
2. Removing CTLFLAG_PERMANENT from all of the sysctl(8) variables
3. Replacing the use of link_set with direct calls to all of the
crypto/auth initializers.
At a future time, I propose to split the crypto/auth stuff out into
their own modules, but that will require a bit more planning and a lot
more testing. :)
I have tested the attached changes on my home system, using a modular
if_rum(4) driver (which I plan to commit separately).
Comments/feedback welcomed...
-
| 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 |
-Index: ieee80211.c
===
RCS file: /cvsroot/src/sys/net80211/ieee80211.c,v
retrieving revision 1.53
diff -u -p -r1.53 ieee80211.c
--- ieee80211.c 5 Apr 2010 07:22:24 - 1.53
+++ ieee80211.c 27 Apr 2012 12:34:49 -
@@ -43,7 +43,9 @@ __KERNEL_RCSID(0, $NetBSD: ieee80211.c,
* IEEE 802.11 generic handler
*/
+#if defined(_KERNEL_OPT)
#include opt_inet.h
+#endif
#include sys/param.h
#include sys/systm.h
Index: ieee80211_crypto.c
===
RCS file: /cvsroot/src/sys/net80211/ieee80211_crypto.c,v
retrieving revision 1.15
diff -u -p -r1.15 ieee80211_crypto.c
--- ieee80211_crypto.c 23 May 2011 15:37:36 - 1.15
+++ ieee80211_crypto.c 27 Apr 2012 12:34:49 -
@@ -39,7 +39,9 @@ __FBSDID($FreeBSD: src/sys/net80211/iee
__KERNEL_RCSID(0, $NetBSD: ieee80211_crypto.c,v 1.15 2011/05/23 15:37:36
drochner Exp $);
#endif
+#if defined(_KERNEL_OPT)
#include opt_inet.h
+#endif
/*
* IEEE 802.11 generic crypto support.
Index: ieee80211_input.c
===
RCS file: /cvsroot/src/sys/net80211/ieee80211_input.c,v
retrieving revision 1.72
diff -u -p -r1.72 ieee80211_input.c
--- ieee80211_input.c 31 Dec 2011 20:41:58 - 1.72
+++ ieee80211_input.c 27 Apr 2012 12:34:49 -
@@ -39,7 +39,9 @@ __FBSDID($FreeBSD: src/sys/net80211/iee
__KERNEL_RCSID(0, $NetBSD: ieee80211_input.c,v 1.72 2011/12/31 20:41:58
christos Exp $);
#endif
+#if defined(_KERNEL_OPT)
#include opt_inet.h
+#endif
#ifdef __NetBSD__
#endif /* __NetBSD__ */
Index: ieee80211_ioctl.c
===
RCS file: /cvsroot/src/sys/net80211/ieee80211_ioctl.c,v
retrieving revision 1.57
diff -u -p -r1.57 ieee80211_ioctl.c
--- ieee80211_ioctl.c 31 Dec 2011 20:41:58 - 1.57
+++ ieee80211_ioctl.c 27 Apr 2012 12:34:50 -
@@ -43,8 +43,10 @@ __KERNEL_RCSID(0, $NetBSD: ieee80211_io
* IEEE 802.11 ioctl support (FreeBSD-specific)
*/
+#if defined(_KERNEL_OPT)
#include opt_inet.h
#include opt_compat_netbsd.h
+#endif
#include sys/endian.h
#include sys/param.h
Index: ieee80211_netbsd.c
===
RCS file: /cvsroot/src/sys/net80211/ieee80211_netbsd.c,v
retrieving revision 1.20
diff -u -p -r1.20 ieee80211_netbsd.c
--- ieee80211_netbsd.c 19 Nov 2011 22:51:25 - 1.20
+++ ieee80211_netbsd.c 27 Apr 2012 12:34:50 -
@@ -40,6 +40,7 @@ __KERNEL_RCSID(0, $NetBSD: ieee80211_ne
#include sys/kernel.h
#include sys/systm.h
#include sys/mbuf.h
+#include sys/module.h
#include sys/proc.h
#include sys/sysctl.h
#include sys/once.h
@@ -72,6 +73,8 @@ static int ieee80211_sysctl_node(SYSCTLF
intieee80211_debug = 0;
#endif
+#ifdef NOTYET /* Currently we can't use link sets in modules */
+
typedef void (*ieee80211_setup_func)(void);
__link_set_decl(ieee80211_funcs, ieee80211_setup_func);
@@ -81,7 +84,7 @@ ieee80211_init0(void)
{
ieee80211_setup_func * const *ieee80211_setup, f;
-__link_set_foreach(ieee80211_setup, ieee80211_funcs) {
+ __link_set_foreach(ieee80211_setup, ieee80211_funcs) {
f = (void*)*ieee80211_setup;
(*f)();
}
@@ -96,6 +99,29 @@ ieee80211_init(void)
RUN_ONCE(ieee80211_init_once, ieee80211_init0);
}
+#else
+/*
+ * One-time initialization
+ *
+ * XXX Make sure you update the list of CYPTO initializers if new
+ * XXX mechanisms are added!
+ */
+
+void ccmp_register(void);
+void tkip_register(void);
+void wep_register(void);
+void ieee80211_external_auth_setup(void);
+
+void
+ieee80211_init(void)
+{
+
+ ccmp_register();
+ tkip_register();
+ wep_register();
+ ieee80211_external_auth_setup();
+}
+#endif /* NOT_YET */
static
Re: Modularizing net80211 (was: link_set info needed)
On Fri, Apr 27, 2012 at 05:51:30AM -0700, Paul Goyette wrote: 3. Replacing the use of link_set with direct calls to all of the crypto/auth initializers. I believe this to a noticable regression due to bugs in the module framework. It should support either link sets or _init sections. If the latter is supposed to be the way forward, current linkset usage should be adjusted and an appropiate place in the kernel for calling all static initializers be found. Joerg
Re: Modularizing net80211 (was: link_set info needed)
On Fri, 27 Apr 2012, Joerg Sonnenberger wrote: On Fri, Apr 27, 2012 at 05:51:30AM -0700, Paul Goyette wrote: 3. Replacing the use of link_set with direct calls to all of the crypto/auth initializers. I believe this to a noticable regression due to bugs in the module framework. It should support either link sets or _init sections. If the latter is supposed to be the way forward, current linkset usage should be adjusted and an appropiate place in the kernel for calling all static initializers be found. Thanks for the feedback. I am not familiar with the _init sections stuff - can you provide a reference or example? Please also note that separating the crypto/auth stuff into their own modules later on will remove these direct calls to the initializers. - | 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: Modularizing net80211 (was: link_set info needed)
On Fri, Apr 27, 2012 at 06:34:40AM -0700, Paul Goyette wrote: On Fri, 27 Apr 2012, Joerg Sonnenberger wrote: On Fri, Apr 27, 2012 at 05:51:30AM -0700, Paul Goyette wrote: 3. Replacing the use of link_set with direct calls to all of the crypto/auth initializers. I believe this to a noticable regression due to bugs in the module framework. It should support either link sets or _init sections. If the latter is supposed to be the way forward, current linkset usage should be adjusted and an appropiate place in the kernel for calling all static initializers be found. Thanks for the feedback. I am not familiar with the _init sections stuff - can you provide a reference or example? That's effectively how __attribute__((constructor)) or the corrsponding C++ functionality is implemented. The necessary clue in userland is crt*.o, would wouldn't be that hard to adopt for kernel usage. Joerg
Re: add disk size to struct disk?
On Fri, 27 Apr 2012 01:02:46 +0200 Jean-Yves Migeon jeanyves.mig...@free.fr wrote: Why push it to struct disk rather than letting backends handle it? As the code looks now, the functions which scan disklabels (sys/dev/dkwedge/dkwedge_*.c) get a struct disk *. To get the actual size, it would need to open the device and call an ioctl. As I see it, the only ioctls available for now are disklabel related, thus limited to 32-bit sector numbers. So it would need a new ioctl. Or the disk size would have to be passed down the API (driver-dkwedge_discover()-dkwedge_discovery_method). There is also dkwedge_add() which can be called from userland dkctl(8). For useful checks, it should also get the total disk size. Atm, it fails to do even simple overflow and overlap checks, as you can see here: # dkctl sd0 listwedges /dev/rsd0d: 3 wedges: dk5: zzz, 2000 blocks at 500, type: ffs dk3: xxx, 1000 blocks at 1000, type: ffs dk4: yyy, 11529215046068469760 blocks at 8070450532247928832, type: ffs This code certainly needs some design work. Having total disk size in struct disk means you have to keep it in sync some way or another (ie. callback maybe). Resizing disks can be a common operation This would have to deal with open partitions or attached wedges on disks being shrunk. So perhaps a callback into the other direction, from the driver into the dk subsystem, if a disk is being resized? best regards Matthias Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt Kennen Sie schon unsere app? http://www.fz-juelich.de/app
4K sector size (again) cgd
Hello, I bought a new disk which included a warning label along the line of Warning: Uses 4K sector size!. I plugged it in, and NetBSD identifies it as: umass0 at uhub6 port 1 configuration 1 interface 0 umass0: JMicron USB to ATA/ATAPI bridge, rev 2.00/1.00, addr 2 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, 1 lun per target sd0 at scsibus0 target 0 lun 0: WDC WD75, 00AARX-00N0YB0, disk fixed sd0: 698 GB, 16383 cyl, 16 head, 63 sec, 4096 bytes/sect x 183143646 sectors disklabel identifies it as: -- # /dev/rsd0d: type: SCSI disk: 00AARX-00N0YB0 label: fictitious flags: bytes/sector: 4096 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 16383 total sectors: 183143646 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 [---] -- So far so good; I can add a slice, and run newfs on the slice. However, I want to run cgd on it, and that's where the problems start. I can configure a cgd device on the sd0a, but disklabel cgd3 returns: -- # /dev/rcgd3d: type: cgd disk: cgd label: default label flags: bytes/sector: 512 sectors/track: 2048 tracks/cylinder: 1 sectors/cylinder: 2048 cylinders: 89425 total sectors: 183143646 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 4 partitions: #sizeoffset fstype [fsize bsize cpg/sgs] a: 183143646 0 4.2BSD 0 0 0 # (Cyl. 0 - 89425*) d: 183143646 0 4.2BSD 0 0 0 # (Cyl. 0 - 89425*) disklabel: boot block size 0 disklabel: super block size 0 disklabel: partitions a and d overlap -- Whatever I try to do at this point, writing of the disklabel fails (which I sort of expect, considering the discrepancies in the disklabel outputs). cgd.c has: -- /* * XXX here we should probe the underlying device. If we * are accessing a partition of type RAW_PART, then * we should populate our initial geometry with the * geometry that we discover from the device. */ pdg = cs-sc_dksc.sc_geom; pdg-pdg_secsize = DEV_BSIZE; pdg-pdg_ntracks = 1; pdg-pdg_nsectors = 1024 * (1024 / pdg-pdg_secsize); pdg-pdg_ncylinders = cs-sc_dksc.sc_size / pdg-pdg_nsectors; -- .. which looks suspiciously ... suspicious. I'm assuming that fixing that will increase the chances of the cgd device working properly on this disk. Just so I don't waste a bunch of time poking in the wrong places; am I looking at - what is likely - the problem? With regards to probing the underlying device: Any helpful pointers to prior art is appreciated. -- Kind regards, Jan Danielsson
Re: 4K sector size (again) cgd
In my experience, USB - ATA adapters can play bizarre games with blocksizes.
