Re: "Next Generation" kernel configuration?
Hi, re, "Next Generation" kernel configuration: Years ago I had a job for a few years where I constantly built RSX-11 systems on PDP-11s. RSX-11 was always built from source and had a couple of hundred build-time options, many hardware build dependencies, and supported numerous other dynamic build-time functions; it was said that it was possible that no 2 RSX systems were really the same binaries. It may have been more combinatorially complex than FreeBSD. An RSX build could easily take a day. Although at the core the build was driven by a file of assembly macro defines, conceptually not unlike FreeBSD, the build process went through continuous evolution over the life of RSX. A comprehensive "sysgen.bat" script, or somesuch, evolved. Sysgen (which was a common industry term at the time) was a very large script that was intended to be run on a fast hard-copy decwriter; it printed out lists of possibilities and then asked you a question, you made a selection from the options, and so on. It conducted a 'scripted dialog' that reflected the options you made along the way. You wanted this on hard copy so you could go back and check things, keep it for next time, and so on. You could go back in the dialog and repeat a section, save the sysgen state and restart later, and so on. A sysgen dialog could easily take half-a-day (sometimes intermediate things had to be built and such), and then the build itself and install could take a number of hours... At the end of the sysgen dialog you could "save the session", basically, and then the next time you did a session you could ask to use the saved session and essentially conduct a "modification dialog". Working with sysgen often felt like taking part in an adventure game with an AI opponent; you had to know how to outsmart the script to get it to do exactly what you wanted. This might be a common failing of many pseudo AI type programs. On the one had this all worked and worked well. On the other hand if you can do it by simply editing flat files it's much better, because you don't have to become an expert on the sysgen script just to do a build. Back on the other hand, there may be a point of complexity (and lack of corresponding widespread sophistication) where a sysgen program is necessary. SO: If a sysgen-like program was built for FreeBSD that used a conversational, graphic, menu, or whatever interface, instead of actually doing anything to real files or the real system, could it just print out _what to do_, that is, it would output a list of instructions - in such-and-such a file, edit this option, then add this line... Or perhaps it would output diffs to files... or put the output in a "candidate" location. But in any case the program would be a SYSGEN ASSISTANT, not an actual sysgen program. Basically a "kernel config checker", a smart build-lint, etc.. It could live in ports. If this program got to where it really worked, everyone liked the interface, and the system complexity was clearly at the point where it was needed, it could be used to directly generate system configurations. The dependency-rule evaluation and output part could be built independent of any user-interface, so a front-end back-end scheme might make sense. In any case, googling on "RSX sysgen" might produce some ideas of interest. BTW, I'm under the impression that for quite some time the largest rule-based AI application ("real-time expert system") in the world was the OPS5 system implemented at DEC to configure VAX hardware, see links such as: http://encyclopedia.thefreedictionary.com/OPS5%20rule%20based It looks like there's a public domain system that compiles rules to C code, perhaps there are some interesting ideas there as well for things like general dependency rule evaluation in the backend and such: http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/expert/systems/ops5/0.html Sorry to go on at length. - bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "Next Generation" kernel configuration?
In message: <[EMAIL PROTECTED]> Murray Taylor <[EMAIL PROTECTED]> writes: : As an initial starting point for 'preloading' any menubased kernel : configurator, could the file /var/run/dmesg.boot be usefully parsed as : a list of 'this is what is actually installed in this box, what else do : you want to add?" Of course any output developed on a run of the : configurator would/could/should be scanned as well to include answers to : the question.."What did I include last time?" if devd could map, somehow, the pnp info into drivers to load, that would solve this problem. warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "Next Generation" kernel configuration?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 21 July 2004 01:00 pm, Andrew Konstantinov wrote: > On Wed, Jul 21, 2004 at 05:43:45AM -0700, Avleen Vig wrote: > > On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote: > > > Just musing on an idea here: > > > > > > I've been thinking for a while now about trying to write a tool to make > > > kernel configuration easier, sort of a "make config" (as in ports) for > > > the kernel, similar to what's available on some of the Linux distros. > > > > I've read over the other posts in this thread, but I cannot say I think > > this is a good idea. In fact, I think it's a very bad idea, but with > > very good intentions. Here's why.. > > > > I'm a strong proponent of user education. The FreeBSD handbook is one of > > the best education tools for someone who wants to use FreeBSD, right > > from beginner to more advanced levels. > > > > A "config tool", while useful for beginners, would quickly result is > > those beginners not learning about building a kernel themselves, copying > > GENERIC to `hostname -s | tr "[:lower:]" "[:upper:]"`, editing it, > > learning what is in LINT, remembering to look through there, etc. > > This process teaches users a lot about how a BSD kernel is configured, > > what options are availible, and where to look for more options. > > > > The end result would be more people building kernels themselves, but not > > knowing what is actually happening, or what more is possible. It would > > mean less educated users, and I don't think that is somewhere any > > organization needs to go (look at what happened to the average Microsoft > > user's IQ level, after people stopped using DOS and started having > > machines do the work for them). > > > > Like I said, I think your intentions are good, but I have concerns about > > the suggested solution. > > I think such a tool would actually influence user education in a positive > way. Here is a sample scenario: > > 1) User starts this "program" to configure the kernel > 2) User sees unknown to him option > 3) User decides to look it up on www.google.com > 4) "That's a nice feature, although I don't really need it" > 5) GOTO 1 > > The only suggestion I have is to make it a third party program and not > build it into the make procedure for the kernel. It would look like > pkg_tree that's located in ports, although with a better ncurses interface. > > Andrew I think a tool with the functionality described in the original post would be very nice, but it shouldn't be menu driven etc. Something more like a kernel dependency checker that would take the kernel config file, and check that all the dependencies are correct. ie. for umass you need da, but if you forget you'll only get a cryptic failing of the kernel build. Also for things like bktr, which you need to have iic and friends. Something along the lines of a command line "make depend-check" before you do a make kernel would be nice. - -- Anish Mistry -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA/qc/xqA5ziudZT0RAhLQAJ9HvvtFjmvOkP7hCX4nNR4LGbeMmACgr4vi gQGqNJyVysUTFlisDYohF+8= =gXI8 -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "Next Generation" kernel configuration?
On Wed, Jul 21, 2004 at 05:43:45AM -0700, Avleen Vig wrote: > On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote: > > Just musing on an idea here: > > > > I've been thinking for a while now about trying to write a tool to make > > kernel configuration easier, sort of a "make config" (as in ports) for > > the kernel, similar to what's available on some of the Linux distros. > > I've read over the other posts in this thread, but I cannot say I think > this is a good idea. In fact, I think it's a very bad idea, but with > very good intentions. Here's why.. > > I'm a strong proponent of user education. The FreeBSD handbook is one of > the best education tools for someone who wants to use FreeBSD, right > from beginner to more advanced levels. > > A "config tool", while useful for beginners, would quickly result is > those beginners not learning about building a kernel themselves, copying > GENERIC to `hostname -s | tr "[:lower:]" "[:upper:]"`, editing it, > learning what is in LINT, remembering to look through there, etc. > This process teaches users a lot about how a BSD kernel is configured, > what options are availible, and where to look for more options. > > The end result would be more people building kernels themselves, but not > knowing what is actually happening, or what more is possible. It would > mean less educated users, and I don't think that is somewhere any > organization needs to go (look at what happened to the average Microsoft > user's IQ level, after people stopped using DOS and started having > machines do the work for them). > > Like I said, I think your intentions are good, but I have concerns about > the suggested solution. I think such a tool would actually influence user education in a positive way. Here is a sample scenario: 1) User starts this "program" to configure the kernel 2) User sees unknown to him option 3) User decides to look it up on www.google.com 4) "That's a nice feature, although I don't really need it" 5) GOTO 1 The only suggestion I have is to make it a third party program and not build it into the make procedure for the kernel. It would look like pkg_tree that's located in ports, although with a better ncurses interface. Andrew pgpk6G5xAzfJR.pgp Description: PGP signature
Re: Getting a fully-qualified path from a PID
In the last episode (Jul 20), Joe Marcus Clarke said: > What is the canonical way for a userland application to get the > fully-qualified path of an executable from its running PID? I know I > can do a readlink(2) on /proc/pid/file, but procfs is deprecated on > 5.X, correct? Is there a more appropriate way to do this? Thanks. realpath(argv[0]) works for commands not run from $PATH. Commands found through a PATH earch will just have the basename in argv[0] so you would have to check each PATH element until you found it. Note that /proc/pid/file won't work if vn_fullpath() fails (say the orignal file has been unlinked, or the filename has expired from the kernel's cache). If you are examining another process, you can use the kvm_getargv() and kvm_getenvv() functions to fetch argv[0] and PATH out of the target process. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "Next Generation" kernel configuration?
Avleen Vig wrote: On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote: Just musing on an idea here: I've been thinking for a while now about trying to write a tool to make kernel configuration easier, sort of a "make config" (as in ports) for the kernel, similar to what's available on some of the Linux distros. I've read over the other posts in this thread, but I cannot say I think this is a good idea. In fact, I think it's a very bad idea, but with very good intentions. Here's why.. I'm a strong proponent of user education. The FreeBSD handbook is one of the best education tools for someone who wants to use FreeBSD, right from beginner to more advanced levels. A "config tool", while useful for beginners, would quickly result is those beginners not learning about building a kernel themselves, copying GENERIC to `hostname -s | tr "[:lower:]" "[:upper:]"`, editing it, learning what is in LINT, remembering to look through there, etc. This process teaches users a lot about how a BSD kernel is configured, what options are availible, and where to look for more options. The end result would be more people building kernels themselves, but not knowing what is actually happening, or what more is possible. It would mean less educated users, and I don't think that is somewhere any organization needs to go (look at what happened to the average Microsoft user's IQ level, after people stopped using DOS and started having machines do the work for them). Like I said, I think your intentions are good, but I have concerns about the suggested solution. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" I wholly disagree. I think using an excuse ``people will let everything else do the work for them and nobody will ever learn'' to discourage the development of automation tools is very poor. Try applying that argument to any utility that you use. You'd have to write your own bloody operating system because ``learning's in your best interest''. I'm sure this will become another bikeshed, so I suggest whoever came up with the idea to put up or shut up. People are interested in solutions, not suggestions. --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "Next Generation" kernel configuration?
On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote: > Just musing on an idea here: > > I've been thinking for a while now about trying to write a tool to make > kernel configuration easier, sort of a "make config" (as in ports) for > the kernel, similar to what's available on some of the Linux distros. I've read over the other posts in this thread, but I cannot say I think this is a good idea. In fact, I think it's a very bad idea, but with very good intentions. Here's why.. I'm a strong proponent of user education. The FreeBSD handbook is one of the best education tools for someone who wants to use FreeBSD, right from beginner to more advanced levels. A "config tool", while useful for beginners, would quickly result is those beginners not learning about building a kernel themselves, copying GENERIC to `hostname -s | tr "[:lower:]" "[:upper:]"`, editing it, learning what is in LINT, remembering to look through there, etc. This process teaches users a lot about how a BSD kernel is configured, what options are availible, and where to look for more options. The end result would be more people building kernels themselves, but not knowing what is actually happening, or what more is possible. It would mean less educated users, and I don't think that is somewhere any organization needs to go (look at what happened to the average Microsoft user's IQ level, after people stopped using DOS and started having machines do the work for them). Like I said, I think your intentions are good, but I have concerns about the suggested solution. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Getting a fully-qualified path from a PID
What is the canonical way for a userland application to get the fully-qualified path of an executable from its running PID? I know I can do a readlink(2) on /proc/pid/file, but procfs is deprecated on 5.X, correct? Is there a more appropriate way to do this? Thanks. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Re: "Next Generation" kernel configuration?
On Wed, 2004-07-21 at 11:53, Conrad J. Sabatier wrote: > On 21-Jul-2004 Max Laier wrote: > > On Wednesday 21 July 2004 03:03, Brooks Davis wrote: > >> On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote: > [snip] > >> > A dependable tool offering a menu-driven means of configuring the > >> > kernel, ensuring proper config file syntax, dependency handling, > >> > prevention of incompatible options, etc. -- as well as online > >> > documentation, advice, suggestions and warnings, plus perhaps a > >> > nice set of default selections -- would be a very nice addition to > >> > the system. But to bring it about, obviously a major reworking of > >> > the current system of kernel configuration files would be required. > >> > >> You can have my simple flat file kernel config when you pry it from > >> my cold, dead hands and I know a number of other develoeprs share > >> this viewpoint. All my experiences with the linux visual kernel > >> config tool have been annoying and I've got friends with more > >> expierence with it that have much less kind things to say. > > > > Add me to the list. And this realates to sys/conf/* as well > > (respondig to the re-reply). Especially developers prefer *clean*, > > *simple* config files and I (personally) would really really hate to > > twiddle with some insane XML just to add something to the build! > > Oh, agreed, definitely. Wasn't even thinking XML (yuck!). :-) > > Basically, I'm just thinking of a layout which, in the simplest, > cleanest manner possible, would allow a "make config"-like tool to > extract the information it needed, so options could be presented to > the user along with their descriptions, if so desired. I don't have a > clear-cut idea just yet of how this might be done, to be honest. :-) > > >> That said, so long as it doesn't impose too much developer burden, > >> an improved set of backend files that did a better job of handling > >> dependencies and knew which options where relevent given the > >> configured set of devices could be useful. > > > > http://www.freebsd.org/releases/5.3R/todo.html has a "Desired > > features"-item saying: "Revised kld build infrastructure", which > > will pretty much interfere with this. You might want to contact with > > the current owner (peter@) and hear what he has to say. > > Thanks for the pointer. I'll check into that. > > > Other than that, I'd welcome a somewhat enriched config > > environment as long as it is done reasonable and makes the job > > easier! And please: NO XML! > > Cool. And not to worry. No XML. :-) > > >> There is a valid question of what a depenency means. For instance, > >> you can't really have IP networking without lo(4) (there's a null > >> pointer derefrence if you try), but since you can load it as a > >> module, should you have to compile it in? > > > > There should be levels of dependencies ... i.e. the TBD config-tool > > would (strongly) suggest that you build-in lo(4) into an "options > > INET" kernel, but should not stop you to do else. > > Exactly. That's the sort of thing I had in mind. > > I realize this is a fairly large undertaking, and hearing that others > have already made attempts but have yet to produce anything makes me a > little uncertain about it all, but I do think it's something worth > exploring. And it'll keep me off the streets and out of trouble for a > good while, too. :-) > > If I manage to come up with anything reasonable, you'll hear about it > here. As an initial starting point for 'preloading' any menubased kernel configurator, could the file /var/run/dmesg.boot be usefully parsed as a list of 'this is what is actually installed in this box, what else do you want to add?" Of course any output developed on a run of the configurator would/could/should be scanned as well to include answers to the question.."What did I include last time?" 0.02c -- Murray Taylor Special Projects Engineer - Bytecraft Systems & Entertainment P: +61 3 8710 2555 F: +61 3 8710 2599 D: +61 3 9238 4275 M: +61 417 319 256 E: [EMAIL PROTECTED] or visit us on the web http://www.bytecraftsystems.com http://www.bytecraftentertainment.com --- The information transmitted in this e-mail is for the exclusive use of the intended addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. E-mails may not be secure, may contain computer viruses and may be corrupted in transmission. Please carefully check this e-mail (and any attachment) accordingly. No warranties are given and no liability is accepted for any loss or damage caused by such matters