Re: Modules and sysctl tree
In message [EMAIL PROTECTED], Jul ian Elischer writes: [sysctlfs] Linux have basically done this in their procfs. And have recently started to wonder if that wasn't a mistake I've heard. I would regard sysctlfs as a grave mistake. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
"Jordan K. Hubbard" wrote: In other words, it's not a problem specific to KLD's .. but it's still a problem :-) Which raises an important issue - other than walking the sysctl tree regularly looking for changes, how does such an application become aware that the sysctl space has changed? The same holds true for a dynamic /dev, of course, though one assumes one can at least hack a solution with devfs where you stat the directory and compare its current mod time with a saved one, only walking the directory if you see a change. I don't see any kind of mechanism for doing this with sysctl, even as a gross hack. It crossed my mind when implementing Linuxulator sysctl variables. IIRC, I though that it might be a good idea to have a `kern.modules' tree that holds which modules are loaded (either dynamicly or staticly). Since each sysctl variable belongs to a module (be it the kernel core), walking the `kern.modules' tree is sufficient to detect changes in the rest of the sysctl tree. It can also used as an alternative to find out if module foobar is loaded, for example. An alternative to this is to only add modules to kern.modules if it changes the sysctl tree. The number of variables would be limited to only one or two (maybe three :-). -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
According to Garrett Wollman: It's listening on a kernel notification socket. (Implementation is an exercise left for the reader, but there are already a few examples.) Like the routing socket I guess ? Or we could implement POLLSYSCTL ? :-) /me hides and runs -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #75: Tue Nov 2 21:03:12 CET 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
I think the latter. In 'theory' there should be no discernable difference between functionality from a KLD vs. the same functionality compiled directly into the kernel. Only in theory, of course. :) As Andrzej has already pointed out, modules can also be loaded and unloaded, creating a sysctl space where things enter and leave dynamically. Let's say I'm somebody who creates a nifty little GUI sysctl editor for the CLI-challenged and, because it's time-consuming to build a form with fields for all the relevant sysctl variables, I take the obvious shortcut of parsing the output of `sysctl -A' once at startup time and then dealing with the individual field callbacks thereafter. On my "classic" system with a config-generated kernel, this works just fine and my GUI front-end for sysctl is eventually declared "useful enough" that I start handing it around. Then somebody who actually loads and unloads klds tries to use it, and results (needless to say) are no longer quite in alignment with expectations. :) Just a hypothetical scenario, of course, but I simply wanted to make the point that "no discernable difference" might be hard to achieve for certain values of discernment. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
In other words, it's not a problem specific to KLD's .. but it's still a problem :-) Which raises an important issue - other than walking the sysctl tree regularly looking for changes, how does such an application become aware that the sysctl space has changed? The same holds true for a dynamic /dev, of course, though one assumes one can at least hack a solution with devfs where you stat the directory and compare its current mod time with a saved one, only walking the directory if you see a change. I don't see any kind of mechanism for doing this with sysctl, even as a gross hack. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
On 11-Dec-99 Jordan K. Hubbard wrote: In other words, it's not a problem specific to KLD's .. but it's still a problem :-) Which raises an important issue - other than walking the sysctl tree regularly looking for changes, how does such an application become aware that the sysctl space has changed? The same holds true for a dynamic /dev, of course, though one assumes one can at least hack a solution with devfs where you stat the directory and compare its current mod time with a saved one, only walking the directory if you see a change. I don't see any kind of mechanism for doing this with sysctl, even as a gross hack. Perhaps a modtime on the sysctl tree as a gross hack? Inside of sysctl() and the SYSCTL() macros you would update the time every time a write was made, node added, node removed, etc. However, it is a gross hack. - Jordan -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
other than walking the sysctl tree regularly looking for changes Use a similar hack: map the sysctl tree to the filesystem (ala kernfs) and then stat the directory nodes. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
Perhaps a modtime on the sysctl tree as a gross hack? Inside of sysctl() and the SYSCTL() macros you would update the time every time a write was made, no de added, node removed, etc. However, it is a gross hack. You're right, it would be a gross hack. :) Also, I can see where it would be valuable to be able to distinguish between tree modification (nodes entered or left) and an existing node simply being written to. Maybe a compound type, just to make it even grosser! :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
On Sat, 11 Dec 1999 14:00:03 -0800, "Jordan K. Hubbard" [EMAIL PROTECTED] said: Which raises an important issue - other than walking the sysctl tree regularly looking for changes, how does such an application become aware that the sysctl space has changed? It's listening on a kernel notification socket. (Implementation is an exercise left for the reader, but there are already a few examples.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
"Jordan K. Hubbard" wrote: In other words, it's not a problem specific to KLD's .. but it's still a problem :-) Which raises an important issue - other than walking the sysctl tree regularly looking for changes, how does such an application become aware that the sysctl space has changed? I seem to recall that John Poltstra was working on a notification system (for use with CVSup) that would allow you to subscribe to certain change events... Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Interesting read: http://www.vcnet.com/bms/ JLF To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
Linux have basically done this in their procfs. On Sat, 11 Dec 1999, Jordan K. Hubbard wrote: Use a similar hack: map the sysctl tree to the filesystem (ala kernfs) and then stat the directory nodes. AAIEE! sysctlfs!! :-) It's an interesting idea and I'm not sure why it also horrifies me at some inner, almost cellular, level. If somebody's actually willing to do the work of creating such a thing, however, I'll probably get over it. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
On Sat, 11 Dec 1999, Julian Elischer wrote: Linux have basically done this in their procfs. If we're looking for a gross hack, we need look no further :-) Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
On Thu, 9 Dec 1999, Archie Cobbs wrote: Andrzej Bialecki writes: I'd like to know whether we reached some conclusions concerning the naming of sysctl variables created (or related to) KLDs. I know that Linux emulator creates "compat.linux". I don't know if any other module creates sysctls (well, except my SPY module.. :-). So, what is the current thinking? Should we use modules.my_module.whatever, or kld.my_kld.whatever, or just sprinkle the new sysctls randomly over the tree, according to their functions, e.g. kern.my_module_kern_hook net.inet.my_module_inet_hook ... I think the latter. In 'theory' there should be no discernable difference between functionality from a KLD vs. the same functionality compiled directly into the kernel. Yes, assuming that the same functionality CAN be compiled in statically. IMHO the kernel modularity is a laudable goal, and if it works well, there are only few cases when you would want to make a monolithic kernel. IMHO, of course :-) KLD's are just a linking mechanism, and shouldn't have any more significance than that from a usability perspective. Hah. If it were so simple... Let's take the example of a module foo, which provides unique features of bar and baz. They are unrelated to any already existing category. Where they should be hooked up? kernel? machdep? Then these categories will become a messy, amorphic trashcans. Also, it will be difficult to see which sysctls will disappear when the module is unloaded. Also, if we say that modules should register their sysctls in easily discernible place in the tree, we set up a good example for third party vendors, who otherwise will sprinkle their own sysctls all over the tree... You can probably see from the above what is my preference.. ;-) More or less, my question is: how the sysctl tree will look like when _most_ of the kernel will be in modules? Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modules and sysctl tree
Andrzej Bialecki writes: I'd like to know whether we reached some conclusions concerning the naming of sysctl variables created (or related to) KLDs. I know that Linux emulator creates "compat.linux". I don't know if any other module creates sysctls (well, except my SPY module.. :-). So, what is the current thinking? Should we use modules.my_module.whatever, or kld.my_kld.whatever, or just sprinkle the new sysctls randomly over the tree, according to their functions, e.g. kern.my_module_kern_hook net.inet.my_module_inet_hook ... I think the latter. In 'theory' there should be no discernable difference between functionality from a KLD vs. the same functionality compiled directly into the kernel. KLD's are just a linking mechanism, and shouldn't have any more significance than that from a usability perspective. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
