cmcmanis%pepper@Sun.COM (Chuck McManis) (04/20/88)
In article <360@midway.ece.scarolina.EDU> (Stuart Anderson) writes: > I don't intend on burning XINU into ROMs. I want to be able to load it > like any other program, except that the initialization function takes over > the machine. Ok, good. Using the existing ROMs, there is a perfectly good floppy disk driver routine in their, that can be used much like one would use a 'smart' disk controller. Realizing that you don't want to "layer" XINU on the exec library/device kernel you can indeed do it yourself. AmigaDOS is layered on this and if you could come up with a replacement for the AmigaDOS layer you might have a marketable product. But opportunity aside, the Developers Conference Notes are available from CATS for $20, (CBM, 1200 Wilson Dr, Westchester CA, 19380) and describe the way the trackdisk device talks to the floppies. >I can. I am still just investigating the possiblilty of such a project. >If many of the pieces can be found, then the amount of work is reduced. If >anybody else is interested, then the project can be divided up and the work >for any one person reduced even further. Well there are things that XINU expects (being UN*X like, like fork()) that you will have problems with (like the MINIX people). But in general OS development is pretty straight forward. Which parts of the OS are you interested in ? (A lot of people equate Systems Programming == Kernel Hacking, when in fact 80% of the 'systems' code is not in the kernel at all.) I usually break an OS in to process control, resource control, i/o subsystems, and user interface. It is simplest to pick each section and build it, and replace the Amiga equivalent. When after they are all done you have a new OS. >I have the RKM & Hardware Manual set. It is not always clear (or even correct). >I was looking for sample code from someone that has already figured it out. >I don't want to do this all by myself. I am a little wary here Stuart, learning is best accomplished by doing not by looking. I strongly encourage you to _do_ this rather than take someone elses code. You will learn just about everything you need to know about floppies in the process. >Back to XINU: I am all for re-use. I would like to use as much as possible. >I would like to implement XINU as close to it's original intentions instead of >being layered on top of something else for performance reasons. I think at this stage it is to early to guess at the performance of a layered system. From what I read in the XINU book I would guess that the Amiga's Exec is a faster and more efficient task scheduling system. >PS: If this seems like it should be in .tech, then let's migrate to there. Now it is in .tech. Maybe I can make up for following up on a Jet question here :-) --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
anderson@midway.ece.scarolina.EDU (Stuart Anderson) (04/21/88)
In article <50049@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: > >Ok, good. Using the existing ROMs, there is a perfectly good floppy disk >driver routine in their, that can be used much like one would use a 'smart' >disk controller. So, the trackdisk.device can be used to implement the lower level and the bottom half of the upper level of the disk device in XINU. >Realizing that you don't want to "layer" XINU on the >exec library/device kernel you can indeed do it yourself. Do you mean replace the exec and device drivers? Later you said: >I think at this stage it is to early to guess at the performance of a layered >system. From what I read in the XINU book I would guess that the Amiga's >Exec is a faster and more efficient task scheduling system. Are you suggesting that XINU be layered on top on the exec library? I'm confused. Maybe I'm mis-interpreting what you are saying. To implement XINU "by-the-book" would require replacing the exec (interrupt handlers and all). The exec does work well, and provides all of the parts of an OS executive (well, more or less). An implementation USING the exec would be a matter of mapping XINU system calls to exec system calls (create() -> addtask(), etc. ). If exec is used, then XINU would be layered at a very low level. Seems reasonable. Now, What about device drivers. Should the one already there be used, or should XINU provide them. The touchy point right now is that devices live as task that receive messages through the exec(,right?). How will this be affected by different conbinations of layer-levels and sub-system replacement? Will the device task be able to live under XINU? If not, does this mean that XINU must provide its own device drivers? >Well there are things that XINU expects (being UN*X like, like fork()) that >you will have problems with (like the MINIX people). XINU has a create() function for creating new processes. It does not claim to do as much as fork() and therefore doesn't have as many problems either. All it does, is create a stack and add the process to the queue. No problems with virtual memory or anything. By definition, Any non-local variable can be accessed by any process according to the rules of C. Variables that get put on the stack are private to the process. (This comes from the book). >Which parts of the OS are you >interested in ? (A lot of people equate Systems Programming == Kernel >Hacking, when in fact 80% of the 'systems' code is not in the kernel at >all.) I usually break an OS in to process control, resource control, >i/o subsystems, and user interface. It is simplest to pick each section >and build it, and replace the Amiga equivalent. When after they are >all done you have a new OS. I guess i/o subsystems has an edge over the other areas, but process control and resource control aren't far behind because they are also at the kernel level. User interfaces, lags behind right now, because it needs the others to be very useful (besides, it isn't covered until the 2nd volume of the XINU books and I don't have it yet :-) ). >I am a little wary here Stuart, learning is best accomplished by doing not >by looking. I strongly encourage you to _do_ this rather than take someone >elses code. You will learn just about everything you need to know about >floppies in the process. I agree completely. I wanted other code as extended examples to supplement the manuals. I doubt if anybody's code would do exactly what I need anyway. I would have to at least rewrite big portions of it. Yet another question to ponder: How about implementing a device that uses the graphics/keyboard hardware for a tty-like device so that the serial port doesn't have to be the only way into the system. ------------------------------------------------------------------------------ Stuart Anderson, University of South Carolina ECE Dept. anderson@ece.scarolina.edu { decwrl!decvax, duke, ecsvax, rti, uvaarpa }!mcnc!ece-csc ......\ { bbn, bloom-beacon, mcnc, purdue, rutgers, ukma }!gatech!hubcap ..\ { charsh, hplabs!hp-sdd }!ncr-sd ................................./ | | /............................................................../ | \..!ncrcae!usceast!midway!anderson