ed@oakhill.UUCP (Ed Rupp) (08/21/88)
In article <3125@homxc.UUCP> dwc@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