Re: Proposing argv for klds and preloaded modules
Peter Wemm wrote: Don't forget, there are zero or more modules per file. Which one gets the arguments? Coda (for example) is structured so that it has two modules, one device (codadev) and one vfs (coda). It seems to me that the one who gets the arguments is the one who searches for it. :-) Either that, or the first file in the module. I don't recall right now the precise structure of this in memory. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposing argv for klds and preloaded modules
"Daniel C. Sobral" wrote: assuming we are making it at all, the less pain. It provides a way of getting parameters that is compatible with what is already possible with loader (ie, the module need not differentiate between it's method of loading). The code is working and ready. Actually... Loader passes a string. It seems the kldcode is passing argv[]. Juha, you sure you have they both working the same way (from a module's perspective)? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposing argv for klds and preloaded modules
On Tue, 3 Aug 1999, Peter Wemm wrote: Don't forget, there are zero or more modules per file. Which one gets the arguments? Coda (for example) is structured so that it has two modules, one device (codadev) and one vfs (coda). Yes, the naming 'module_get_file_argstr()' had the _file_ for just this reason, filewide argument string. I didn't know any plans were already made on these circles, had only buggered Mr. Rabson once about arguments. Well, no harm done, I hope. Juha To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposing argv for klds and preloaded modules
Juha Nurmela wrote: On Tue, 3 Aug 1999, Daniel C. Sobral wrote: Actually... Loader passes a string. It seems the kldcode is passing argv[]. Juha, you sure you have they both working the same way (from a module's perspective)? It's splatted together, by just putting ' ' between words, somewhere in there. Search for strbuf Juha Don't forget, there are zero or more modules per file. Which one gets the arguments? Coda (for example) is structured so that it has two modules, one device (codadev) and one vfs (coda). This is why Warner's X-resource-like proposal is the only method for passing parameters to modules that I am likely to accept. argv/argc and getopt() are just not good enough. If someone want to implement a simple resource matcher, you could start by coming up with a tiny, tidy glob() for the kernel. We can use it elsewhere as well... -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposing argv for klds and preloaded modules
Daniel C. Sobral wrote: assuming we are making it at all, the less pain. It provides a way of getting parameters that is compatible with what is already possible with loader (ie, the module need not differentiate between it's method of loading). The code is working and ready. Actually... Loader passes a string. It seems the kldcode is passing argv[]. Juha, you sure you have they both working the same way (from a module's perspective)? -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
On Tue, 3 Aug 1999, Daniel C. Sobral wrote: Actually... Loader passes a string. It seems the kldcode is passing argv[]. Juha, you sure you have they both working the same way (from a module's perspective)? It's splatted together, by just putting ' ' between words, somewhere in there. Search for strbuf Juha To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
Juha Nurmela wrote: On Tue, 3 Aug 1999, Daniel C. Sobral wrote: Actually... Loader passes a string. It seems the kldcode is passing argv[]. Juha, you sure you have they both working the same way (from a module's perspective)? It's splatted together, by just putting ' ' between words, somewhere in there. Search for strbuf Juha Don't forget, there are zero or more modules per file. Which one gets the arguments? Coda (for example) is structured so that it has two modules, one device (codadev) and one vfs (coda). Cheers, -Peter -- Peter Wemm - pe...@freebsd.org; pe...@yahoo-inc.com; pe...@netplex.com.au To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
Peter Wemm wrote: Don't forget, there are zero or more modules per file. Which one gets the arguments? Coda (for example) is structured so that it has two modules, one device (codadev) and one vfs (coda). It seems to me that the one who gets the arguments is the one who searches for it. :-) Either that, or the first file in the module. I don't recall right now the precise structure of this in memory. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
Daniel C. Sobral wrote: Peter Wemm wrote: Don't forget, there are zero or more modules per file. Which one gets the arguments? Coda (for example) is structured so that it has two modules, on e device (codadev) and one vfs (coda). It seems to me that the one who gets the arguments is the one who searches for it. :-) Either that, or the first file in the module. I don't recall right now the precise structure of this in memory. The Plan(TM) was that things will be able to query the resource database. What I've had in mind for a while is to take the argument strings etc and merge them into the tables, but that's a rather device centric view. They would be installable either via preload args, kldload args and/or settable via some userland tool (sysctl would be ideal, but it's too limited in it's design - it can't have arbitary strings, everything has to translate to an OID first). Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
On Tue, 3 Aug 1999, Peter Wemm wrote: Don't forget, there are zero or more modules per file. Which one gets the arguments? Coda (for example) is structured so that it has two modules, one device (codadev) and one vfs (coda). Yes, the naming 'module_get_file_argstr()' had the _file_ for just this reason, filewide argument string. I didn't know any plans were already made on these circles, had only buggered Mr. Rabson once about arguments. Well, no harm done, I hope. Juha To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
Juha Nurmela wrote: On Tue, 3 Aug 1999, Daniel C. Sobral wrote: Actually... Loader passes a string. It seems the kldcode is passing argv[]. Juha, you sure you have they both working the same way (from a module's perspective)? It's splatted together, by just putting ' ' between words, somewhere in there. Search for strbuf Juha Don't forget, there are zero or more modules per file. Which one gets the arguments? Coda (for example) is structured so that it has two modules, one device (codadev) and one vfs (coda). This is why Warner's X-resource-like proposal is the only method for passing parameters to modules that I am likely to accept. argv/argc and getopt() are just not good enough. If someone want to implement a simple resource matcher, you could start by coming up with a tiny, tidy glob() for the kernel. We can use it elsewhere as well... -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
On Sun, 1 Aug 1999, Chris Costello wrote: On Sun, Aug 01, 1999, Juha Nurmela wrote: Sometimes it would be handy to pass a commandline to a kld, preloaded modules already support arguments. kldload(2) unfortunately has only the pathname.ko argument. Is this really a problem? Can the administrator not use sysctl instead? It is not always possible. Some device drivers (both hardware and software) require an arguments that needed at init/attach time. IMO, args should be passed in usual manner via argv[] and argc with plain get_opt() in libkern. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposing argv for klds and preloaded modules
Warner Losh wrote: In message [EMAIL PROTECTED] Juha Nurmela writes: : Yes, but (this might be a trademark ;) commonly the arguments would : be used during the sysinit-attach, and at that time sysctl has not yet : been able to change anything. Use of sysctl would require a sidestep : from attach and later continuation with a sysctl_proc. Not a problem, : but inconvenient, IMHO. And it's analogous to executing, they too : can get arguments. I believe that the plan was to make to have more generic stuff so that all drivers woudln't have to parse argv... Modules are not just drivers. Forget about drivers, and try again. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposing argv for klds and preloaded modules
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes: : Modules are not just drivers. Forget about drivers, and try again. : :-) But the generic mechanism extends beyond just drivers :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposing argv for klds and preloaded modules
Warner Losh wrote: In message [EMAIL PROTECTED] "Daniel C. Sobral" writes: : Modules are not just drivers. Forget about drivers, and try again. : :-) But the generic mechanism extends beyond just drivers :-) Ah, I recall now. Something similar to the way X works, with all the information stored in a file instead of passed on the command line. If things are passed on the command line, we put a getopt() in the kernel and that's that. Get the _string_ to the application, and let it do it's job. We'll seriously regret anything else. For that matter, when I was working on loader's commands, I want to pre-process their arguments. That idea was shot down on the grounds that we can't foresee what the applications will need as parameters. The same applies here, right? So, here is my take. On one hand, we have Juha's code. The change proposed needs a new syscall. The sooner we make the change, assuming we are making it at all, the less pain. It provides a way of getting parameters that is compatible with what is already possible with loader (ie, the module need not differentiate between it's method of loading). The code is working and ready. On the other hand, we have a vaguely defined vapourware that looks real cool, and will be done some day after other outstanding priorities are dealt with. I'm not a fan of adding code to FreeBSD just because it exists. That _is_ one thing we do different from another popular open source OS, and which serves us well. If the code is crass, does not serve us well, is kitchen-sink bloating, or goes in a direction we see as a dead-end, it should not be imported. Alas, it seems none of the above applies. Even if we *do* come up with something better later, this code won't get in the way any more than what's in loader(8) already does. In that light, I think we ought to import it into our tree. BTW, won't any of the kld gods speak up? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposing argv for klds and preloaded modules
On Tue, 3 Aug 1999, Daniel C. Sobral wrote: Warner Losh wrote: In message [EMAIL PROTECTED] "Daniel C. Sobral" writes: : Modules are not just drivers. Forget about drivers, and try again. : :-) But the generic mechanism extends beyond just drivers :-) Ah, I recall now. Something similar to the way X works, with all the information stored in a file instead of passed on the command line. If things are passed on the command line, we put a getopt() in the kernel and that's that. Get the _string_ to the application, and let it do it's job. We'll seriously regret anything else. For that matter, when I was working on loader's commands, I want to pre-process their arguments. That idea was shot down on the grounds that we can't foresee what the applications will need as parameters. The same applies here, right? So, here is my take. On one hand, we have Juha's code. The change proposed needs a new syscall. The sooner we make the change, assuming we are making it at all, the less pain. It provides a way of getting parameters that is compatible with what is already possible with loader (ie, the module need not differentiate between it's method of loading). The code is working and ready. On the other hand, we have a vaguely defined vapourware that looks real cool, and will be done some day after other outstanding priorities are dealt with. I'm not a fan of adding code to FreeBSD just because it exists. That _is_ one thing we do different from another popular open source OS, and which serves us well. If the code is crass, does not serve us well, is kitchen-sink bloating, or goes in a direction we see as a dead-end, it should not be imported. Alas, it seems none of the above applies. Even if we *do* come up with something better later, this code won't get in the way any more than what's in loader(8) already does. In that light, I think we ought to import it into our tree. BTW, won't any of the kld gods speak up? I'm currently extremely distracted by non-FreeBSD work and will be so until after SIGGRAPH. If Peter doesn't show an interest before then remind me in a couple of weeks. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposing argv for klds and preloaded modules
On Sun, 1 Aug 1999, Chris Costello wrote: On Sun, Aug 01, 1999, Juha Nurmela wrote: Sometimes it would be handy to pass a commandline to a kld, preloaded modules already support arguments. kldload(2) unfortunately has only the pathname.ko argument. Is this really a problem? Can the administrator not use sysctl instead? It is not always possible. Some device drivers (both hardware and software) require an arguments that needed at init/attach time. IMO, args should be passed in usual manner via argv[] and argc with plain get_opt() in libkern. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
Warner Losh wrote: In message pine.bsf.4.05.9908020021290.9676-100...@pena.oh5nxo.ampr.org Juha Nurmela writes: : Yes, but (this might be a trademark ;) commonly the arguments would : be used during the sysinit-attach, and at that time sysctl has not yet : been able to change anything. Use of sysctl would require a sidestep : from attach and later continuation with a sysctl_proc. Not a problem, : but inconvenient, IMHO. And it's analogous to executing, they too : can get arguments. I believe that the plan was to make to have more generic stuff so that all drivers woudln't have to parse argv... Modules are not just drivers. Forget about drivers, and try again. :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
In message 37a5c680.3ca1d...@newsguy.com Daniel C. Sobral writes: : Modules are not just drivers. Forget about drivers, and try again. : :-) But the generic mechanism extends beyond just drivers :-) Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
Warner Losh wrote: In message 37a5c680.3ca1d...@newsguy.com Daniel C. Sobral writes: : Modules are not just drivers. Forget about drivers, and try again. : :-) But the generic mechanism extends beyond just drivers :-) Ah, I recall now. Something similar to the way X works, with all the information stored in a file instead of passed on the command line. If things are passed on the command line, we put a getopt() in the kernel and that's that. Get the _string_ to the application, and let it do it's job. We'll seriously regret anything else. For that matter, when I was working on loader's commands, I want to pre-process their arguments. That idea was shot down on the grounds that we can't foresee what the applications will need as parameters. The same applies here, right? So, here is my take. On one hand, we have Juha's code. The change proposed needs a new syscall. The sooner we make the change, assuming we are making it at all, the less pain. It provides a way of getting parameters that is compatible with what is already possible with loader (ie, the module need not differentiate between it's method of loading). The code is working and ready. On the other hand, we have a vaguely defined vapourware that looks real cool, and will be done some day after other outstanding priorities are dealt with. I'm not a fan of adding code to FreeBSD just because it exists. That _is_ one thing we do different from another popular open source OS, and which serves us well. If the code is crass, does not serve us well, is kitchen-sink bloating, or goes in a direction we see as a dead-end, it should not be imported. Alas, it seems none of the above applies. Even if we *do* come up with something better later, this code won't get in the way any more than what's in loader(8) already does. In that light, I think we ought to import it into our tree. BTW, won't any of the kld gods speak up? -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
On Tue, 3 Aug 1999, Daniel C. Sobral wrote: Warner Losh wrote: In message 37a5c680.3ca1d...@newsguy.com Daniel C. Sobral writes: : Modules are not just drivers. Forget about drivers, and try again. : :-) But the generic mechanism extends beyond just drivers :-) Ah, I recall now. Something similar to the way X works, with all the information stored in a file instead of passed on the command line. If things are passed on the command line, we put a getopt() in the kernel and that's that. Get the _string_ to the application, and let it do it's job. We'll seriously regret anything else. For that matter, when I was working on loader's commands, I want to pre-process their arguments. That idea was shot down on the grounds that we can't foresee what the applications will need as parameters. The same applies here, right? So, here is my take. On one hand, we have Juha's code. The change proposed needs a new syscall. The sooner we make the change, assuming we are making it at all, the less pain. It provides a way of getting parameters that is compatible with what is already possible with loader (ie, the module need not differentiate between it's method of loading). The code is working and ready. On the other hand, we have a vaguely defined vapourware that looks real cool, and will be done some day after other outstanding priorities are dealt with. I'm not a fan of adding code to FreeBSD just because it exists. That _is_ one thing we do different from another popular open source OS, and which serves us well. If the code is crass, does not serve us well, is kitchen-sink bloating, or goes in a direction we see as a dead-end, it should not be imported. Alas, it seems none of the above applies. Even if we *do* come up with something better later, this code won't get in the way any more than what's in loader(8) already does. In that light, I think we ought to import it into our tree. BTW, won't any of the kld gods speak up? I'm currently extremely distracted by non-FreeBSD work and will be so until after SIGGRAPH. If Peter doesn't show an interest before then remind me in a couple of weeks. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
On Sun, Aug 01, 1999, Juha Nurmela wrote: Hello. Sometimes it would be handy to pass a commandline to a kld, preloaded modules already support arguments. kldload(2) unfortunately has only the pathname.ko argument. Is this really a problem? Can the administrator not use sysctl instead? -- |Chris Costello [EMAIL PROTECTED] |Advanced design: Upper management doesn't understand it. ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposing argv for klds and preloaded modules
On Sun, 1 Aug 1999, Chris Costello wrote: On Sun, Aug 01, 1999, Juha Nurmela wrote: Sometimes it would be handy to pass a commandline to a kld, preloaded modules already support arguments. kldload(2) unfortunately has only the pathname.ko argument. Is this really a problem? Can the administrator not use sysctl instead? Yes, but (this might be a trademark ;) commonly the arguments would be used during the sysinit-attach, and at that time sysctl has not yet been able to change anything. Use of sysctl would require a sidestep from attach and later continuation with a sysctl_proc. Not a problem, but inconvenient, IMHO. And it's analogous to executing, they too can get arguments. Juha To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposing argv for klds and preloaded modules
On Sun, Aug 01, 1999, Juha Nurmela wrote: Hello. Sometimes it would be handy to pass a commandline to a kld, preloaded modules already support arguments. kldload(2) unfortunately has only the pathname.ko argument. Is this really a problem? Can the administrator not use sysctl instead? -- |Chris Costello ch...@calldei.com |Advanced design: Upper management doesn't understand it. ` To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
On Sun, 1 Aug 1999, Chris Costello wrote: On Sun, Aug 01, 1999, Juha Nurmela wrote: Sometimes it would be handy to pass a commandline to a kld, preloaded modules already support arguments. kldload(2) unfortunately has only the pathname.ko argument. Is this really a problem? Can the administrator not use sysctl instead? Yes, but (this might be a trademark ;) commonly the arguments would be used during the sysinit-attach, and at that time sysctl has not yet been able to change anything. Use of sysctl would require a sidestep from attach and later continuation with a sysctl_proc. Not a problem, but inconvenient, IMHO. And it's analogous to executing, they too can get arguments. Juha To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
In message pine.bsf.4.05.9908020021290.9676-100...@pena.oh5nxo.ampr.org Juha Nurmela writes: : Yes, but (this might be a trademark ;) commonly the arguments would : be used during the sysinit-attach, and at that time sysctl has not yet : been able to change anything. Use of sysctl would require a sidestep : from attach and later continuation with a sysctl_proc. Not a problem, : but inconvenient, IMHO. And it's analogous to executing, they too : can get arguments. I believe that the plan was to make to have more generic stuff so that all drivers woudln't have to parse argv... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
