[comp.os.os2.misc] Deficiencies in the OS/2 kernel

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.