pezely@cis.udel.edu (Daniel Pezely) (10/15/90)
ast@cs.vu.nl (Andy Tanenbaum) wrote: >... What I'm working on now is POSIX. I am not terribly interested >in adding new features to the kernel, FS, or MM, although I am less hostile >to utility programs since they don't get in the way at least. How about creating/supporting HOOKS for others to implement alternative features? Would you object to that much? I'd like to see, and I intend to help in the effort, that Minix is everything that it is today -- a teaching tool -- and that Minix will be a powerful enough system for those who need it. If such an alternative system evolved, would you support it or would you include it with your distribution system? -Cowboy Dan -- R+D Cowboys: HITL, Seattle CSL, U Delaware Pezely@hitl.VRnet.washington.edu Pezely@udel.edu
pezely@cis.udel.edu (Daniel Pezely) (10/16/90)
>From: Andy Tanenbaum <ast@cs.vu.nl> >Subject: Re: Where is MINIX headed? > >We have gone through this before. It is just not technically feasible. >The "hook" for virtual memory or shared text or most other proposals >is pages of code all over the place. This kind of "hook" makes the code >incomprehensible for the students. > >My idea of a hook consist of 3 lines of code: > >#ifdef FEATURE_3274 > run_virtual_memory_code(); >#endif > >If that were possible, I would not mind. It's just not possible. I do understand what you're saying, but what about the students who want to learn about more advanced features of a high performance os? Oh yes, I keep forgetting that nothing really useful is taught in school and such things are learned independently or on-the-job. :-) Anyone care to change that? Andy, you have a good os book for undergrads. Now, as an encore, how about a book for the grad student level? But I'm sure you've been asked this many times before... -cowboy dan -- R+D Cowboys: HITL, Seattle CSL, U Delaware Pezely@hitl.VRnet.washington.edu Pezely@udel.edu
ast@cs.vu.nl (Andy Tanenbaum) (10/16/90)
In article <33437@nigel.ee.udel.edu> pezely@cis.udel.edu (Daniel Pezely) writes: >How about creating/supporting HOOKS for others to implement >alternative features? Would you object to that much? If the hooks are of the form: #ifdef FEATURE_3275a execute_virual_memory_code(); #endif I might say ok. The problem is that hooks have little feelers all over the place, making the code harder to understand. My students would not approve. Andy Tanenbaum (ast@cs.vu.nl)
ast@cs.vu.nl (Andy Tanenbaum) (10/16/90)
In article <33514@nigel.ee.udel.edu> pezely@cis.udel.edu (Daniel Pezely) writes: >I do understand what you're saying, but what about the students who >want to learn about more advanced features of a high performance os? Let them read Hwang & Briggs books. All 800+ pages of it, and small letters. Andy Tanenbaum (ast@cs.vu.nl)
burgess%creek.decnet@hsdp1.brooks.af.mil (CREEK::BURGESS) (10/16/90)
In Mon, 15 Oct 90 17:21:40 GMT, Daniel Pezely <pezely@CIS.UDEL.EDU> writes: >>From: Andy Tanenbaum <ast@cs.vu.nl> >>Subject: Re: Where is MINIX headed? >> >>We have gone through this before. It is just not technically feasible. >>The "hook" for virtual memory or shared text or most other proposals >>is pages of code all over the place. This kind of "hook" makes the code >>incomprehensible for the students. >>My idea of a hook consist of 3 lines of code: >I do understand what you're saying, but what about the students who >want to learn about more advanced features of a high performance os? (lines deleted...) >Andy, you have a good os book for undergrads. Now, as an encore, how >about a book for the grad student level? >But I'm sure you've been asked this many times before... >-cowboy dan Hear, hear... Dave Burgess
feustel@netcom.UUCP (David Feustel) (10/17/90)
Hwang & Briggs books. All 800+ pages of it, and small letters. Can anyone provide the titles? -- David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631
pezely@cis.udel.edu (Cowboy Dan) (10/18/90)
cdh1@eds1.UUCP (C. Daniel Hassell) writes: >>Let them read Hwang & Briggs books. All 800+ pages of it, and small letters. > >I think Andy has a point here. What we have is a clash of intentions. >... >Minix was designed to be changed by users so I don't see why we can't >work together on it. We could develop a consensus list of features >we want to work toward, and see what happens. >... >What does anyone think? Sure thing. I'll work on BSD fast file systems for 16bit (PC/AT) MFM disk controllers and then for the Adaptec SCSI controller. I'll let you know later what the delivery dates will be like. -Cowboy Dan -- R+D Cowboys: HITL, Seattle CSL, U Delaware Pezely@hitl.VRnet.washington.edu Pezely@udel.edu
busch@arisia.Xerox.COM (Richard Busch) (10/18/90)
In article <14987@netcom.UUCP> feustel@netcom.UUCP (David Feustel) writes: > >>Hwang & Briggs books. All 800+ pages of it, and small letters. > >Can anyone provide the titles? For those interested, here is a bibliographic citation for the Hwang and Briggs book recently referenced by Dr. Tanenbaum: -> find pa hwang and briggs The MELVYL system is working on your request... Search request: FIND PA HWANG AND BRIGGS Search result: 1 record at all libraries 1. Hwang, Kai. Computer architecture and parallel processing / Kai Hwang, Faye A. Briggs. New York : McGraw-Hill, c1984. Series title: McGraw-Hill series in computer organization and architecture. UCSD S & E QA76.9.A73 H88 1984 ============================================================================ Richard Busch Xerox Corporation busch.sd@xerox.com ============================================================================
rwa@cs.athabascau.ca (Ross Alexander) (10/18/90)
pezely@cis.udel.edu (Cowboy Dan) writes: >Sure thing. I'll work on BSD fast file systems for 16bit (PC/AT) MFM >disk controllers and then for the Adaptec SCSI controller. Huh? The MFM and SCSI disk drivers are already written, to the best of my knowledge. The FFS doesn't rely on the underlying hardware for anything other than storing the bits :-) [an aside: well, of course it assumes quite a bit about geometry (tracks, cylinders, heads, rotational delays, chained reads/writes, & c. & c.) but this doesn't mean the code varies as a function of SCSI / MFM / RLL / IDE / ESDI / SMD / IPI / what-have-you, just that a well designed implementation won't choke in the face of these variations]. What we have here is a statement of intent to commit layering violation(s). Please don't do it. This is not to say that a FFS isn't welcome. Au contrare', it's massively desirable (at least by myself). Please let us know how you're making out, it's an excellent project. Thanks for starting work. -- -- Ross Alexander rwa@cs.athabascau.ca (403) 675 6311 ve6pdq
hp@vmars.tuwien.ac.at (Peter Holzer) (10/18/90)
pezely@cis.udel.edu (Cowboy Dan) writes: >cdh1@eds1.UUCP (C. Daniel Hassell) writes: >>I think Andy has a point here. What we have is a clash of intentions. >>... >>Minix was designed to be changed by users so I don't see why we can't >>work together on it. We could develop a consensus list of features >>we want to work toward, and see what happens. >>... >>What does anyone think? Yes, I think this would be the best solution. It is happening even now... People are writing versions for the 386, SPARC, etc and impementing features independently from Andy. >Sure thing. I'll work on BSD fast file systems for 16bit (PC/AT) MFM >disk controllers and then for the Adaptec SCSI controller. >I'll let you know later what the delivery dates will be like. I got this idea of a multiple server file system spooking around in my head for some time: Requests to open a file are sent to a FS dispatcher which determines the type of the file system (Minix 1.x, DOS, UNIX, Minix 2.x, BSD, Bullet ...) and passes the request to the right server. All other requests for operations on that file are sent directly to the server. As soon as I get 1.5 (I've been waiting now for a month :-( ) I will try to implement it, and if it works, post it to the net. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |