Re: load time module parameters?
Maxime Henrion wrote: > > The kernel environment is most useful for diagnostic porposes, and > > for use in the way descrived in this thread -- to provide a means > > of passing parameters that should not be parameters to modules that > > should not need parameters in the first place. Many times, hacking > > the values post-boot will have little or no effect. It's too bad > > the things that will have no effect were exported as writeable, > > instead of resulting in an error. > > I agree this is not perfect, but I don't think we should return an error > though. It would be bad to start duplicating the sysctl functionality > into the kernel environment. What could be nice would be to unsetenv() > the environment variables after them being read and used, so that people > typing kenv won't see these variables in the output and so won't be > tempted to set them. They are too useful for reporting purposes. Without their values, you can't tell the boot environment, and therefore the code that's actually running in the kernel, without a lot more effort, and that would mean duplicated code. There's also the problem of a value that used more than once; the counter argument is to clear them after everything's up -- but that doesn't address things which may or may not be modules. I guess I'm saying that the read-onlyness is cautionary: you can not expect some things to change and be valid. The "maxfiles" example is actually a sysctl, unless you override specifically in the boot loader, in which case it's both a sysctl and in the environment. Even so, after a sysctl change, the environment value (if present) would not be changed. The name space is effective "snapshotted" into the sysctl space when the TUNABLE's are processed from the environment, and interned to kernel data values, instead. With that in mind, it's probably a much better idea to use sysctl's instead of parameters, but the kenv has the advantage of being able to specify initialization parameters. Really, it's a very bad idea to write kernel code that needs command line arguments in the first place, at all. I guess it's something that has to be lived with, as people port Linux code to FreeBSD... but not something to be encouraged. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: load time module parameters?
Terry Lambert wrote: > Maxime Henrion wrote: > > With kenv(1) you can modify kernel environment variables, which hold the > > tunables. Previously, you could only set those at boot time. > > Note that there are some values which are used to determine the > size of KVA space allocations, and changing them after boot, > even if it's permitted, will have no real effect. > > For example, you can change the value of "maxfiles" with a sysctl, > but doing so will not increase the number of simultaneous network > connections your system will support, since the reserved space for > tcpcb's and sockets is not increased. Yes. > The kernel environment is most useful for diagnostic porposes, and > for use in the way descrived in this thread -- to provide a means > of passing parameters that should not be parameters to modules that > should not need parameters in the first place. Many times, hacking > the values post-boot will have little or no effect. It's too bad > the things that will have no effect were exported as writeable, > instead of resulting in an error. I agree this is not perfect, but I don't think we should return an error though. It would be bad to start duplicating the sysctl functionality into the kernel environment. What could be nice would be to unsetenv() the environment variables after them being read and used, so that people typing kenv won't see these variables in the output and so won't be tempted to set them. Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: load time module parameters?
Maxime Henrion wrote: > With kenv(1) you can modify kernel environment variables, which hold the > tunables. Previously, you could only set those at boot time. Note that there are some values which are used to determine the size of KVA space allocations, and changing them after boot, even if it's permitted, will have no real effect. For example, you can change the value of "maxfiles" with a sysctl, but doing so will not increase the number of simultaneous network connections your system will support, since the reserved space for tcpcb's and sockets is not increased. The kernel environment is most useful for diagnostic porposes, and for use in the way descrived in this thread -- to provide a means of passing parameters that should not be parameters to modules that should not need parameters in the first place. Many times, hacking the values post-boot will have little or no effect. It's too bad the things that will have no effect were exported as writeable, instead of resulting in an error. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: load time module parameters?
M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Chuck Tuffli <[EMAIL PROTECTED]> writes: > : I'm a newbie to FreeBSD and am wondering if there is a way to pass > : loadable kernel modules parameters. Under Linux, if a module had > : configurable parameters "a" and "b", you can do something like > : > :insmod module.o parameters="a:10 b:5" > : > : I noticed that some of the drivers grabed information from the > : "environment" using getenv_int(), but I couldn't seem to get this to > : work. Thanks for any thoughts. > > You can generally do this with hints and/or kernel environment > variables. However, you can't easily edit these things once you > boot. With kenv(1) you can modify kernel environment variables, which hold the tunables. Previously, you could only set those at boot time. Now you can have load time module parameters, and you can do things like unload a module, change the parameter, reload it and it will take effect immediately. This is really useful for things which need to be gathered by the module at load time, because the module can't use a sysctl for this if it's at load time. I have patches which make the IPFIREWALL_DEFAULT_TO_ACCEPT setting dynamic with kernel environment variables. So people can install FreeBSD, use the already compiled ipfw module and still change this setting. Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: load time module parameters?
In message: <[EMAIL PROTECTED]> Dan Nelson <[EMAIL PROTECTED]> writes: : In the last episode (Nov 05), Chuck Tuffli said: : > I'm a newbie to FreeBSD and am wondering if there is a way to pass : > loadable kernel modules parameters. Under Linux, if a module had : > configurable parameters "a" and "b", you can do something like : > : >insmod module.o parameters="a:10 b:5" : > : > I noticed that some of the drivers grabed information from the : > "environment" using getenv_int(), but I couldn't seem to get this to : > work. Thanks for any thoughts. : : You can use /usr/bin/kenv to set kernel env variables, or you can have : your module register a dynamic sysctl variable that the user can tweak : after the module has been loaded. I've used the sysctl method myself : and it works fine. Hmmm, if you can use kenv to set variables, then you can use the TUNABLE_FOO interface. I didn't know that setting had been added... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: load time module parameters?
In message: <[EMAIL PROTECTED]> Chuck Tuffli <[EMAIL PROTECTED]> writes: : I'm a newbie to FreeBSD and am wondering if there is a way to pass : loadable kernel modules parameters. Under Linux, if a module had : configurable parameters "a" and "b", you can do something like : :insmod module.o parameters="a:10 b:5" : : I noticed that some of the drivers grabed information from the : "environment" using getenv_int(), but I couldn't seem to get this to : work. Thanks for any thoughts. You can generally do this with hints and/or kernel environment variables. However, you can't easily edit these things once you boot. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: load time module parameters?
In the last episode (Nov 05), Chuck Tuffli said: > I'm a newbie to FreeBSD and am wondering if there is a way to pass > loadable kernel modules parameters. Under Linux, if a module had > configurable parameters "a" and "b", you can do something like > >insmod module.o parameters="a:10 b:5" > > I noticed that some of the drivers grabed information from the > "environment" using getenv_int(), but I couldn't seem to get this to > work. Thanks for any thoughts. You can use /usr/bin/kenv to set kernel env variables, or you can have your module register a dynamic sysctl variable that the user can tweak after the module has been loaded. I've used the sysctl method myself and it works fine. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
load time module parameters?
I'm a newbie to FreeBSD and am wondering if there is a way to pass loadable kernel modules parameters. Under Linux, if a module had configurable parameters "a" and "b", you can do something like insmod module.o parameters="a:10 b:5" I noticed that some of the drivers grabed information from the "environment" using getenv_int(), but I couldn't seem to get this to work. Thanks for any thoughts. -- Chuck Tuffli To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters? (WildWire DSL card driver)
> > You would send the data down to the parameter module before you > > load the driver module; thus: > > > > 1) Load paramter module > > 2) Open parameter module psuedo device > > 3) Ioctl parameters up/down via the pseudo device > > 4) Load the deriver module > > 5) Driver module attach routine call parameter_fetch() > > routine out of parameter module > > 6) Parameter module returns static parameter structure, > > by reference > > 7) Driver dereferences parameters out of static struct > > 8) Driver completes attach > > I'm implementing this suggested method, but I have one problem. I don't > know what "device" to access to allow me to do ioctl's to it. > That is, I've created a parameter module (which loads and is accessible > by my driver) - but I don't think that (alone) has created a "device", > has it? If so, what is it named? Realize that at step 3, my real > device doesn't exist yet, so I can't reference that... > Do I need to somehow "create" a (pseudo-)device in my parameter module > - and if so how do I do that? Yes, you need to have a pseudo device. There are examples in the modules stuff, in particular, the "bpf" code. But it basically just means a device with an attach routine that does nothing, and with an open routine that returns an fd handle that points to the global data structure that you put your parameters in, a close routine, and an ioctl() routine. Everything else can be ENOTIMP (well, you might want a detach routine, and any other load/unload houskeeping, but you get the idea). Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters? (WildWire DSL card driver)
Terry Lambert wrote: > > > Back in July I was asking about the capability to set parameters (variables) > > when loading my DSL driver module. There was a small flurry of activity > > about some initial ideas on how to do it, but I never heard any more about > > it. Did you (Mike, Warner, or anybody) have time to work on it? Did this > > capability get put into release 4.1, by any chance? :) > > A common trick "in the old days" was to load a parameter module > that the driver module depended up, and give it a hook that it > could call to get data from the parameter module, by reference > to a statis structure. > > You would send the data down to the parameter module before you > load the driver module; thus: > > 1) Load paramter module > 2) Open parameter module psuedo device > 3) Ioctl parameters up/down via the pseudo device > 4) Load the deriver module > 5) Driver module attach routine call parameter_fetch() > routine out of parameter module > 6) Parameter module returns static parameter structure, > by reference > 7) Driver dereferences parameters out of static struct > 8) Driver completes attach I'm implementing this suggested method, but I have one problem. I don't know what "device" to access to allow me to do ioctl's to it. That is, I've created a parameter module (which loads and is accessible by my driver) - but I don't think that (alone) has created a "device", has it? If so, what is it named? Realize that at step 3, my real device doesn't exist yet, so I can't reference that... Do I need to somehow "create" a (pseudo-)device in my parameter module - and if so how do I do that? Thanks, Gary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters? (WildWire DSL card driver)
> > I guess I'm asking "What moron would want to intentionally disable > > system resource tracking?". > > Who said anything about disabling system resource tracking? "track all > closes" means to call the devsw d_close function for *each* close, not just > for the "last close" as 99% of our drivers expect... If we suddenly caused > d_close() to be called on every close() syscall, then existing drivers break > because they are used to freeing everything and cleaning up when the close > function is called. Who remembers the open that resulted in the close, if not the driver? Perhaps I'm merely complaining that there are not seperate "close" and "last_close" entry points, since exposing a "last_close" entry point, and then a generic "close" handler that calls "last_close" when the reference count goes from 1->0, which is ignored if the driver has a non-generic handler. Not much of a namespace exposure kludge. I guess I'm anout as annoyed as I was when supposed "bit rot" killed the ISODE and X.25 functioning, when certain kernel interfaces were redefined, without the person doing the redefintion taking care to maintain all caller instances, or when a similar thing ate LFS. 8-(. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters? (WildWire DSL card driver)
Terry Lambert wrote: > > > > > > #define D_TRACKCLOSE0x8 /* track all closes */ > > > > > Under what circumstances is it permissable to _not_ set this bit? > > > > When you want the old behavior. > > > Under what circumstances is it permissable to want the old behaviour? > > > > Jeez Terry, I don't know, it's how it used to be so I assume it's for > > compatibility or for drivers that simply don't care. Am I missing > > something here? > > I guess I'm asking "What moron would want to intentionally disable > system resource tracking?". Who said anything about disabling system resource tracking? "track all closes" means to call the devsw d_close function for *each* close, not just for the "last close" as 99% of our drivers expect... If we suddenly caused d_close() to be called on every close() syscall, then existing drivers break because they are used to freeing everything and cleaning up when the close function is called. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters? (WildWire DSL card driver)
On 17-Oct-00 Terry Lambert wrote: > I guess I'm asking "What moron would want to intentionally disable > system resource tracking?". > > It's OK for the driver to not care, I guess, if it doesn't want to > allow you to unload it, and other evil things. > > > I can maybe buy the legacy argument, but, frankly, and I said > this when Poul and David first asked that the capability to > track closes first went in, unless everyone plays by the same > rules, no one benefits. If you don't need 'per-open' instance data then getting notified of the final close would be sufficient. Also, if you only allow one open you don't need to track each close. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters? (WildWire DSL card driver)
> > > > > #define D_TRACKCLOSE0x8 /* track all closes */ > > > > Under what circumstances is it permissable to _not_ set this bit? > > > When you want the old behavior. > > Under what circumstances is it permissable to want the old behaviour? > > Jeez Terry, I don't know, it's how it used to be so I assume it's for > compatibility or for drivers that simply don't care. Am I missing > something here? I guess I'm asking "What moron would want to intentionally disable system resource tracking?". It's OK for the driver to not care, I guess, if it doesn't want to allow you to unload it, and other evil things. I can maybe buy the legacy argument, but, frankly, and I said this when Poul and David first asked that the capability to track closes first went in, unless everyone plays by the same rules, no one benefits. I guess it'd be nice if it weren't possible to have new drivers not support device close tracking, even if they did nothing about it, other than disallowing unloads when the open count was positive. In the specific context of this thread, if there was a control daemon, then the first open could always be the control daemon, and "attach" parameters could be passed by doing an open, noting it was the first open, and delaying the attach until the open count went from 1->2. For symmetry, this means that if I want to change the parameters after a reconfiguration, I need to know when the open count has gone from 2->1 (leaving only the control daemon). In order to differentiate the control daemon failing, from a normal non-control close, I would need to track and maintain a list of who the opener is, and remove from that list on close. As a general approach, this removes the need for a seperate control and usage device distinction, for those devices which have it now. It also means that I can distinguish a control open from another open, and that I can wedge an open in through an ioctl() to let me do things like have opens onto the ISO9660 and DVDROM views onto a DVD, without having to have seperate character and block devices, so tat, given a legal codec, I can play DVDs on FreeBSD, just like you can on MacOS X (which uses the caharcter device for one type of access, and the block device for the other: efectively another control device hack). Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters? (WildWire DSL card driver)
* Terry Lambert <[EMAIL PROTECTED]> [001016 18:57] wrote: > > > > > Alternately, if the problem is lack of reference counting on > > > > > FreeBSD's part, and you therefore can't do the job on the > > > > > open, since you can't track closes aws they happen, only the > > > > > last clse, there are a couple of approaches: > > > > > > > > FreeBSD has had that capability for over a year now. > > > > > > > > /* > > > > * Flags for d_flags. > > > > */ > > > > #define D_TRACKCLOSE0x8 /* track all closes */ > > > > > > Under what circumstances is it permissable to _not_ set this bit? > > > > When you want the old behavior. > > Under what circumstances is it permissable to want the old behaviour? Jeez Terry, I don't know, it's how it used to be so I assume it's for compatibility or for drivers that simply don't care. Am I missing something here? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters? (WildWire DSL card driver)
> > > > Alternately, if the problem is lack of reference counting on > > > > FreeBSD's part, and you therefore can't do the job on the > > > > open, since you can't track closes aws they happen, only the > > > > last clse, there are a couple of approaches: > > > > > > FreeBSD has had that capability for over a year now. > > > > > > /* > > > * Flags for d_flags. > > > */ > > > #define D_TRACKCLOSE0x8 /* track all closes */ > > > > Under what circumstances is it permissable to _not_ set this bit? > > When you want the old behavior. Under what circumstances is it permissable to want the old behaviour? Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters? (WildWire DSL card driver)
* Terry Lambert <[EMAIL PROTECTED]> [001016 18:19] wrote: > > > Alternately, if the problem is lack of reference counting on > > > FreeBSD's part, and you therefore can't do the job on the > > > open, since you can't track closes aws they happen, only the > > > last clse, there are a couple of approaches: > > > > FreeBSD has had that capability for over a year now. > > > > /* > > * Flags for d_flags. > > */ > > #define D_TRACKCLOSE0x8 /* track all closes */ > > Under what circumstances is it permissable to _not_ set this bit? When you want the old behavior. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters? (WildWire DSL card driver)
> > Alternately, if the problem is lack of reference counting on > > FreeBSD's part, and you therefore can't do the job on the > > open, since you can't track closes aws they happen, only the > > last clse, there are a couple of approaches: > > FreeBSD has had that capability for over a year now. > > /* > * Flags for d_flags. > */ > #define D_TRACKCLOSE0x8 /* track all closes */ Under what circumstances is it permissable to _not_ set this bit? Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters? (WildWire DSL card driver)
Terry, First, thanks for the reply. > > Back in July I was asking about the capability to set parameters (variables) > > when loading my DSL driver module. There was a small flurry of activity > > about some initial ideas on how to do it, but I never heard any more about > > it. Did you (Mike, Warner, or anybody) have time to work on it? Did this > > capability get put into release 4.1, by any chance? :) > > A common trick "in the old days" was to load a parameter module > that the driver module depended up, and give it a hook that it > could call to get data from the parameter module, by reference > to a statis structure. Hmmm... Quite a hack :), but yes it should work. If all else fails, I guess I could do this... > Really, it seems to me that if this driver looks like an > ethernet interface, you should be able to set the parameters > after the atttach, before bringing the interface up. ... > One of these aprroaches should be able to work for you; the parameter > driver approach with a pseudo device will definitely work, but is > much less elegant (parameters on an attach probably mean that you > are doing something in an attach that really belongs elsewhere). One of the problems with supporting DSL is that there are many "flavors" of protocol that different equipment providers use. But there are two main divisions, which unfortunately make for a Jekyl-and-Hyde personality. The DSL card must either appear as a LAN device (ethernet interface) or a WAN device (sync PPP device). Thus, at the moment of attach(), I need to know whether to do an ether_ifattach() or an sppp_attach(). That's the main reason I need module parameters. The other reason I _want_ module parameters is that Linux provides them, so the Linux flavor of my driver uses them, and it's easier to keep the drivers in sync with changes if they are written in a similar manner (since only the Linux driver is "officially" supported)... Gary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters? (WildWire DSL card driver)
* Terry Lambert <[EMAIL PROTECTED]> [001016 17:55] wrote: > > Alternately, if the problem is lack of reference counting on > FreeBSD's part, and you therefore can't do the job on the > open, since you can't track closes aws they happen, only the > last clse, there are a couple of approaches: FreeBSD has had that capability for over a year now. /* * Flags for d_flags. */ #define D_MEMDISK 0x1 /* memory type disk */ #define D_NAGGED0x2 /* nagged about missing make_dev() */ #define D_CANFREE 0x4 /* can free blocks */ #define D_TRACKCLOSE0x8 /* track all closes */ (from sys/conf.h) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters? (WildWire DSL card driver)
> Back in July I was asking about the capability to set parameters (variables) > when loading my DSL driver module. There was a small flurry of activity > about some initial ideas on how to do it, but I never heard any more about > it. Did you (Mike, Warner, or anybody) have time to work on it? Did this > capability get put into release 4.1, by any chance? :) A common trick "in the old days" was to load a parameter module that the driver module depended up, and give it a hook that it could call to get data from the parameter module, by reference to a statis structure. You would send the data down to the parameter module before you load the driver module; thus: 1) Load paramter module 2) Open parameter module psuedo device 3) Ioctl parameters up/down via the pseudo device 4) Load the deriver module 5) Driver module attach routine call parameter_fetch() routine out of parameter module 6) Parameter module returns static parameter structure, by reference 7) Driver dereferences parameters out of static struct 8) Driver completes attach Really, it seems to me that if this driver looks like an ethernet interface, you should be able to set the parameters after the atttach, before bringing the interface up. Alternately, if the problem is lack of reference counting on FreeBSD's part, and you therefore can't do the job on the open, since you can't track closes aws they happen, only the last clse, there are a couple of approaches: A) Have one driver, but two devices; one for control, and one for data B) Have only one device, but inactivate it until a special ioctl() starting it up is issued; thus: 1) Open 2) Set parameters 3) ioctl(fd,LUCENT_START,...) 4) ... 5) ioctl(fd,LUCENT_STOP,...) 6) Set new parameters 7) ioctl(fd,LUCENT_START,...) 8) ... One of these aprroaches should be able to work for you; the parameter driver approach with a pseudo device will definitely work, but is much less elegant (parameters on an attach probably mean that you are doing something in an attach that really belongs elsewhere). Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Module parameters? (WildWire DSL card driver)
Back in July I was asking about the capability to set parameters (variables) when loading my DSL driver module. There was a small flurry of activity about some initial ideas on how to do it, but I never heard any more about it. Did you (Mike, Warner, or anybody) have time to work on it? Did this capability get put into release 4.1, by any chance? :) I'm going to be transitioning from the DSL department here, and so I'd like to get the FreeBSD flavor of our DSL driver fully working before I leave DSL land. Right now the driver basically works, but I have to recompile it when I want to change options (recall that at the time my attach routine is called I need to know some parameters, I can't wait for a later ioctl). If I get the ability to set module parameters, so that the driver will be useful to people in general, is there anyone out there with DSL service and a Lucent WildWire card who would like to try out the driver? The Lucent WildWire DSL + V.90 modem cards have been shipped in PCs from Compaq, Dell, Hewlett-Packard, and Samsung (or soon to be from them). I believe they're still not yet available by themselves in retail stores - they still only come from OEMs. The driver is written for FreeBSD 4.x. At this point we're still not releasing any source code (and may never :( ), so that's why you can't just recompile your own driver with the options you need... So what's the status of module parameters? (no longer subscribed to either of these lists, please keep me in the address list on all replies) Thanks, Gary -- = Gary Corcoran - Distinguished Member of Technical Staff Lucent Microelectronics - Client Access Broadband Systems Communications Protocol & Driver Development Group "We make the drivers that make communications work" Email: [EMAIL PROTECTED] - "No brain, no service." = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
Mike Smith writes:
> Archie - I'd really appreciate a pointer to an example of using the
> ng_parse code to pick up this sort of data, if you can recommend
> something to help me get my head around it quickly (I've looked but slid
> off sideways so far...).
Just to clarify.. a couple of things about the ng_parse stuff.
(I'm not claiming this is the right thing to use for modules,
just trying to clarify & give more information about it).
Basically, it contains routines for converting between ASCII and
binary data; there are two main components..
(a) An infrastructure for doing completely arbitrary conversion,
provided that you are willing to write your own encode and
decode routines (i.e., the functions of type ng_parse_t
and ng_unparse_t, which are pointed to by the struct
ng_parse_type).
(b) Several pre-defined parse types, for example:
Integer types (8, 16, 32, and 64 bit)
String types (fixed and variable length)
C arrays (fixed and variable length)
C structures (including 'variable length structures')
Typically you either use a predefined simple type, or define a new
type by 'subclassing' the pre-defined structure or array types and
supplying some type-specific info that describes the structure or array.
As an example, see the 'struct ng_tee_hookstat' in ng_tee.h:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_tee.h?rev=1.3
/* Statistics structure for one hook */
struct ng_tee_hookstat {
u_int64_t inOctets;
u_int64_t inFrames;
u_int64_t outOctets;
u_int64_t outFrames;
};
Below it is the NG_TEE_HOOKSTAT_INFO definition which defines the
specifics of the structure for the parse type: four 64 bit fields:
/* Keep this in sync with the above structure definition */
#define NG_TEE_HOOKSTAT_INFO{ \
{ \
{ "inOctets", &ng_parse_int64_type}, \
{ "inFrames", &ng_parse_int64_type}, \
{ "outOctets",&ng_parse_int64_type}, \
{ "outFrames",&ng_parse_int64_type}, \
{ NULL }, \
} \
}
Now look in ng_tee.c where the parse type corresponding to a
'struct ng_tee_hookstat' is defined:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_tee.c?rev=1.8
/* Parse type for struct ng_tee_hookstat */
static const struct ng_parse_struct_info
ng_tee_hookstat_type_info = NG_TEE_HOOKSTAT_INFO;
static const struct ng_parse_type ng_tee_hookstat_type = {
&ng_parse_struct_type,
&ng_tee_hookstat_type_info,
};
The parse type we're defining is 'ng_tee_hookstat_type' which is
a 'subclass' of ng_parse_struct_type (a predefined type from
ng_parse.c), with the type-specific info 'ng_tee_hookstat_type_info'.
In ASCII form one of these 'struct ng_tee_hookstat' structures might
look like this:
{ inOctets=123 inFrames=27 outOctets=1033 outFrames=328 }
(The syntax for the predefined array and structure types is described
in ng_parse.h).
At some point I'd like to edit the files so that they can be compiled
either in user or kernel mode.
FYI, ng_parse is completely independent from the rest of netgraph
(i.e., the rest of netgraph is not required).
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
In message <[EMAIL PROTECTED]> Mike Smith writes: : > Something like the following? I know that there's more routines that : > need to be written. parse_int, parse_string, parse_bool, parse_enum : > should be enough. : > : > Comments? : : Reuse the parsers in ng_parse.c, or (IMO better) use sscanf format : strings (which are *extremely* flexible). sscanf doesn't do enum strings. sscanf is inadequate in many other ways as well. The ng_parse stuff is a little different than the what I had in mind, but it looks like it might be useful. I have concerns about the ng_parse_type being too heavy weight for what I want to do. It maintains an offset in a long stream of data, and I'm just wanting to parse one thing. It seems a lot simpler and useful. Also, netgraph isn't required and I'd like to have something that is light weight enough to be included always. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
> Something like the following? I know that there's more routines that > need to be written. parse_int, parse_string, parse_bool, parse_enum > should be enough. > > Comments? Reuse the parsers in ng_parse.c, or (IMO better) use sscanf format strings (which are *extremely* flexible). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
> > Mike Smith wrote: > > > > If you say "kldload foo", you load the file foo.ko. However, that file > > may contain more than one module. > > I didn't know that was possible (i.e. supported)... Yup. In fact, modules aren't even bound to source files - you can have an arbitrary set of parameter-consuming objects within a single source file. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
In message <[EMAIL PROTECTED]> "Gary T. Corcoran" writes: : Perhaps instead of the "size_t off" above, which from the : code below tied us always into "softc", what about a more : general "void * varaddr"? That is, just put the address of : the variable into the driver_param struct? That would allow : driver global variables to be tuned as well - or in other : structures besides softc, if one wanted...? No. That makes it very hard to have multiple instances. You'd have to fill it in for each instance. It also encourages good programming by making driver writers use encapsilation. :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
Warner Losh wrote:
>
> Something like the following?
>
> Comments?
>
> struct driver_param
> {
> const char *name;
> int (*fnp)(const char *, void *, void *);
> size_t off;
> void *argp;
> };
>
Perhaps instead of the "size_t off" above, which from the
code below tied us always into "softc", what about a more
general "void * varaddr"? That is, just put the address of
the variable into the driver_param struct? That would allow
driver global variables to be tuned as well - or in other
structures besides softc, if one wanted...?
Gary
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
Something like the following? I know that there's more routines that
need to be written. parse_int, parse_string, parse_bool, parse_enum
should be enough.
Comments?
struct driver_param
{
const char *name;
int (*fnp)(const char *, void *, void *);
size_t off;
void *argp;
};
int get_parameters(device_t dev, struct driver_param *param, size_t nparam)
{
int i;
caddr_t sc;
const char *name;
int unit;
char buffer[1024];
const char *cp;
sc = device_get_softc(dev);
name = device_get_name(dev);
unit = device_get_unit(dev);
for (i = 0; i < nparam; i++) {
snprintf(buffer, "hints.%s.%d.%s", name, unit, param[i].name);
cp = getenv (buffer);
if (cp) {
if (param[i].fnp(cp, (void *) (sc + param[i].off),
param[i].argp) == 0)
continue;
}
snprintf(buffer, "hints.%s.%d.%s", name, -1, param[i].name);
cp = getenv (buffer);
if (cp) {
if (param[i].fnp(cp, (void *) (sc + param[i].off),
param[i].argp) == 0)
continue;
}
}
return 0;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
Warner Losh wrote: > > Yes. You'd say > > hint.dslmodem.-1.TransmissionMode=LLC What's the "-1" in the above? > But writing this, I thin that normal enums would want a specialized > routine for doing this that would could pass a table to. Yes, a table of strings and enums seems like a generally-useful thing to support - no need making each driver re-write the code... > Hmmm, maybe I should just write something now that I've designed it to > this level :-) Might as well... Thanks, Gary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
In message <[EMAIL PROTECTED]> "Gary T. Corcoran" writes:
: Forgive my ignorance (since I'm unfamiliar with this hint stuff), but
: I presume the above hints.foo... stuff just goes in some config file
: somewhere? And this config file would be consulted whenever a module
: is loaded? Just curious, what would "userconfig" be for?
Yes. hints are loaded in the environment at boot time. userconfig
will edit hints.
: Umm, I'm a little bit confused by the above. First you say that you'd
: make simple functions to do the storing, but that you don't do the
: parsing yourself.
No. I'd provide the usual functions to parse integers, simple
strings, booleans, etc and store them properly. Driver writers would
be free to provide their own string -> binary mappings if they
desired.
: If you don't know how to do the storing (because of
: a special type), how do you know how to do the parsing in a general
: routine? :)
That's implicit. All the strings in the enviornment are of the form:
hint.foo.4.key=value\0
so the function listed in the table would be called with value and it
would be responsible for storing the binary represenation of the
string.
: But then you go on to suggest that you would like the
: function pointers to give modules the maximum flexibility. This means
: that the module itself would have the functions for parsing the parameters,
: right? I'm not trying to give you a hard time, I'm just trying to
: understand what you really meant to say... :)
No. See above.
: And I do agree that it would be nice to have the flexibility for the
: module to parse its own parameters, if desired. For example, it would
: be much clearer, and less prone to error, if the user could specify
: TransmissionMode=LLC/SNAP/Bridged, rather than having to look up that
: LLC/SNAP/Bridged mode is value 4 and then put TransmissionMode=4 in
: a config file. The Windows "Advanced Properties" GUI allows this -
: that is, it presents a drop-down list of strings, and when the user
: chooses one, the corresponding enum'ed value is stored in the registry.
Yes. You'd say
hint.dslmodem.-1.TransmissionMode=LLC
and your entry would look like:
"TransmissionMode", offsetof(struct softc, tm), MyParseTM, NULL,
in the table. And it would be responsible for parsing. MyParseTM
would look like:
int
MyParseTM(const char *src, void *dst, void *argp)
{
int *valp = (int *) dst;
if (strcmp("LLC", src) == 0) {
*valp = 1;
return 1;
}
if (strcmp("Next", src) == 0) {
*valp = 2;
return 1;
}
// etc
return 0;
}
It would be called
ep points to the entry
vp points to "LLC"
sc points to softc.
ep->fnp(vp, (void *) ((caddr_t) sc) + ep->off, ep->argp);
But writing this, I thin that normal enums would want a specialized
routine for doing this that would could pass a table to.
Hmmm, maybe I should just write something now that I've designed it to
this level :-)
: But of course using the string to specify the desired
: mode takes more work on the part of the module writer, so it'd be
: nice to not require that in all cases, i.e. allow "=4" auto-parsed.
: I suppose we could have kernel-supplied functions to do the parsing
: for the typical simple cases, e.g. int's, strings, and allow the
: modules themselves to supply parsing routines for "special" parameters?
: Maybe that's what you meant by the above? ;-)
Something like that.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, "Gary T. Corcoran" writes: > > >No, I know it's not that easy. We need to be able to do things > >like have "TransmissionMode=4" on the kldload command line, and > >have that parse the decimal value 4, and then go into the module > > I have a much simpler idea: > > The loader needs to pass an argc+argv to the modules "configure" > routine, and the module can do whatever it damn pleases with > the passed arguments. Would be good to provide some standard routine somewhat like getopt() so that each module won't reimplement it by itself. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
Mike Smith wrote: > > If you say "kldload foo", you load the file foo.ko. However, that file > may contain more than one module. I didn't know that was possible (i.e. supported)... > The hints mechanism is what we are currently using to pass in the > information that used to be in the kernel configuration file. Each hint > is an entry in the kernel environment space; these are currently read > from a file by the loader when it's loading the kernel, but we must also > have an interface for setting these after the system starts. Gee, you mean you're not gonna make me reboot every time I change a setting like Windows does? :-P Actually they've gotten rid of most of that baloney in Windows2000, so we better not be worse! > In addition, it should be possible to pass arguments to a module as you > load it, however it's not clear yet that this is the "clean" way to do it. > I think the initial approach is going to look like this: > > # kenv hint.foo.0.parameter=15 > # kldload foo > > ie. the hints can be set entirely independently of the module load. Sounds reasonable to me... Gary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
> > : The Linux approach is bad insofar as the arguments are per-module rather > > : than per-instance. In our case we need per-module and per-instance even > > : though the arguments are supplied per-file. > > You're right, Mike. I hadn't thought about it (since one usually won't > have more than one DSL card in a PC :), but to be generally useful, we really > should have per-instance arguments for modules that support multiple > instances of the same device. I'm not sure what you mean though, by > "even though the arguments are supplied per-file" ? If you say "kldload foo", you load the file foo.ko. However, that file may contain more than one module. So in order to pass arguments to each of those modules, you need some way of associating an argument with a module. > It sounds pretty good to me, too. And yes, even though my initial > example concerned just an int, you also need to be able to set strings > for tunable parameters (e.g. the Service Name for PPPoE). > Forgive my ignorance (since I'm unfamiliar with this hint stuff), but > I presume the above hints.foo... stuff just goes in some config file > somewhere? And this config file would be consulted whenever a module > is loaded? Just curious, what would "userconfig" be for? The hints mechanism is what we are currently using to pass in the information that used to be in the kernel configuration file. Each hint is an entry in the kernel environment space; these are currently read from a file by the loader when it's loading the kernel, but we must also have an interface for setting these after the system starts. In addition, it should be possible to pass arguments to a module as you load it, however it's not clear yet that this is the "clean" way to do it. I think the initial approach is going to look like this: # kenv hint.foo.0.parameter=15 # kldload foo ie. the hints can be set entirely independently of the module load. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> Mike Smith writes:
> : > In message <[EMAIL PROTECTED]> "Gary T. Corcoran" writes:
> : > : No, I know it's not that easy. We need to be able to do things
> : > : like have "TransmissionMode=4" on the kldload command line, and
> : > : have that parse the decimal value 4, and then go into the module
> : > : and set the value of the TransmissionMode variable to actually be
> : > : 4 immediately after loading the module into memory, before any of
> : > : its subroutines are called. This is what the Linux module loader
> : > : allows, and it's extremely useful...
> : >
> : > Understood. What I'm suggesting is that you get those values from the
> : > kernel like so:
> : >
> : > int transmission_mode;
> : >
> : > transmission_mode = 4; /* 4 is the default */
> : > if (resource_int_value(name, unit, "TransmissionMode",
> : > &transmission_mode) != 0)
> : > resource-int_value(name, -1, "TransmissionMode",
> : > &transmission_mode);
> : >
> : > You can then put
> : > hint.dslmodem.-1.TransmissionMode=4
> : > in your hints file for the kernel.
> : >
> : > Right now the draw back of this is that hints cannot be added after
> : > boot. We're working on fixing that. So if you use this model, you'll
> : > get the dynamic setting of this information essensially for free.
> :
> : What Gary and Archie are talking about is actually quite smarfy, and I'm
> : somewhat torn. Imagine an API like this:
> :
> : struct foodev_tunables {
> : int colour;
> : charname[32];
> : };
> :
> : struct config_keys[] {
> : {"colour", offsetof(struct foodev_tunables, colour), TYPE_INT, 0},
> : {"name", offsetof(struct foodev_tunables, name), TYPE_CHAR, 32}
> : };
> : ...
> : hints_get_config(dev, &config_keys, &foodev_tunables);
> :
> : The Linux approach is bad insofar as the arguments are per-module rather
> : than per-instance. In our case we need per-module and per-instance even
> : though the arguments are supplied per-file.
You're right, Mike. I hadn't thought about it (since one usually won't
have more than one DSL card in a PC :), but to be generally useful, we really
should have per-instance arguments for modules that support multiple
instances of the same device. I'm not sure what you mean though, by
"even though the arguments are supplied per-file" ?
> So the above would, for
> : example, as the foo0 device pick up:
> :
> : hints.foo.*.colour=4
> : hints.foo.0.name="foo the zeroeth"
> :
> : and pack them into the structure. You could easily use this to tweak
> : tunables in your softc, etc. with a lot less code overhead than one call
> : per tunable.
>
> I like that idea, so long as it doesn't add yet another configuration
> path. That is, so long as it builds on the hint and hint management
> that is in the kernel now so that it can easily be added to userconfig
> later.
It sounds pretty good to me, too. And yes, even though my initial
example concerned just an int, you also need to be able to set strings
for tunable parameters (e.g. the Service Name for PPPoE).
Forgive my ignorance (since I'm unfamiliar with this hint stuff), but
I presume the above hints.foo... stuff just goes in some config file
somewhere? And this config file would be consulted whenever a module
is loaded? Just curious, what would "userconfig" be for?
> In fact, that's where I'd like to take things in the future. It was
> part of what I'd envisoned when I started. However, the config_keys
> would have function pointers rather than raw offsets. The raw offsets
> are OK, but you run into a lot of problems with them down the road.
> You make simple functions that will do the storing, and that replaces
> your TYPE_XXX parameter as well.
>
> It would certainly be nicer than parsing it yourself.
>
> I've been down this path twice before on large X toolkits (twice with
> the OI toolkit), so I know the problems that you're going to hit. The
> type parameter is weak at best because later you'll want to have a
> filename (which is a string of a certain syntax and meaning) as well
> as a node id (which is also a string of a certain, but different,
> syntax and meaning). It will be much easier if we allow for function
> pointers now to deal with that and to give the modules the maximum
> flexibility in turning their strings into numbers.
Umm, I'm a little bit confused by the above. First you say that you'd
make simple functions to do the storing, but that you don't do the
parsing yourself. If you don't know how to do the storing (because of
a special type), how do you know how to do the parsing in a general
routine? :) But then you go on to suggest that you would like the
function pointers to give modules the maximum flexibility. This means
that the module itself would have the functions for parsing the parameters,
right? I'm not trying to give you a hard time, I'm just trying to
understand wh
Re: Module parameters?
In message <[EMAIL PROTECTED]> Mike Smith writes:
: > In message <[EMAIL PROTECTED]> "Gary T. Corcoran" writes:
: > : No, I know it's not that easy. We need to be able to do things
: > : like have "TransmissionMode=4" on the kldload command line, and
: > : have that parse the decimal value 4, and then go into the module
: > : and set the value of the TransmissionMode variable to actually be
: > : 4 immediately after loading the module into memory, before any of
: > : its subroutines are called. This is what the Linux module loader
: > : allows, and it's extremely useful...
: >
: > Understood. What I'm suggesting is that you get those values from the
: > kernel like so:
: >
: > int transmission_mode;
: >
: > transmission_mode = 4; /* 4 is the default */
: > if (resource_int_value(name, unit, "TransmissionMode",
: > &transmission_mode) != 0)
: > resource-int_value(name, -1, "TransmissionMode",
: > &transmission_mode);
: >
: > You can then put
: > hint.dslmodem.-1.TransmissionMode=4
: > in your hints file for the kernel.
: >
: > Right now the draw back of this is that hints cannot be added after
: > boot. We're working on fixing that. So if you use this model, you'll
: > get the dynamic setting of this information essensially for free.
:
: What Gary and Archie are talking about is actually quite smarfy, and I'm
: somewhat torn. Imagine an API like this:
:
: struct foodev_tunables {
: int colour;
: charname[32];
: };
:
: struct config_keys[] {
: {"colour", offsetof(struct foodev_tunables, colour), TYPE_INT, 0},
: {"name", offsetof(struct foodev_tunables, name), TYPE_CHAR, 32}
: };
: ...
: hints_get_config(dev, &config_keys, &foodev_tunables);
:
: The Linux approach is bad insofar as the arguments are per-module rather
: than per-instance. In our case we need per-module and per-instance even
: though the arguments are supplied per-file. So the above would, for
: example, as the foo0 device pick up:
:
: hints.foo.*.colour=4
: hints.foo.0.name="foo the zeroeth"
:
: and pack them into the structure. You could easily use this to tweak
: tunables in your softc, etc. with a lot less code overhead than one call
: per tunable.
I like that idea, so long as it doesn't add yet another configuration
path. That is, so long as it builds on the hint and hint management
that is in the kernel now so that it can easily be added to userconfig
later.
In fact, that's where I'd like to take things in the future. It was
part of what I'd envisoned when I started. However, the config_keys
would have function pointers rather than raw offsets. The raw offsets
are OK, but you run into a lot of problems with them down the road.
You make simple functions that will do the storing, and that replaces
your TYPE_XXX parameter as well.
It would certainly be nicer than parsing it yourself.
I've been down this path twice before on large X toolkits (twice with
the OI toolkit), so I know the problems that you're going to hit. The
type parameter is weak at best because later you'll want to have a
filename (which is a string of a certain syntax and meaning) as well
as a node id (which is also a string of a certain, but different,
syntax and meaning). It will be much easier if we allow for function
pointers now to deal with that and to give the modules the maximum
flexibility in turning their strings into numbers.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
> In message <[EMAIL PROTECTED]> "Gary T. Corcoran" writes:
> : No, I know it's not that easy. We need to be able to do things
> : like have "TransmissionMode=4" on the kldload command line, and
> : have that parse the decimal value 4, and then go into the module
> : and set the value of the TransmissionMode variable to actually be
> : 4 immediately after loading the module into memory, before any of
> : its subroutines are called. This is what the Linux module loader
> : allows, and it's extremely useful...
>
> Understood. What I'm suggesting is that you get those values from the
> kernel like so:
>
> int transmission_mode;
>
> transmission_mode = 4; /* 4 is the default */
> if (resource_int_value(name, unit, "TransmissionMode",
> &transmission_mode) != 0)
> resource-int_value(name, -1, "TransmissionMode",
> &transmission_mode);
>
> You can then put
> hint.dslmodem.-1.TransmissionMode=4
> in your hints file for the kernel.
>
> Right now the draw back of this is that hints cannot be added after
> boot. We're working on fixing that. So if you use this model, you'll
> get the dynamic setting of this information essensially for free.
What Gary and Archie are talking about is actually quite smarfy, and I'm
somewhat torn. Imagine an API like this:
struct foodev_tunables {
int colour;
charname[32];
};
struct config_keys[] {
{"colour", offsetof(struct foodev_tunables, colour), TYPE_INT, 0},
{"name", offsetof(struct foodev_tunables, name), TYPE_CHAR, 32}
};
...
hints_get_config(dev, &config_keys, &foodev_tunables);
The Linux approach is bad insofar as the arguments are per-module rather
than per-instance. In our case we need per-module and per-instance even
though the arguments are supplied per-file. So the above would, for
example, as the foo0 device pick up:
hints.foo.*.colour=4
hints.foo.0.name="foo the zeroeth"
and pack them into the structure. You could easily use this to tweak
tunables in your softc, etc. with a lot less code overhead than one call
per tunable.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
In message <[EMAIL PROTECTED]> "Gary T. Corcoran" writes: : No, I know it's not that easy. We need to be able to do things : like have "TransmissionMode=4" on the kldload command line, and : have that parse the decimal value 4, and then go into the module : and set the value of the TransmissionMode variable to actually be : 4 immediately after loading the module into memory, before any of : its subroutines are called. This is what the Linux module loader : allows, and it's extremely useful... Understood. What I'm suggesting is that you get those values from the kernel like so: int transmission_mode; transmission_mode = 4; /* 4 is the default */ if (resource_int_value(name, unit, "TransmissionMode", &transmission_mode) != 0) resource-int_value(name, -1, "TransmissionMode", &transmission_mode); You can then put hint.dslmodem.-1.TransmissionMode=4 in your hints file for the kernel. Right now the draw back of this is that hints cannot be added after boot. We're working on fixing that. So if you use this model, you'll get the dynamic setting of this information essensially for free. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
> In message <[EMAIL PROTECTED]>, "Gary T. Corcoran" writes: > > >No, I know it's not that easy. We need to be able to do things > >like have "TransmissionMode=4" on the kldload command line, and > >have that parse the decimal value 4, and then go into the module > >and set the value of the TransmissionMode variable to actually be > >4 immediately after loading the module into memory, before any of > >its subroutines are called. This is what the Linux module loader > >allows, and it's extremely useful... > > I have a much simpler idea: > > The loader needs to pass an argc+argv to the modules "configure" > routine, and the module can do whatever it damn pleases with > the passed arguments. This was what I was originally contemplating, along with infrastructure for getopt-style helpers. However, having looked at the "Linux way" of doing things, I'm leaning towards a compromise solution. We have a couple of interesting issues to consider; for example, who gets which arguments when we load a file which contains several modules? Archie - I'd really appreciate a pointer to an example of using the ng_parse code to pick up this sort of data, if you can recommend something to help me get my head around it quickly (I've looked but slid off sideways so far...). Thanks -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
In message <[EMAIL PROTECTED]>, "Gary T. Corcoran" writes: >No, I know it's not that easy. We need to be able to do things >like have "TransmissionMode=4" on the kldload command line, and >have that parse the decimal value 4, and then go into the module >and set the value of the TransmissionMode variable to actually be >4 immediately after loading the module into memory, before any of >its subroutines are called. This is what the Linux module loader >allows, and it's extremely useful... I have a much simpler idea: The loader needs to pass an argc+argv to the modules "configure" routine, and the module can do whatever it damn pleases with the passed arguments. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
Gary T. Corcoran writes: > > > : I was wondering if you (or anyone on this list) has had time > > > : to add module parameters to kldload? (and before anyone suggests > > > : it, sorry, but I am barely able to squeeze out enough time to > > > : even work on this unofficial driver, I can't work on kldload) > > > > > > You can use the hint mechanism that we've developed for other things. > > > > Another possibility is the netgraph binary <-> ASCII conversion stuff: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_parse.h?rev=1.3 > > Are you suggesting that these routines could be used to > easily add parameters to kldload? (hint, hint) :-) > No, I know it's not that easy. We need to be able to do things > like have "TransmissionMode=4" on the kldload command line, and > have that parse the decimal value 4, and then go into the module > and set the value of the TransmissionMode variable to actually be > 4 immediately after loading the module into memory, before any of > its subroutines are called. This is what the Linux module loader > allows, and it's extremely useful... This is the kind of thing ng_parse.c can do. In fact kldload could just pass the parameters as a single, opaque ASCII string and the kernel (the KLD, actually) can decode it back into a binary C structure using the ng_parse routines. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
Archie Cobbs wrote: > > Warner Losh writes: > > In message <[EMAIL PROTECTED]> "Gary T. Corcoran" writes: > > : I was wondering if you (or anyone on this list) has had time > > : to add module parameters to kldload? (and before anyone suggests > > : it, sorry, but I am barely able to squeeze out enough time to > > : even work on this unofficial driver, I can't work on kldload) > > > > You can use the hint mechanism that we've developed for other things. > > Another possibility is the netgraph binary <-> ASCII conversion stuff: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_parse.h?rev=1.3 Are you suggesting that these routines could be used to easily add parameters to kldload? (hint, hint) No, I know it's not that easy. We need to be able to do things like have "TransmissionMode=4" on the kldload command line, and have that parse the decimal value 4, and then go into the module and set the value of the TransmissionMode variable to actually be 4 immediately after loading the module into memory, before any of its subroutines are called. This is what the Linux module loader allows, and it's extremely useful... Gary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
Warner Losh writes: > In message <[EMAIL PROTECTED]> "Gary T. Corcoran" writes: > : I was wondering if you (or anyone on this list) has had time > : to add module parameters to kldload? (and before anyone suggests > : it, sorry, but I am barely able to squeeze out enough time to > : even work on this unofficial driver, I can't work on kldload) > > You can use the hint mechanism that we've developed for other things. Another possibility is the netgraph binary <-> ASCII conversion stuff: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_parse.h?rev=1.3 -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Module parameters?
In message <[EMAIL PROTECTED]> "Gary T. Corcoran" writes: : I was wondering if you (or anyone on this list) has had time : to add module parameters to kldload? (and before anyone suggests : it, sorry, but I am barely able to squeeze out enough time to : even work on this unofficial driver, I can't work on kldload) You can use the hint mechanism that we've developed for other things. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Module parameters?
Mike, A couple of months ago we spoke about my needing the ability to set module parameters during a kldload, and you indicated that you would be working on them for FreeBSD 4.1. I've since progressed my DSL driver to the point where it works in all the modes I need (same as the Linux driver), but I have to recompile my driver to change any options. Therefore, I haven't done any further work on it, and I have been unable to make it available to anyone else for beta testing (since everyone needs to change options for their particular installation)... I was wondering if you (or anyone on this list) has had time to add module parameters to kldload? (and before anyone suggests it, sorry, but I am barely able to squeeze out enough time to even work on this unofficial driver, I can't work on kldload) Thanks, Gary -- = Gary Corcoran - Distinguished Member of Technical Staff Lucent Microelectronics - Client Access Broadband Systems Communications Protocol & Driver Development Group "We make the drivers that make communications work" Email: [EMAIL PROTECTED] = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
