Re: VMware detection code in boot loader
In message [EMAIL PROTECTED] Mike Smith writes: : a larger issue. It is not the loader's job to detect the underlying : hardware configuration. : : Actually, in a broad fashion, it _is_. This is why the loader : understands PCI and PnP, for example. How hard would it be to add usb and pccard support? Very hard. There's no standardised firmware interface to either of these, so we would have to use "real" drivers. As far as the loader is concerned, though, neither of these are on the boot path, so we can typically wait until the kernel's up and we can use some "real real" drivers. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
In message [EMAIL PROTECTED] Mike Smith writes: : As far as the loader is concerned, though, neither of these are on the : boot path, so we can typically wait until the kernel's up and we can use : some "real real" drivers. 8) Well, I have seen boards that support booting off pccard devices... But I think they make them look like normal BIOS disk devices just like the DOC2k chips do. And the boot support is somewhat limited as to which devices (usually only ATA cards and sometimes linear flash). I'll not worry about it for now. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
In message [EMAIL PROTECTED] Mike Smith writes: : a larger issue. It is not the loader's job to detect the underlying : hardware configuration. : : Actually, in a broad fashion, it _is_. This is why the loader : understands PCI and PnP, for example. How hard would it be to add usb and pccard support? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
In [EMAIL PROTECTED], Luoqi Chen wrote: In [EMAIL PROTECTED], Luoqi Chen wrote: It is not the loader's job to detect the underlying hardware configuration. I disagree. I would like to tell which machine I am booting on to choose an appropriate kernel. Eventually (it may take a while) we should be able to boot any i386/AT based machine with a single kernel which dynamically loads drivers for available hardware (and different locking modules for UP and SMP for that matter). I have such a kernel for all my machines except SMP. However, I still boot different UP kernels on each machines for testing purposes: - different 'cpu I..._CPU' settings - different floating emulators - much or few RAM I don't want to detect all hardware, what I need is one way to tell each machine from each other, like a hostid. The ethernet address of the first card could be. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
In [EMAIL PROTECTED], Luoqi Chen wrote: It is not the loader's job to detect the underlying hardware configuration. I disagree. I would like to tell which machine I am booting on to choose an appropriate kernel. Eventually (it may take a while) we should be able to boot any i386/AT based machine with a single kernel which dynamically loads drivers for available hardware (and different locking modules for UP and SMP for that matter). My -current harddisk (physically) moves between 3 machines with very different requirements, not just SMP. FPU, few or much RAM, ISA stuff on identical places etc. I can select the kernel manually, but after a crash or power fail I might not be in a position to do it again. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Given the way VMware works, I'd have nothing against making it a FICL words, except... ...VMware is a port. For some reason, I dislike the idea of having support targetted at exclusively one specific port. Though we have features added specifically to deal with certain ports, they were all more generic features. I'm quite reluctant to add the ficl word myself. Ideally, we should not need to know which platform we're running on, be it a dell, a gateway or a software emulation like vmware. The problem is our inability to have a single kernel to boot an UP and a SMP machine, once we've solved this problem, I would remove this ficl word. I see this as a temporary solution to a specific problem, I don't want to generalize this into a larger issue. It is not the loader's job to detect the underlying hardware configuration. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
a larger issue. It is not the loader's job to detect the underlying hardware configuration. Actually, in a broad fashion, it _is_. This is why the loader understands PCI and PnP, for example. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
a larger issue. It is not the loader's job to detect the underlying hardware configuration. Actually, in a broad fashion, it _is_. This is why the loader understands PCI and PnP, for example. Why do we want to do that? Are we going to offload device probe routines to the loader? I thought the loader only needs to understand bootable devices, and it's the kernel's responsibility to handle the rest. It's hard to decide where to draw the line, and hard to decide what is or isn't part of the boot path. The simplest answer is just to have the loader load drivers for everything that it can find, which is the path that we've been walking down. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Mike Smith wrote: VMware intercepts the inb/outb instruction to port 0x5658 when the eax register is set to a magic value, otherwise it would be handled as any other ports. I think, again, that adding an i386-specific word that detects the presence of VMware is a perfectly sensible idea, and it should simply be done. Given the way VMware works, I'd have nothing against making it a FICL words, except... ...VMware is a port. For some reason, I dislike the idea of having support targetted at exclusively one specific port. Though we have features added specifically to deal with certain ports, they were all more generic features. So, I see two alternatives here: 1) Add the Forth words that allow execution of assembler code (CODE ;CODE), and hex-compile the code (as having a whole assembler around is unreasonable). This enables similar problems to be solved without having to change loader(8). 2) Add the VMware detecting to FICL, as originally suggested. While I have reservations about the latter, I'm not objecting to it. If you, Luoqi, prefer to go that way, go ahead. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Mike Smith wrote: VMware intercepts the inb/outb instruction to port 0x5658 when the eax register is set to a magic value, otherwise it would be handled as any other ports. I think, again, that adding an i386-specific word that detects the presence of VMware is a perfectly sensible idea, and it should simply be done. Given the way VMware works, I'd have nothing against making it a FICL words, except... ...VMware is a port. For some reason, I dislike the idea of having support targetted at exclusively one specific port. Though we have features added specifically to deal with certain ports, they were all more generic features. So, I see two alternatives here: 1) Add the Forth words that allow execution of assembler code (CODE ;CODE), and hex-compile the code (as having a whole assembler around is unreasonable). This enables similar problems to be solved without having to change loader(8). 2) Add the VMware detecting to FICL, as originally suggested. or 3) add inw and outw Forth words, and make the VMWARE specific stuff just new words defined in Forth. Perhaps this doesn't preclude having to do 1) for some future problem, but it could delay it somewhat. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
"Daniel C. Sobral" wrote: Mike Smith wrote: VMware intercepts the inb/outb instruction to port 0x5658 when the eax register is set to a magic value, otherwise it would be handled as any other ports. I think, again, that adding an i386-specific word that detects the presence of VMware is a perfectly sensible idea, and it should simply be done. Given the way VMware works, I'd have nothing against making it a FICL words, except... ...VMware is a port. For some reason, I dislike the idea of having support targetted at exclusively one specific port. Though we have features added specifically to deal with certain ports, they were all more generic features. So, I see two alternatives here: 1) Add the Forth words that allow execution of assembler code (CODE ;CODE), and hex-compile the code (as having a whole assembler around is unreasonable). This enables similar problems to be solved without having to change loader(8). 2) Add the VMware detecting to FICL, as originally suggested. While I have reservations about the latter, I'm not objecting to it. If you, Luoqi, prefer to go that way, go ahead. Why make #2 vmware specific? Why not set $emulation to native,vmware,bochs, etc. This is applicable to any platform that may have some sort of emulator. Putting it in an environment variable has the advantage of having it passed through to the kernel environment too, so you might be able to use it in /etc/rc* as well. 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-current" in the body of the message
Re: VMware detection code in boot loader
Mike Smith wrote: VMware intercepts the inb/outb instruction to port 0x5658 when the eax register is set to a magic value, otherwise it would be handled as any other ports. I think, again, that adding an i386-specific word that detects the presence of VMware is a perfectly sensible idea, and it should simply be done. Given the way VMware works, I'd have nothing against making it a FICL words, except... ...VMware is a port. For some reason, I dislike the idea of having support targetted at exclusively one specific port. Though we have features added specifically to deal with certain ports, they were all more generic features. It's not a port, it's a platform. We probably want to add extra words to detect other platform features, eg. i386, alpha, ia64, etc. but that doesn't invalidate the basic idea. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Peter Wemm wrote: 2) Add the VMware detecting to FICL, as originally suggested. Why make #2 vmware specific? Why not set $emulation to native,vmware,bochs, etc. This is applicable to any platform that may have some sort of emulator. Putting it in an environment variable has the advantage of having it passed through to the kernel environment too, so you might be able to use it in /etc/rc* as well. It wouldn't change the matter of having port-specific code on loader. It is really irrelevant whether that code will be setting an environment variable or returning flag/version. Forth code executed at run-time is an extension of loader. It can call various flag-returning words and set an environment variable accordingly. The only difference is that having C code set the environment variable let us get away from using FICL, but, then, the utility of it is _only_ passing it to the kernel environment, as loader(8) without FICL can do very little based on the content of an environment variable. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Mike Smith wrote: ...VMware is a port. For some reason, I dislike the idea of having support targetted at exclusively one specific port. Though we have features added specifically to deal with certain ports, they were all more generic features. It's not a port, it's a platform. We probably want to add extra words to detect other platform features, eg. i386, alpha, ia64, etc. but that doesn't invalidate the basic idea. Huh... duh! Of course! In this case, I object to the way the word works. We *do* "detect" i386 and alpha. The code ought to do something similar to what the i386 and alpha words do. That would make sense. Note that 'vmware' is a subset of 'i386' for whatever that's worth. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
At 10:47 AM -0700 6/11/00, Mike Smith wrote: It's not a port, it's a platform. We probably want to add extra words to detect other platform features, eg. i386, alpha, ia64, etc. but that doesn't invalidate the basic idea. For instance, I might be running the vmware program itself under linux, and thus I am doing nothing with a "freebsd port" of vmware. At system startup, vmware is just a (virtual) hardware platform that the OS might want to be aware of. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
We have inb and outb. Can't vmware be written in Forth? If inl cannot be replaced with inb, I'd rather add inl than vmware. But we can't set registers to specific values before inb/outb, which also means our inb/outb are quite useless in making BIOS calls. IMHO, it would be better to add exec="include /boot/vmware.4th" to the end of your /boot/loader.conf, and either execute vmware-conf from there or script the whole thing: s" arch-i386" environment? [if] \ Get vmware version, magic 0x564d868 ( VMware magic ) = [if] .( VMware version ) . cr .( Loading /boot/vmware.conf...) cr s" /boot/vmware.conf" read-conf [else] drop [then] [then] Either way, no changes to /boot/loader.rc would be required. This looks much better, I didn't know we could tell the loader to execute a script in loader.conf. -- Daniel C. Sobral (8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Hmmm - I have to go check this. My reality assumptions are shattered. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
As for setting registers ti specific values... huh? Why does this matter? Can you explain exactly what your code does and how? VMware intercepts the inb/outb instruction to port 0x5658 when the eax register is set to a magic value, otherwise it would be handled as any other ports. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
As for setting registers ti specific values... huh? Why does this matter? Can you explain exactly what your code does and how? VMware intercepts the inb/outb instruction to port 0x5658 when the eax register is set to a magic value, otherwise it would be handled as any other ports. I think, again, that adding an i386-specific word that detects the presence of VMware is a perfectly sensible idea, and it should simply be done. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Would anyone object if I add a ficl word to detect whether we're booting from a vmware virtual machine? Sounds good to me! -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Luoqi Chen wrote: Would anyone object if I add a ficl word to detect whether we're booting from a vmware virtual machine? I find it extremely useful when I'm running FreeBSD as a guest under NT. Because it is a dual cpu box, I can't use a single kernel to boot both directly or inside the virtual machine. With this new word, I can determine which kernel to use in the loader script, saving me the trouble to unload and reload a new kernel each time I reboot. Here's the patch to the boot loader, Index: boot/ficl/ficl.h === RCS file: /home/ncvs/src/sys/boot/ficl/ficl.h,v retrieving revision 1.14 diff -u -r1.14 ficl.h --- boot/ficl/ficl.h2000/06/01 18:10:43 1.14 +++ boot/ficl/ficl.h2000/06/07 18:18:38 @@ -860,6 +860,7 @@ #if defined(__i386__) !defined(TESTMAIN) extern void ficlOutb(FICL_VM *pVM); extern void ficlInb(FICL_VM *pVM); +extern void vmware(FICL_VM *pVM); I'm not sure it is a good idea to name this variable VMWare as that is implementation specific. It may be better to have a var named 'emulation' set to 'none' or 'vmware' or 'bochs' or ... Just my EC 0.02, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
On Fri, Jun 09, 2000 at 01:14:35PM -0400, Jeroen C. van Gelderen wrote: I'm not sure it is a good idea to name this variable VMWare as that is implementation specific. It may be better to have a var named 'emulation' set to 'none' or 'vmware' or 'bochs' or ... Mmm.. or, giving forth the ability to do in/out instructions, so the non-generic code would be entirely in the add-on forth piece. I'm not sure if there are any security implications there.. at boot time the machine is essentially as single-user as it's ever going to be. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
extern void ficlOutb(FICL_VM *pVM); extern void ficlInb(FICL_VM *pVM); I'm an idiot. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Christopher Masto wrote: On Fri, Jun 09, 2000 at 01:14:35PM -0400, Jeroen C. van Gelderen wrote: I'm not sure it is a good idea to name this variable VMWare as that is implementation specific. It may be better to have a var named 'emulation' set to 'none' or 'vmware' or 'bochs' or ... Mmm.. or, giving forth the ability to do in/out instructions, so the non-generic code would be entirely in the add-on forth piece. I'm not sure if there are any security implications there.. at boot time the machine is essentially as single-user as it's ever going to be. I prefer 'emulation' being set to 'native', 'vmware' etc. Consider that there is IA64, Alpha, sparc, ppc etc to deal with. Teaching the ficl scripts to do inb/outb would be bad. It would be much better to have a generic mechanism for informing the loader about possible emulation environments, eg you are using the IA64 emulator under an x86 box, or an x86 emulator on an Alpha, or an Alpha SIMOS emulation under x86, or whatever. 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-current" in the body of the message
Re: VMware detection code in boot loader
Peter Wemm wrote: Christopher Masto wrote: On Fri, Jun 09, 2000 at 01:14:35PM -0400, Jeroen C. van Gelderen wrote: I'm not sure it is a good idea to name this variable VMWare as that is implementation specific. It may be better to have a var named 'emulation' set to 'none' or 'vmware' or 'bochs' or ... Mmm.. or, giving forth the ability to do in/out instructions, so the non-generic code would be entirely in the add-on forth piece. I'm not sure if there are any security implications there.. at boot time the machine is essentially as single-user as it's ever going to be. I prefer 'emulation' being set to 'native', 'vmware' etc. Consider that there is IA64, Alpha, sparc, ppc etc to deal with. Teaching the ficl scripts to do inb/outb would be bad. It would be much better to have a generic mechanism for informing the loader about possible emulation environments, eg you are using the IA64 emulator under an x86 box, or an x86 emulator on an Alpha, or an Alpha SIMOS emulation under x86, or whatever. Rethinking, emulation may not be the best suggestion. People might confuse it with Linux emulation. How about 'hardware' ? or 'platform' or your suggestion here ? Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Luoqi Chen wrote: Would anyone object if I add a ficl word to detect whether we're booting from a vmware virtual machine? I find it extremely useful when I'm running FreeBSD as a guest under NT. Because it is a dual cpu box, I can't use a single kernel to boot both directly or inside the virtual machine. With this new word, I can determine which kernel to use in the loader script, saving me the trouble to unload and reload a new kernel each time I reboot. Here's the patch to the boot loader, --- boot/ficl/ficl.h2000/06/01 18:10:43 1.14 +++ boot/ficl/ficl.h2000/06/07 18:18:38 @@ -860,6 +860,7 @@ #if defined(__i386__) !defined(TESTMAIN) extern void ficlOutb(FICL_VM *pVM); extern void ficlInb(FICL_VM *pVM); ^^^ +extern void vmware(FICL_VM *pVM); We have inb and outb. Can't vmware be written in Forth? If inl cannot be replaced with inb, I'd rather add inl than vmware. To use this feature, you first create a file /boot/vmware.4th: : vmware-conf vmware dup 0 if ." VMware version " . cr ." Loading /boot/vmware.conf..." cr s" /boot/vmware.conf" read-conf else drop then ; then create /boot/vmware.conf which sets the kernel to use: kernel="/kernel.VMWARE" finally, change your /boot/loader.rc to include /boot/loader.4th include /boot/vmware.4th initialize drop vmware-conf boot-conf check-password IMHO, it would be better to add exec="include /boot/vmware.4th" to the end of your /boot/loader.conf, and either execute vmware-conf from there or script the whole thing: s" arch-i386" environment? [if] \ Get vmware version, magic 0x564d868 ( VMware magic ) = [if] .( VMware version ) . cr .( Loading /boot/vmware.conf...) cr s" /boot/vmware.conf" read-conf [else] drop [then] [then] Either way, no changes to /boot/loader.rc would be required. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Hmmm - I have to go check this. My reality assumptions are shattered. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
