From bounces-tech-kern-owner-dyoung=ojctech.com@NetBSD.org Mon May 28 01:51:38 2012 Date: Mon, 28 May 2012 07:46:12 +0100 From: David Laight To: tech-kern@netbsd.org Subject: link-sets in modules Message-ID: <20120528064612.GA27576@snowdrop.l8s.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: tech-kern-owner@NetBSD.org Status: RO Content-Length: 1754 Lines: 45 There are currently problems loading modules that contain link-sets (link-sets were the 'flavour of the month' a while back!) because the link sets don't get processed during module load (and unload) because they are processed by the initialisation of other code. I think the following will fix this and thus allow the same driver object to be run either as a loaded module, or linked into the main kernel. 1) Add another link-set describing each link-set. At a minumum containing the name of the link-set, and functions to process the addition and removal of data areas. 2) When the module-loader is loading a module and finds a link-set (which is how it finds the module info itself), it searches the known link-set processors (from the link-set defined in (1) and any added later) and calls the relevant function to proces the entries. I think the link-set functions need initialising after the module's own initialisation - unless that is a property of the link-set? The module loader will need to remember the link sets info for module unload. That should make it easier to build some bits as modules. I have an aim that the kernel build be changed slightly: 1) build all the 'modules' *.kmod. 2) run 'config' and compile a kernel that excludes all the modules but leave the final link as an 'ld -r' generating a netbsd.o. 3) Link some or all of the *.kmod into netbsd.o 4) A final link generating a fully fixed-up netbsd. 5) Release *.kmod and netbsd.o (as well as netbsd). This would make it easy to remove a lot of 'unusual' drivers from the kernel, while still making is easy to add them into a bootable kernel for systems that need them at boot time. Thoughts/comments ? David -- David Laight: david@l8s.co.uk From bounces-tech-kern-owner-dyoung=ojctech.com@NetBSD.org Mon May 28 08:52:07 2012 Date: Mon, 28 May 2012 06:51:43 -0700 (PDT) From: Paul Goyette Reply-To: paul@whooppee.com To: David Laight cc: tech-kern@netbsd.org Subject: Re: link-sets in modules In-Reply-To: <20120528064612.GA27576@snowdrop.l8s.co.uk> Message-ID: References: <20120528064612.GA27576@snowdrop.l8s.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: tech-kern-owner@NetBSD.org Status: RO Content-Length: 3185 Lines: 84 I'm not sure this solves the problem. From my earlier attempts at modularizing the ieee80211 code, it seems that there are two separate mechanisms for finding the start and end of a link set: 1. Within a monolithically-linked kernel, we have the symbols __{start,stop}_link_set_* but no program section table 2. Within a module, we have the program section table (containing a start address and size), but no symbols Since the primary purpose of link_sets is to gather together some unknown quantity of "info" from arbitrary contributors without imposing any restrictions on quantity, I don't see how your proposal addresses the need of figuring out the size/quantity portion of the equation. I _do_ like part 2 of your proposal - linking the "core" kernel first, and then re-linking with selected modules. On Mon, 28 May 2012, David Laight wrote: > There are currently problems loading modules that contain link-sets > (link-sets were the 'flavour of the month' a while back!) because > the link sets don't get processed during module load (and unload) > because they are processed by the initialisation of other code. > > I think the following will fix this and thus allow the same driver > object to be run either as a loaded module, or linked into the main > kernel. > > 1) Add another link-set describing each link-set. At a minumum containing > the name of the link-set, and functions to process the addition and > removal of data areas. > > 2) When the module-loader is loading a module and finds a link-set > (which is how it finds the module info itself), it searches the > known link-set processors (from the link-set defined in (1) and > any added later) and calls the relevant function to proces the > entries. > > I think the link-set functions need initialising after the module's > own initialisation - unless that is a property of the link-set? > > The module loader will need to remember the link sets info for > module unload. > > That should make it easier to build some bits as modules. > > I have an aim that the kernel build be changed slightly: > 1) build all the 'modules' *.kmod. > 2) run 'config' and compile a kernel that excludes all the modules > but leave the final link as an 'ld -r' generating a netbsd.o. > 3) Link some or all of the *.kmod into netbsd.o > 4) A final link generating a fully fixed-up netbsd. > 5) Release *.kmod and netbsd.o (as well as netbsd). > > This would make it easy to remove a lot of 'unusual' drivers from > the kernel, while still making is easy to add them into a bootable > kernel for systems that need them at boot time. > > Thoughts/comments ? > > David > > -- > David Laight: david@l8s.co.uk > > !DSPAM:4fc320902401490139417! > > > ------------------------------------------------------------------------- | 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 | ------------------------------------------------------------------------- From bounces-tech-kern-owner-dyoung=ojctech.com@NetBSD.org Mon May 28 13:24:46 2012 Date: Mon, 28 May 2012 19:19:22 +0100 From: David Laight To: Paul Goyette Cc: tech-kern@netbsd.org Subject: Re: link-sets in modules Message-ID: <20120528181922.GC27576@snowdrop.l8s.co.uk> References: <20120528064612.GA27576@snowdrop.l8s.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: tech-kern-owner@NetBSD.org Status: RO Content-Length: 1356 Lines: 40 On Mon, May 28, 2012 at 06:51:43AM -0700, Paul Goyette wrote: > I'm not sure this solves the problem. > > From my earlier attempts at modularizing the ieee80211 code, it seems > that there are two separate mechanisms for finding the start and end of > a link set: > > 1. Within a monolithically-linked kernel, we have the symbols > __{start,stop}_link_set_* but no program section table > > 2. Within a module, we have the program section table (containing a > start address and size), but no symbols > > Since the primary purpose of link_sets is to gather together some > unknown quantity of "info" from arbitrary contributors without imposing > any restrictions on quantity, I don't see how your proposal addresses > the need of figuring out the size/quantity portion of the equation. If you look at (say) evcnt_init() is has: __link_set_decl(evcnts, struct evcnt); __link_set_foreach(evp, evcnts) evcnt_attach_static(*evp); If could also call something like: __link_set_process(evcnts, evcnt_attach_static, evcnt_detach); which would save data the module loader can use to process the program section of a lodable module. Plausibly this data could be in a linkset itself! It would be an error to try to load a module which contained a linkset without anything defined to process it. David -- David Laight: david@l8s.co.uk From bounces-tech-kern-owner-dyoung=ojctech.com@NetBSD.org Mon May 28 13:38:26 2012 Date: Mon, 28 May 2012 11:38:09 -0700 (PDT) From: Paul Goyette Reply-To: paul@whooppee.com To: David Laight cc: tech-kern@netbsd.org Subject: Re: link-sets in modules In-Reply-To: <20120528181922.GC27576@snowdrop.l8s.co.uk> Message-ID: References: <20120528064612.GA27576@snowdrop.l8s.co.uk> <20120528181922.GC27576@snowdrop.l8s.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: tech-kern-owner@NetBSD.org Status: RO Content-Length: 2154 Lines: 55 On Mon, 28 May 2012, David Laight wrote: > On Mon, May 28, 2012 at 06:51:43AM -0700, Paul Goyette wrote: >> I'm not sure this solves the problem. >> >> From my earlier attempts at modularizing the ieee80211 code, it seems >> that there are two separate mechanisms for finding the start and end of >> a link set: >> >> 1. Within a monolithically-linked kernel, we have the symbols >> __{start,stop}_link_set_* but no program section table >> >> 2. Within a module, we have the program section table (containing a >> start address and size), but no symbols >> >> Since the primary purpose of link_sets is to gather together some >> unknown quantity of "info" from arbitrary contributors without imposing >> any restrictions on quantity, I don't see how your proposal addresses >> the need of figuring out the size/quantity portion of the equation. > > If you look at (say) evcnt_init() is has: > > __link_set_decl(evcnts, struct evcnt); > > __link_set_foreach(evp, evcnts) > evcnt_attach_static(*evp); > > If could also call something like: > __link_set_process(evcnts, evcnt_attach_static, evcnt_detach); > > which would save data the module loader can use to process the program > section of a lodable module. I'm obviously missing something that is, or should be, intrinsically obvious, but... How would __link_set_process() know how many entries to process? What would indicate the end of the data? > Plausibly this data could be in a linkset itself! Hmm. If this data were available (at link time) in your model, it should already be available within the existing framework. Since I'm lacking a clue or two, I'll defer further comments here until there's a prototype to work with. ------------------------------------------------------------------------- | 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 | ------------------------------------------------------------------------- From bounces-tech-kern-owner-dyoung=ojctech.com@NetBSD.org Mon May 28 14:03:07 2012 Date: Mon, 28 May 2012 19:57:48 +0100 From: David Laight To: Paul Goyette Cc: tech-kern@netbsd.org Subject: Re: link-sets in modules Message-ID: <20120528185748.GE27576@snowdrop.l8s.co.uk> References: <20120528064612.GA27576@snowdrop.l8s.co.uk> <20120528181922.GC27576@snowdrop.l8s.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: tech-kern-owner@NetBSD.org Status: RO Content-Length: 1513 Lines: 34 On Mon, May 28, 2012 at 11:38:09AM -0700, Paul Goyette wrote: > > How would __link_set_process() know how many entries to process? What > would indicate the end of the data? It has the program headers eg (from a random module): Sections: Idx Name Size VMA LMA File off Algn 0 .text 0000160e 00000000 00000000 00000040 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .rodata.str1.1 00000105 00000000 00000000 0000164e 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .rodata.str1.4 000001bc 00000000 00000000 00001754 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .rodata 00000099 00000000 00000000 00001920 2**5 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 4 link_set_modules 00000004 00000000 00000000 000019bc 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 5 link_set_sysctl_funcs 00000004 00000000 00000000 000019c0 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 6 .data 000000a4 00000000 00000000 000019e0 2**5 CONTENTS, ALLOC, LOAD, RELOC, DATA 7 .ident 00000071 00000000 00000000 00001a84 2**0 CONTENTS, READONLY When it processes section 5 it allocates 4 bytes somewhere ... Since the entries are all pointers (actually it ought to be possible to use any fixes size structure) it known where the end is. David -- David Laight: david@l8s.co.uk From bounces-tech-kern-owner-dyoung=ojctech.com@NetBSD.org Mon May 28 14:39:06 2012 Date: Mon, 28 May 2012 12:38:47 -0700 (PDT) From: Paul Goyette Reply-To: paul@whooppee.com To: David Laight cc: tech-kern@netbsd.org Subject: Re: link-sets in modules In-Reply-To: <20120528185748.GE27576@snowdrop.l8s.co.uk> Message-ID: References: <20120528064612.GA27576@snowdrop.l8s.co.uk> <20120528181922.GC27576@snowdrop.l8s.co.uk> <20120528185748.GE27576@snowdrop.l8s.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: tech-kern-owner@NetBSD.org Status: RO Content-Length: 2810 Lines: 64 On Mon, 28 May 2012, David Laight wrote: > On Mon, May 28, 2012 at 11:38:09AM -0700, Paul Goyette wrote: >> >> How would __link_set_process() know how many entries to process? What >> would indicate the end of the data? > > It has the program headers eg (from a random module): > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 0000160e 00000000 00000000 00000040 2**4 > CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE > 1 .rodata.str1.1 00000105 00000000 00000000 0000164e 2**0 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 2 .rodata.str1.4 000001bc 00000000 00000000 00001754 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 3 .rodata 00000099 00000000 00000000 00001920 2**5 > CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA > 4 link_set_modules 00000004 00000000 00000000 000019bc 2**2 > CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA > 5 link_set_sysctl_funcs 00000004 00000000 00000000 000019c0 2**2 > CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA > 6 .data 000000a4 00000000 00000000 000019e0 2**5 > CONTENTS, ALLOC, LOAD, RELOC, DATA > 7 .ident 00000071 00000000 00000000 00001a84 2**0 > CONTENTS, READONLY Unless I've missed something in my explorations, this data is not available for the "monolithic kernel". So a built-in module needs the {start,end} symbols to learn where the program sections are loaded. Modules that are loaded by the run-time linker _do_ have the above info, but do not have the symbols. > When it processes section 5 it allocates 4 bytes somewhere ... > Since the entries are all pointers (actually it ought to be possible > to use any fixes size structure) it known where the end is. Section 5 deals with the SYSCTL_SETUP() stuff. When modules create a sysctl(9) sub-tree, they have to explicitly call sysctl_createv() since the initializer(s) defined by SYSCTL_SETUP doesn't get called. (The code that does call the SYSCTL_SETUP() initializers uses the __link_set_foreach() macro which depends on the {start,end} symbols - see sysctl_init() in src/sys/kern_sysctl.c) So, I'm still hoping to see a prototype the works for both built-in and independantly-linked modules ... :) ------------------------------------------------------------------------- | 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 | ------------------------------------------------------------------------- From bounces-tech-kern-owner-dyoung=ojctech.com@NetBSD.org Tue May 29 11:05:27 2012 Subject: Re: link-sets in modules Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Matt Thomas In-Reply-To: Date: Tue, 29 May 2012 09:05:03 -0700 Cc: David Laight , tech-kern@netbsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <645D9446-103F-471A-B266-09187F38BCE3@3am-software.com> References: <20120528064612.GA27576@snowdrop.l8s.co.uk> <20120528181922.GC27576@snowdrop.l8s.co.uk> <20120528185748.GE27576@snowdrop.l8s.co.uk> To: paul@whooppee.com Sender: tech-kern-owner@NetBSD.org Status: RO Content-Length: 1853 Lines: 43 On May 28, 2012, at 12:38 PM, Paul Goyette wrote: > On Mon, 28 May 2012, David Laight wrote: >=20 >> On Mon, May 28, 2012 at 11:38:09AM -0700, Paul Goyette wrote: >>>=20 >>> How would __link_set_process() know how many entries to process? = What >>> would indicate the end of the data? >>=20 >> It has the program headers eg (from a random module): >>=20 >> Sections: >> Idx Name Size VMA LMA File off Algn >> 0 .text 0000160e 00000000 00000000 00000040 2**4 >> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE >> 1 .rodata.str1.1 00000105 00000000 00000000 0000164e 2**0 >> CONTENTS, ALLOC, LOAD, READONLY, DATA >> 2 .rodata.str1.4 000001bc 00000000 00000000 00001754 2**2 >> CONTENTS, ALLOC, LOAD, READONLY, DATA >> 3 .rodata 00000099 00000000 00000000 00001920 2**5 >> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA >> 4 link_set_modules 00000004 00000000 00000000 000019bc 2**2 >> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA >> 5 link_set_sysctl_funcs 00000004 00000000 00000000 000019c0 2**2 >> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA >> 6 .data 000000a4 00000000 00000000 000019e0 2**5 >> CONTENTS, ALLOC, LOAD, RELOC, DATA >> 7 .ident 00000071 00000000 00000000 00001a84 2**0 >> CONTENTS, READONLY >=20 > Unless I've missed something in my explorations, this data is not = available for the "monolithic kernel". So a built-in module needs the = {start,end} symbols to learn where the program sections are loaded. >=20 > Modules that are loaded by the run-time linker _do_ have the above = info, but do not have the symbols. >=20 It could if the kernel loader did what ld did. create = __{start,stop}_xxxx for each section. From bounces-tech-kern-owner-dyoung=ojctech.com@NetBSD.org Tue May 29 12:00:15 2012 Date: Tue, 29 May 2012 10:00:01 -0700 (PDT) From: Paul Goyette Reply-To: paul@whooppee.com To: Matt Thomas cc: David Laight , tech-kern@netbsd.org Subject: Re: link-sets in modules In-Reply-To: <645D9446-103F-471A-B266-09187F38BCE3@3am-software.com> Message-ID: References: <20120528064612.GA27576@snowdrop.l8s.co.uk> <20120528181922.GC27576@snowdrop.l8s.co.uk> <20120528185748.GE27576@snowdrop.l8s.co.uk> <645D9446-103F-471A-B266-09187F38BCE3@3am-software.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: tech-kern-owner@NetBSD.org Status: RO Content-Length: 891 Lines: 22 On Tue, 29 May 2012, Matt Thomas wrote: >> Modules that are loaded by the run-time linker _do_ have the above >> info, but do not have the symbols. > > It could if the kernel loader did what ld did. create > __{start,stop}_xxxx for each section. Yeah, that would be nice. But the module linker script doesn't do the PROVIDE() I suppose the kernel loader could fabricate an extra elf symbol table for all __link_set_* program sections... ------------------------------------------------------------------------- | 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 | ------------------------------------------------------------------------- From bounces-tech-kern-owner-dyoung=ojctech.com@NetBSD.org Tue May 29 12:26:48 2012 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) Subject: Re: link-sets in modules From: Matt Thomas In-Reply-To: Date: Tue, 29 May 2012 10:26:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6A66F8D6-8B4A-4D52-AFC9-9641CC3B7119@3am-software.com> References: <20120528064612.GA27576@snowdrop.l8s.co.uk> <20120528181922.GC27576@snowdrop.l8s.co.uk> <20120528185748.GE27576@snowdrop.l8s.co.uk> <645D9446-103F-471A-B266-09187F38BCE3@3am-software.com> To: tech-kern mailing list Sender: tech-kern-owner@NetBSD.org Status: RO Content-Length: 578 Lines: 19 On May 29, 2012, at 10:00 AM, Paul Goyette wrote: > On Tue, 29 May 2012, Matt Thomas wrote: >=20 >>> Modules that are loaded by the run-time linker _do_ have the above >>> info, but do not have the symbols. >>=20 >> It could if the kernel loader did what ld did. create >> __{start,stop}_xxxx for each section. >=20 >=20 > Yeah, that would be nice. But the module linker script doesn't do the = PROVIDE() >=20 > I suppose the kernel loader could fabricate an extra elf symbol table = for all __link_set_* program sections... This isn't in the script, it's internal to ld.= From bounces-tech-kern-owner-dyoung=ojctech.com@NetBSD.org Tue May 29 16:47:36 2012 Date: Tue, 29 May 2012 22:41:52 +0100 From: David Laight To: Matt Thomas Cc: tech-kern mailing list Subject: Re: link-sets in modules Message-ID: <20120529214152.GI27576@snowdrop.l8s.co.uk> References: <20120528064612.GA27576@snowdrop.l8s.co.uk> <20120528181922.GC27576@snowdrop.l8s.co.uk> <20120528185748.GE27576@snowdrop.l8s.co.uk> <645D9446-103F-471A-B266-09187F38BCE3@3am-software.com> <6A66F8D6-8B4A-4D52-AFC9-9641CC3B7119@3am-software.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A66F8D6-8B4A-4D52-AFC9-9641CC3B7119@3am-software.com> Sender: tech-kern-owner@NetBSD.org Status: RO Content-Length: 1026 Lines: 31 On Tue, May 29, 2012 at 10:26:36AM -0700, Matt Thomas wrote: > > On May 29, 2012, at 10:00 AM, Paul Goyette wrote: > > > On Tue, 29 May 2012, Matt Thomas wrote: > > > >>> Modules that are loaded by the run-time linker _do_ have the above > >>> info, but do not have the symbols. > >> > >> It could if the kernel loader did what ld did. create > >> __{start,stop}_xxxx for each section. > > > > > > Yeah, that would be nice. But the module linker script doesn't do the PROVIDE() > > > > I suppose the kernel loader could fabricate an extra elf symbol table for all __link_set_* program sections... > > This isn't in the script, it's internal to ld. I'm not at all sure ld uses a linker script for 'ld -r' - so you can't add symbols that way. No reason why the module loader can't generate them though. But really you need the module loader be able to request the contents of the linkset be processed by code in the main kernel (eg to get sysctls or event counters added). David -- David Laight: david@l8s.co.uk From bounces-tech-kern-owner-dyoung=ojctech.com@NetBSD.org Tue May 29 17:01:15 2012 Date: Tue, 29 May 2012 15:00:58 -0700 (PDT) From: Paul Goyette Reply-To: paul@whooppee.com To: David Laight cc: Matt Thomas , tech-kern mailing list Subject: Re: link-sets in modules In-Reply-To: <20120529214152.GI27576@snowdrop.l8s.co.uk> Message-ID: References: <20120528064612.GA27576@snowdrop.l8s.co.uk> <20120528181922.GC27576@snowdrop.l8s.co.uk> <20120528185748.GE27576@snowdrop.l8s.co.uk> <645D9446-103F-471A-B266-09187F38BCE3@3am-software.com> <6A66F8D6-8B4A-4D52-AFC9-9641CC3B7119@3am-software.com> <20120529214152.GI27576@snowdrop.l8s.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: tech-kern-owner@NetBSD.org Status: RO Content-Length: 1293 Lines: 28 On Tue, 29 May 2012, David Laight wrote: > I'm not at all sure ld uses a linker script for 'ld -r' - so you can't > add symbols that way. > No reason why the module loader can't generate them though. > > But really you need the module loader be able to request the contents > of the linkset be processed by code in the main kernel (eg to get > sysctls or event counters added). Well, at least for sysctl's SYSCTL_SETUP() stuff, you probably don't want to use the same initialization call for modules as is used for built-ins. The built-ins are initialized with an explicit NULL argument passed for the sysctl_clog argument, which makes it difficult for a module to do its clean-up. Modular code needs to (or at least, should?) pass a non-null module-specific clog so it can be used during an "undo" at MODULE_CMD_UNLOAD time. JMHO ... ------------------------------------------------------------------------- | 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 | ------------------------------------------------------------------------- From bounces-tech-kern-owner-dyoung=ojctech.com@NetBSD.org Tue May 29 23:03:33 2012 Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=k+/5j0k648vyd5g72WMfEOyFh1nelis8NncuOK+PVFI=; b=IC2A/ky5YCH1iIsHgu7iH6vLGbbbdZI9pDcQmLSc928X9zFiV5xu3cK+vz3j6bqYmy NE2etCdZnS0EJCuXYpf6BDIglob1phV1kuPITiduDj10MT/jXH7yLUGU33+EYEk1i18Y mZeXUOjL1LZsyd5hsZxRyZsTkNjQhWC9ZYbzKtOGlkFl+BXXH05X5PiJgKTX6bT13tsj 7aJ3K6aldncWmz7k4e3AMQwErer3MWH+TDech+lY6w8Jah6oIsrDWvV6tkce5of/l+HS Kbvhv5pgM8ruxUfBZ5SBRGseUGExzdMoln/SOQWD8SANhJmaabIDehkJwmsarYsPcBve 9B3w== Date: Wed, 30 May 2012 07:03:15 +0300 From: Jukka Ruohonen To: tech-kern mailing list Subject: Re: link-sets in modules Message-ID: <20120530040315.GA7844@marx.bitnet> Reply-To: jruohonen@iki.fi References: <20120528181922.GC27576@snowdrop.l8s.co.uk> <20120528185748.GE27576@snowdrop.l8s.co.uk> <645D9446-103F-471A-B266-09187F38BCE3@3am-software.com> <6A66F8D6-8B4A-4D52-AFC9-9641CC3B7119@3am-software.com> <20120529214152.GI27576@snowdrop.l8s.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: tech-kern-owner@NetBSD.org Status: RO Content-Length: 695 Lines: 14 On Tue, May 29, 2012 at 03:00:58PM -0700, Paul Goyette wrote: > Well, at least for sysctl's SYSCTL_SETUP() stuff, you probably don't > want to use the same initialization call for modules as is used for > built-ins. The built-ins are initialized with an explicit NULL argument > passed for the sysctl_clog argument, which makes it difficult for a > module to do its clean-up. Modular code needs to (or at least, should?) > pass a non-null module-specific clog so it can be used during an "undo" > at MODULE_CMD_UNLOAD time. Indeed I consider it a bug if a module uses SYSCTL_SETUP() (and does not tear down the nodes after unload). This applies more generally to drivers too. - Jukka. From bounces-tech-kern-owner-dyoung=ojctech.com@NetBSD.org Thu May 31 13:09:38 2012 Message-Id: <201205311809.q4VI9KuW023234@ginseng.pulsar-zone.net> Date: Thu, 31 May 2012 14:09:20 -0400 From: Matthew Mondor To: tech-kern@netbsd.org Subject: Re: link-sets in modules In-Reply-To: References: <20120528064612.GA27576@snowdrop.l8s.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: tech-kern-owner@NetBSD.org Status: RO Content-Length: 253 Lines: 9 On Mon, 28 May 2012 06:51:43 -0700 (PDT) Paul Goyette wrote: > I _do_ like part 2 of your proposal - linking the "core" kernel first, > and then re-linking with selected modules. I also think that this would be very nice -- Matt