System V portability issues

[Ed Rupp]

In article <3125 at homxc.UUCP> dwc at homxc.UUCP (Malaclypse the Elder) writes:
>i would also like to add that i believe henry is again confusing
>kernel portability with application portability.  i would like to
>know of any specific kernel portability problems that the System V
>developers have 'gratuitously' added.
>
>danny chen
>att!homxc!dwc

I'm not sure what you mean by 'gratuitously', but
off the top of my head, here are a few kernel portability issues in
the current incarnation of the UNIX(tm) source code (SVR3.2).

1) Why does os/prf.c have references to the dmd5620 terminal and nvram? 
   Couldn't the terminal code be removed?  Couldn't the details of
   manipulating the nvram be isolated instead of scattered about?

2) In the same file, why are there references to iumodem?  And really,
   why aren't the console and clock devices configurable like everything
   else?  But, then there's:

3) The whole autoboot/autoconfigure code is hopeless.  What in the
   world am I supposed to do with the files in boot and master.d?  If I try
   to implement the autoconfig stuff, I must wade through megabytes
   of machine specific code.  I know it is difficult to make this
   portable, but it would be nice.

4) Why are there a mix of routines in the sys3b() system call?  Some of 
   these are not really machine dependent (S3BSWPI,SETNAME) and some are 
   (GRNON).  Shouldn't these functions be separated more cleanly?  As it 
   stands I can't just remove os/sys3b.c.  I must examine it to find out
   what parts I really need.  There aren't any '#ifdef u3b2's around
   the machine specific pieces.

Now, who should I talk to at AT&T to get these fixed? :-)

--
Ed Rupp		cs.utexas.edu!oakhill!ed
Motorola Inc., Austin Tx