shiva@well.sf.ca.us (Kenneth Porter) (06/14/91)
While I think OS/2 can be extended in many ways to give it capabilities now shipped with Unix, one thing I don't see is the ability to easily add new drivers to the kernel so that third-party boot devices can be used. Only MS/IBM-approved boot disks are allowed, so one can't easily extend OS/2 to, say, boot over an arbitrary network or disk drive without OEM-ing OS/2 sources. It's quite common in the Unix market to add drivers to the kernel, and with Sun's SCSA for SCSI, one can add device- specific SCSI support as well. When will we see this in OS/2? Related to this is the need for a standard API for querying kernel resources. Such an API would allow a program to get the kinds of information that a user can get with the PSTAT utility. One of the posters here has reverse-engineered the system call used by PSTAT, but this shouldn't be necessary; MS/IBM should publish the specs for an approved way of instrumenting a system. OS/2 should be able to do this more cleanly than the Unix method of peeking into the memory of the running kernel using the on-disk symbol table (as is done with the ps command). I would suggest that users and programmers post here the kinds of information that such an API should provide. I would personally like to see detailed breakdowns of blocking conditions of each thread, per-process memory, pipe, queue, semaphore, and file usage. Another hassle related to booting (and shared with DOS) is the insistence on booting from the first floppy or the first hard disk (or first partition). According to information given in literature for IBM's new 486 servers, this is hard-coded into the boot code. The new servers can get around this by swapping drive addresses in the BIOS. Most Unix implementations can boot from any device built into the kernel. My 386i can boot from any of the floppy, the cartridge tape, either hard disk (any partition), or the network, and this is just the default search list. One could in principle boot from any device that can contain a file. I suppose that one could even boot over the serial port if one had the patience. If OS/2 is to be considered a serious operating system, it should have this technology. One of the biggest objections to converting to OS/2 is that one must make it the primary operating system on a machine, eliminating the possiblity of going back to DOS. This has been partly fixed by various dual-boot kludges, but the result is less than optimal. As a developer, I need to be able to freely switch among many operating environments, including DOS, OS/2 1.x and 2.x, Unix (in several flavors), and Concurrent DOS. DOS and OS/2 are notable in their hostility to co-existence with other operating environments. Ken (shiva@well.sf.ca.us)
larrys@watson.ibm.com (06/17/91)
In <25434@well.sf.ca.us>, shiva@well.sf.ca.us (Kenneth Porter) writes: > >It's quite common in the Unix market to add drivers to the >kernel, and with Sun's SCSA for SCSI, one can add device- >specific SCSI support as well. When will we see this in OS/2? Good question. >Related to this is the need for a standard API for querying >kernel resources. Such an API would allow a program to get the >kinds of information that a user can get with the PSTAT >utility. One of the posters here has reverse-engineered the >system call used by PSTAT, but this shouldn't be necessary; >MS/IBM should publish the specs for an approved way of >instrumenting a system. OS/2 should be able to do this more >cleanly than the Unix method of peeking into the memory of the >running kernel using the on-disk symbol table (as is done with >the ps command). Yes, but once IBM/Microsoft publish the spec for something like this, they become LOCKED into a nasty monster called "backward compatibility", which does NOT allow them to change things to take advantage of new technologies. This is also the reason (I found out) that the IFS spec is not published. >I would suggest that users and programmers post here the kinds >of information that such an API should provide. I would >personally like to see detailed breakdowns of blocking >conditions of each thread, per-process memory, pipe, queue, >semaphore, and file usage. So would I. Like you said, the interface for DosQProcStatus was published before and can be used with some risk that it might not be there in the future. >Another hassle related to booting (and shared with DOS) is the >insistence on booting from the first floppy or the first hard >disk (or first partition). According to information given in >literature for IBM's new 486 servers, this is hard-coded into >the boot code. The new servers can get around this by swapping >drive addresses in the BIOS. Most Unix implementations can boot >from any device built into the kernel. My 386i can boot from >any of the floppy, the cartridge tape, either hard disk (any >partition), or the network, and this is just the default search >list. One could in principle boot from any device that can >contain a file. I suppose that one could even boot over the >serial port if one had the patience. Ahem...Uhh...Well...Err... ;) >If OS/2 is to be considered a serious operating system, it >should have this technology. One of the biggest objections to >converting to OS/2 is that one must make it the primary >operating system on a machine, eliminating the possiblity of >going back to DOS. This has been partly fixed by various >dual-boot kludges, but the result is less than optimal. As a >developer, I need to be able to freely switch among many >operating environments, including DOS, OS/2 1.x and 2.x, Unix >(in several flavors), and Concurrent DOS. DOS and OS/2 are >notable in their hostility to co-existence with other operating >environments. Ken, these are good points, but (as much as I would like to) I cannot address them. I can say this: these same points have been voiced internally before and I know Boca has heard, but we will have to wait until 4Q91 to see if they listened. Cheers, Larry Salomon, Jr. (aka 'Q') LARRYS@YKTVMV.BITNET OS/2 Applications and Tools larrys@ibmman.watson.ibm.com IBM T.J. Watson Research Center larrys@eng.clemson.edu Yorktown Heights, NY Disclaimer: The statements and/or opinions stated above are strictly my own and do not reflect the views of my employer. Additionally, I have a reputation for being obnoxious, so don't take any personal attacks too seriously.