graham@sce.carleton.ca (Doug Graham) (07/13/90)
I've had some time to play with Minix recently, and I've got a few questions
about it. I'm using 1.5.10, but I'll refer to the book where it doesn't
differ much.
1) A process which is blocked waiting on a pipe will not be woken up if a
signal arrives for it. On line 10591 in the book, a check is made for a pipe,
and the revive on line 10602 (which is now a reply) is only done if the task
was not waiting on a pipe. Is this intentional? If so, why? I moved line
10602 out of the if block, so it is done regardless of whether the process
is waiting on a pipe, and I've had no problems (yet).
2) I notice that O_NONBLOCK has been added, and is implemented for pipes.
Why not extend this to work for tty's as well? The mechanism is all in place,
it just hasn't been done. Somebody (Bruce Evans I think) added an extra
process to the program "term" so that it could take advantage of non-
blocking I/O on pipes, when it would probably have been simpler, and more
generally useful, to add a non-blocking I/O capability to the tty task.
3) A call to "sync" will result in function do_sync (line 12018) being
executed. The first thing this routine does is to mark the superblock
for the root file system as dirty. This guarentees that it will be written
to disk. Why is this done? Why should the superblock *ever* need to be
written during the normal operation of the file system. The only data it
contains is that written there by "mkfs" when the file system was created.
I ask this because I have my root file system on a hard disk with self
parking heads. On an otherwise quiescent system, every 30 seconds, the
program "update" calls sync, which seeks to the root partition, and writes
the superblock. Then 15 seconds later, the drive parks itself. This constant
seeking is quite distracting. (At least it was, until I took out the
offending lines from do_sync)
4) When a buffer is allocated from the front of the LRU list in
"get_block", it is not removed from the list. Instead, it is marked as used
by having it's b_count set to > 0. Now the next time a buffer is allocated,
it must search past all previously allocated blocks before finding a free
one. Why not remove the block from the LRU list in "get_block", and then
re-insert it in "put_block"?
5) In looking at the Minix source code, I have always had the feeling that
there is something quite wrong with the way it is structured. While I was
fixing problem 4, I think I realized what it is. Dr. Tanenbaum uses tasking
as a means to enforce some kind of modularization concept. ie. the kernel
possesses all the low level task information such as the registers contents.
If, for example, MM wants to fiddle with the stack of a process in order to
deliver a signal to it, it must send a message to the "system" task telling
it to do so. The "system" task carries out the request, and then replies
a status, at which point MM continues. But this is really nothing more
than a procedure call, it does nothing to enhance paralellism. All this
message passing stuff only serves to obfuscate the code. The system task
could just as easily be made a passive collection of procedures. As well
as making the code easier to follow, this would also eliminate the message
passing, and context switching overhead.
Getting back to problem 4: I wanted to arrange to remove blocks from
the LRU list when they were allocated. Then when a new block is to be
allocated, no search is necessary; it just takes the first block from the
front of the LRU list. In a properly modular design, this would have
required making changes to only one file: "cache.c". However, for some
reason, the function "buf_pool", which initializes the buffer cache, is
a PRIVATE function in "main.c". As I discovered after a few attempts,
I needed to modify this as well, in order to remove any blocks that cross
DMA boundaries from the LRU list. "buf_pool" should have been a PUBLIC
function in "cache.c", which, along with "get_block", and "put_block",
manipulates the PRIVATE data structures associated with the buffer pool.
*This* is correct modularization, not sticking a random bunch of stuff in
a task, and then sending messages to it.
Now for my final question: are there any real advantages to structuring
an OS as a collection of co-operating tasks as in Minix? I don't see
paralellism as being the answer either; in fact, the structure of Minix
impedes paralellism in a lot cases. For example, FS is a major bottleneck.
If one process is waiting for a sector to be read from a floppy, other
processes wanting to access the winchester, or tty, wait. You can also
say goodbye to all those fancy disk scheduling algorithms. In Minix,
the disk driver only gets a single request at a time, so it's scheduling
job is pretty simple. I think Unix has it right: the kernel should be
a passive entity which carries out requests in the (kernel) context of
the calling process. The Unix sleep/wakeup mechanism seems a bit weird
(How come it's never mentioned in the textbooks alongside semaphores,
monitors, and message passing), but it also seems quite effective.
Note: None of the above should be construed as a flame. I would be quite
interested in hearing any comments, especially about the Minix structure.
Minix is certainly a lot of fun, and I thank Dr. T. for that. I would
like it to become useful as well, and for that, I think it definitely
needs to do swapping. I intend to have a go at this, but I think some
restructuring needs to be done first.
------
Doug.adrie@philica.ica.philips.nl (Adrie Koolen) (07/16/90)
In article <877@sce.carleton.ca> graham@sce.carleton.ca (Doug Graham) writes: >... >If, for example, MM wants to fiddle with the stack of a process in order to >deliver a signal to it, it must send a message to the "system" task telling >it to do so. The "system" task carries out the request, and then replies >a status, at which point MM continues. But this is really nothing more >than a procedure call, it does nothing to enhance paralellism. All this >message passing stuff only serves to obfuscate the code. The system task >could just as easily be made a passive collection of procedures. As well >as making the code easier to follow, this would also eliminate the message >passing, and context switching overhead. >... > Now for my final question: are there any real advantages to structuring >an OS as a collection of co-operating tasks as in Minix? I don't see >paralellism as being the answer either; in fact, the structure of Minix >impedes paralellism in a lot cases. For example, FS is a major bottleneck. >If one process is waiting for a sector to be read from a floppy, other >processes wanting to access the winchester, or tty, wait. You can also >say goodbye to all those fancy disk scheduling algorithms. In Minix, >the disk driver only gets a single request at a time, so it's scheduling >job is pretty simple. I think Unix has it right: the kernel should be >a passive entity which carries out requests in the (kernel) context of >the calling process. The Unix sleep/wakeup mechanism seems a bit weird >(How come it's never mentioned in the textbooks alongside semaphores, >monitors, and message passing), but it also seems quite effective. >------ >Doug. The method of structuring Minix into a bunch of processes reflects the way of thinking of the programmer. The way of assigning policy matters to MM and FS and implementation matters to the kernel eases porting and debugging a lot. The structure of Minix helped me porting it to the SparcStation 1, where the MM and FS contain NO assembly routines and run in the processor's user mode. They also run in separate contexts, so neither the MM nor the FS can access memory of other processes directly. When there's a fault in the MM or FS, e.g. a bus error, it is trapped and reported to the kernel, so that appropriate actions can be taken. The kernel processes run in supervisor mode and can do nasty things like program the hardware (e.g. remap physical memory). The problem with the one-threaded FS is mentioned regularly in this newsgroup and I agree: it has to be fixed. On my SparcStation, I use a multi-windowed TTY driver and I suffer the single-threadedness continuously when in one window, a `make' is started, or another disk- intensive process, like `find' or `tar', and I want to edit a file in another window. The best solution to this problem would be to re-implement the FS as a 'stated' FS which returns to the main FS loop to send or receive messages. This approach requires quite complicated changes in the FS. An easier method would be to create e.g. 3 FS threads. A FS, which waits in the main loop for a message is said to be free. User processes send messages to the FS, not knowing that there are 3 instances of the FS. A free FS is selected, which handles the request. When it sends a message to a task, the task replies to EXACTLY that FS thread. A FS thread cannot be interrupted by another FS thread, only by tasks. This feature can be used to garantee the consistency of the FS tables. This way, several processes can use the FS to access different tasks concurrently. Adrie Koolen (adrie@ica.philips.nl), Philips Innovation Centre Aachen
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (07/16/90)
I think the aim of all this has nothing to do with parallel computing. It has to do with readability of code (note that I do not say it IS readable as it is, but it WAS the intetion). On a PC, there is quite a trivial reason doing it so: The address space of the kernel is to small to make all these procedures fit in it. To speek for my own, I am VERY sure that all the MM stuff will go to the Kernel one day. On an ATARI, much of the real work MM does has been moved to the system task (look at the number of clock ticks each process consumes). The kernel-MM-interface is horrible regarding signals (with this point, you are right). It will even be much worse when MINIX is moved to a 386 etc platform with paging. It is nearly killing to send a message to MM on every page fault. The FS, on the other side, is nearly a self-contained entity that may remain a separate process. This has nothing to do with the fact it is realyy single-tasking - this will change in the future. C.v.W.
wayne@csri.toronto.edu (Wayne Hayes) (07/17/90)
In article <628@philica.ica.philips.nl> adrie@beitel.ica.philips.nl (Adrie Koolen) writes: >The problem with the one-threaded FS is mentioned regularly in this >newsgroup and I agree: it has to be fixed. On my SparcStation, I use a >multi-windowed TTY driver and I suffer the single-threadedness >continuously when in one window, a `make' is started, or another disk- >intensive process, like `find' or `tar', and I want to edit a file in >another window. Err, how did you get Minix to perform in windows? Is Minix running as the actual OS on your Sparc, or just a user process faking an OS on top of the real SparcUnix OS? If it's the real OS, HOW THE HECK did you get it to run windows??? Is this something we other Minixer's might be interested in? "MXwindows" :-) ? -- "The number of programs that can be done with the HST has always greatly exceeded the time available for their execution, and this remains true even with the telescope in its current state." -- HST Science Working Group and User's Commitee Report, 1990 June 29. Wayne Hayes INTERNET: wayne@csri.utoronto.ca CompuServe: 72401,3525
graham@sce.carleton.ca (Doug Graham) (07/17/90)
In article <24719@nigel.udel.EDU>, HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: > I think the aim of all this has nothing to do with parallel computing. > It has to do with readability of code (note that I do not say it IS > readable as it is, but it WAS the intetion). My point is though, that splitting a program into tasks should not be done for readability, because invariably, it has the opposite effect. Tasking should only be used to deal with asynchronous events, although even then, I'm not convinced they are the best approach because things get complicated when abnormal conditions such as signals must be dealt with. Aside from the readability aspect, splitting an inherently sequential algorithm into tasks is just begging for deadlock as can be seen in earlier versions of Minix, and as can be seen in the ugly hacks to avoid it in the current version. For example, it used to be, that when FS needed to generate a SIGPIPE, it would send a message to MM. The problem was, that MM could have been simultaneously trying to send a message to FS via. tell_fs. Deadlock! Actually it was even worse than that, because in the course of handling the SIGPIPE, MM would send an UNPAUSE message to FS. But FS was still waiting for a reply to the original request. In the current Minix, FS sends the SIGPIPE message to to SYSTASK, which passes it to MM after checking that MM is actually waiting for it, and replies immediately to FS, so FS can get the UNPAUSE later. This is all far too complicated, and it would all go away if MM and FS were not separate tasks. > On a PC, there is quite a trivial reason doing it so: > The address space of the kernel is to small to make all these procedures > fit in it. Actually, except for the buffer cache, current Minix will fit quite nicely into 64K split I&D. Note that when you get rid of all the extra tasks, you can dump a fair chunk of duplicated code (e.g. printk only needs to be loaded once, not thrice), and some code will go away because communication is via procedure call, not message passing. There is other code than could be tossed as well. The buffer cache need not reside in directly addressable space; the buffer structures, instead of containing the data itself, could contain a physical address pointer to the data. > To speek for my own, I am VERY sure that all the MM stuff will go to the > Kernel one day. On an ATARI, much of the real work MM does has been moved > to the system task (look at the number of clock ticks each process consumes). > The kernel-MM-interface is horrible regarding signals (with this point, you > are right). It will even be much worse when MINIX is moved to a 386 etc > platform with paging. It is nearly killing to send a message to MM on every > page fault. I wan't aware that there were any plans to implement virtual memory. I thought Dr. T. has decided that VM is obsolete because RAM is so cheap and plentiful. (I must be in the dark ages with my 640K XT). Is there ongoing work in this area? > The FS, on the other side, is nearly a self-contained entity that may remain > a separate process. This has nothing to do with the fact it is realyy > single-tasking - this will change in the future. Yes, hopefully the single threaded FS will go away in the future, but, although it would be possible implement a multithreaded FS in the same manner as a read on a TTY is done now (with SUSPEND's and REVIVE's), I think it would be madness to attempt this. Consider how many potential places there are to block, when you do an open for example. You may have to read many inodes, and many directories. At each blocking point, you would have to save the state of the currently executing system call, so that another could be started or resumed. In Unix, this is easy, you just call wait, and the state is saved on the kernel stack for the process. In Minix, you'd have to stash the state in the "fproc" structure, and then return to the main processing loop. Considering that the state would likely be spread over multiple nested procedure calls, this could prove to be quite a feat. There is also the problem of synchronizing access to global data structures. Consider what happens when process P1 requests block B from the disk, and blocks waiting for it. Now process P2 runs and requests the same block. Presumably, the file system would notice that this block was in transit, and block P2 somewhere. When the disk block arrives, both processes should be awakened. In Unix, this is easy. In Minix it's not. You'd probably wind up implementing something like the Unix wakeup primitive. The reason I bring all this up, is because somewhere in his book, Dr. T. states that message passing is the more modern (and by implication better) way of structuring an OS. As you can tell, I am far from convinced of this. I don't necessarily think that Unix has all the right answers either, but it seems that many of it's solutions are more satisfactory than those of Minix, and perhaps Minix hackers ought to be looking in that direction for ideas. > C.v.W. ---- Doug.
adrie@philica.ica.philips.nl (Adrie Koolen) (07/17/90)
In article <1990Jul16.235145.25212@jarvis.csri.toronto.edu> wayne@csri.toronto.edu (Wayne Hayes) writes: >In article <628@philica.ica.philips.nl> adrie@beitel.ica.philips.nl (Adrie Koolen) writes: >>The problem with the one-threaded FS is mentioned regularly in this >>newsgroup and I agree: it has to be fixed. On my SparcStation, I use a >>multi-windowed TTY driver and I suffer the single-threadedness >>continuously when in one window, a `make' is started, or another disk- >>intensive process, like `find' or `tar', and I want to edit a file in >>another window. > >Err, how did you get Minix to perform in windows? Is Minix running as >the actual OS on your Sparc, or just a user process faking an OS on top >of the real SparcUnix OS? If it's the real OS, HOW THE HECK did you get >it to run windows??? Is this something we other Minixer's might be >interested in? "MXwindows" :-) ? Minix for the SparcStation 1 will be a completely autonomous operating system. It doesn't use the original Sun Unix, SunOS. Only the Minix boot-image has to have a SunOS header in order to be able to let the monitor load the image. Because Minix for the Sparc is an independant O.S., I had to (re)write all the device drivers. Because the SparcStation has a large (1152 * 900) bit-mapped display, I used the Atari-ST TTY driver as a basis. The screen is too large to be used for just a single window, so I rewrote spvdu.c (and a few changes in tty.c) to split the screen into more windows. There are three fixed sized windows now and there's no way to change the position of the windows other than recompilation of the driver. The TIOCGETWINSZ ioctl is used to inspect the window size, so that elvis, more an man work correctly. A special key is used to select the window to which keyboard input is directed. It would not be too difficult to dynamically create, move and resize windows with special keys and/or the mouse, but I know that I would constantly add more features and I've no time to do that. Maybe, that somebody will port the X Window System to Minix for the SparcStation somewhere in the future. It shouldn't be that difficult; Minix only lacks a real ethernet driver and the socket mechanism. Rewriting the TTY task of Minix-ST to support multiple (ASCII) windows is quite easy. I'm not sure whether the display is large enough (640 * 400) to make multiple windows workable. On the SparcStation, I can use the 8 and 16 pixel fonts, but I also added a font of 12 pixels high, which I use mostly. I've always wondered why the Atari guys didn't add an extra intermediate sized font, because 8 pixels is to small, 16 is quite big and with 12 pixels, you can make a good and readable font and get 33 lines on the screen! Adrie Koolen (adrie@ica.philips.nl) Philips Innovation Centre Aachen
graham@sce.carleton.ca (Doug Graham) (07/18/90)
In article <628@philica.ica.philips.nl>, adrie@beitel.ica.philips.nl (Adrie Koolen) writes: > The method of structuring Minix into a bunch of processes reflects the way > of thinking of the programmer. This is almost a tautology no? > The way of assigning policy matters to MM > and FS and implementation matters to the kernel eases porting and debugging > a lot. I don't disagree with this. But I think this statement would still be true if MM, FS, and the "system" task were not implemented as tasks, but rather software subsystems in the usual sense. Note that I'm not advocating mixing the high level software with the low level software into one big jumble. > The structure of Minix helped me porting it to the SparcStation 1, > where the MM and FS contain NO assembly routines and run in the processor's > user mode. They also run in separate contexts, so neither the MM nor the FS > can access memory of other processes directly. When there's a fault in the > MM or FS, e.g. a bus error, it is trapped and reported to the kernel, so > that appropriate actions can be taken. The kernel processes run in > supervisor mode and can do nasty things like program the hardware (e.g. > remap physical memory). What might those appropriate actions be? In the Minix that I have, MM, and, to a lesser extent, FS, are intricately involved in exception handling. If it was one of those tasks that incurred the exception, what then? Even if there is some advantage to having a good part of the O/S run in user mode, could the switch to supervisor mode not then be done via a normal trap, rather than a message pass, and context switch? One of the things that bothers me about Minix, are the time wasting checks scattered about in the code that do something like: if (source != MM_PROC_NR) return (ERROR) /* Only MM may make this call */ This is necessary, because, as set up now, the different peices of the O/S communicate between themselves using the same message passing mechanism that the user processes use to communicate with the O/S. There is nothing preventing a user process from sending a message to the SYSTASK for example. IMO, even if the O/S is implemented internally using message passing, this should not be visible to the user, i.e. he/she should not have to name a destination task when making a system call. If Minix wants to internally vector the call off to a task, it should have an internal table telling it which task to pass the call off to. This solves the problem above, and also, more importantly, makes it possible to change the kernel implementation without having to change the libraries, and recompile all the user programs. > An easier method would be to create e.g. 3 FS threads. A FS, which > waits in the main loop for a message is said to be free. User processes > send messages to the FS, not knowing that there are 3 instances of the FS. > A free FS is selected, which handles the request. When it sends a message > to a task, the task replies to EXACTLY that FS thread. A FS thread cannot > be interrupted by another FS thread, only by tasks. This feature can be > used to garantee the consistency of the FS tables. This way, several > processes can use the FS to access different tasks concurrently. I implemented almost exactly this for a real time system I was working on. The only diffence was that the determination of which file server task to use, was done at open time, not on every call as you suggest. This had more to do with the limitations of the RT executive I was using than anything else. Anyway, I think this approach makes some sense for a distributed system, but for a uniprocessor system such as Minix (am I being too short-sighted here?) it is just unecessary overhead and complexity. Note that your solution does not solve the disk arm scheduling problem. As long as there is only a single winchester task, it will get only one request at a time. Or do you plan to clone these as well? Note as well, that preventing one FS thread from preempting another, is not enough to guarentee the consistency of the FS data structures. A thread would still have to lock critical data before possibly blocking on disk I/O. Actually, having got as far as having multiple FS threads, you're now faced with exactly the same mutual exclusion problems that standard Unix has. You could consider the FS thread as being the equivalent of the Unix kernel context for the user process. So how do do this locking of data structures in Minix? Where does the FS thread wait until the lock has been released? ---- Doug.
peter@ficc.ferranti.com (Peter da Silva) (07/18/90)
> > Now for my final question: are there any real advantages to structuring > >an OS as a collection of co-operating tasks as in Minix? As in MINIX? I don't know. Other operating systems that use multiple co-operating tasks in the kernel use asynchronous message queues to communicate between those tasks rather than a synchronous rendezvous. This reduces the opportunities for deadlock as well as making it easier to service simultaneous requests (for example, the FS can make a request from the disk driver on behalf of one task, and then immediately go on to service the next task. When the disk driver replies to the first message it can forward the data to the original task, or whatever. The disk driver can similarly queue and prioritise requests. If the FS had to wait for the driver before continuing this wouldn't be possible). -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
peter@ficc.ferranti.com (Peter da Silva) (07/18/90)
In article <630@philica.ica.philips.nl> adrie@beitel.ica.philips.nl (Adrie Koolen) writes: > Maybe, that > somebody will port the X Window System to Minix for the SparcStation > somewhere in the future. It shouldn't be that difficult; Minix only > lacks a real ethernet driver and the socket mechanism. From the "small is beautiful" point of view of MINIX the MGR window system might be a better idea. It's a much smaller system and should be easier to port to the relatively small systems MINIX runs on. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
bjl@baldr.pttrnl.nl (Ben Lippolt) (07/19/90)
peter@ficc.ferranti.com (Peter da Silva) writes: >From the "small is beautiful" point of view of MINIX the MGR window system >might be a better idea. It's a much smaller system and should be easier >to port to the relatively small systems MINIX runs on. When MGR was first released (to comp.sources.unix I think) there was some discussion in comp.os.minix on the possibility of porting it to minix. I haven't heard anything from it since. Has it been done? Are there diffs to the original MGR-posting available (preferably for an ST)? Ben J. Lippolt --- PTT Research, Dr. Neher Laboratories [ E-mail : BJ_Lippolt@pttrnl.nl ] P.O. Box 421, 2260 AK Leidschendam, [ BITnet : LIPPOLT@HLSDNL5 ] The Netherlands. Tel: +31 70 3325439 [ UUCP : hp4nl!dnlunx!bjl ]
adrie@philica.ica.philips.nl (Adrie Koolen) (07/23/90)
Newsgroups: comp.os.minix Subject: Re: Assorted questions Summary: Expires: References: <628@philica.ica.philips.nl> <879@sce.carleton.ca> Sender: Reply-To: adrie@beitel.ica.philips.nl (Adrie Koolen) Followup-To: Distribution: Organization: Philips TDS, Innovation Centre Aachen Keywords: In article <879@sce.carleton.ca> graham@sce.carleton.ca (Doug Graham) writes: >In article <628@philica.ica.philips.nl>, adrie@beitel.ica.philips.nl (Adrie Koolen) writes: >> The way of assigning policy matters to MM >> and FS and implementation matters to the kernel eases porting and debugging >> a lot. > >I don't disagree with this. But I think this statement would still be >true if MM, FS, and the "system" task were not implemented as tasks, >but rather software subsystems in the usual sense. Note that I'm not >advocating mixing the high level software with the low level software >into one big jumble. You've got a big problem here. You can SAY, that the way of structuring an O.S. results in an O.S., that is at least as readable and understandable as Minix, is more portable and runs faster than Minix, but in order to prove that, you have to show that some O.S. has these properties or write such an O.S. yourself. I don't mean that everyone who makes a comment on some deficiency has first to solve it before saying something, but you've got to make your statements plausible. When you've ever dived in Unix sources, you can see, that they are quite unreadable. My SCSI task for Minix on the SparcStation consists of two files, one header and one C file, with a total length of 30KB. The SCSI driver for SunOS 4.0.3c is contained in 37 files, scaterred over 6 directories for a total of more than 350KB. I know that there are reasons for this and that the SunOS driver is faster and more versatile than Minix's, but writing or reading such a SunOS driver requires you to be more than a `normal' expert. Give me one good reason why Minix, after it is structured the way Unix is, won't go the same way of size, complexity and unreadability as Unix has followed since 1970?! You say, that you're not promoting to throw the entire O.S. into one big jumble. Can you clarify that? When I look at Unix, that's just what's going to happen when you structure Minix that way! >> They also run in separate contexts, so neither the MM nor the FS >> can access memory of other processes directly. When there's a fault in the >> MM or FS, e.g. a bus error, it is trapped and reported to the kernel, so >> that appropriate actions can be taken. The kernel processes run in >> supervisor mode and can do nasty things like program the hardware (e.g. >> remap physical memory). > >What might those appropriate actions be? In the Minix that I have, >MM, and, to a lesser extent, FS, are intricately involved in exception >handling. If it was one of those tasks that incurred the exception, >what then? Even if there is some advantage to having a good part of >the O/S run in user mode, ... I don't really feel like discussing the advantages of running as much of the system as possible in user mode. I guess, that you're deliberately provoking me. >One of the things that bothers me about Minix, are the time wasting checks >scattered about in the code that do something like: > > if (source != MM_PROC_NR) return (ERROR) /* Only MM may make this call */ > >This is necessary, because, as set up now, the different peices of the >O/S communicate between themselves using the same message passing mechanism >that the user processes use to communicate with the O/S. There is nothing >preventing a user process from sending a message to the SYSTASK for >example. Except for ONE test in mini_send(). >IMO, even if the O/S is implemented internally using message >passing, this should not be visible to the user, i.e. he/she should not have >to name a destination task when making a system call. If Minix wants to >internally vector the call off to a task, it should have an internal >table telling it which task to pass the call off to. This solves the >problem above, and also, more importantly, makes it possible to change >the kernel implementation without having to change the libraries, and >recompile all the user programs. You've got a point there, but it doesn't happen to much that you've got to recompile everything. >Note that your solution does not solve the disk arm scheduling >problem. As long as there is only a single winchester task, it will get >only one request at a time. Or do you plan to clone these as well? With multiple FS threads, a single task could receive multiple messages in principle. (There are still problems to be solved but in principle, it can be done. >Note as well, that preventing one FS thread from preempting another, >is not enough to guarentee the consistency of the FS data structures. I know, but it certainly helps! >A thread would still have to lock critical data before possibly blocking >on disk I/O. Actually, having got as far as having multiple FS threads, >you're now faced with exactly the same mutual exclusion problems that >standard Unix has. You could consider the FS thread as being the equivalent >of the Unix kernel context for the user process. So how do do this >locking of data structures in Minix? Where does the FS thread wait >until the lock has been released? Good question! I don't have all the answers right now. Adrie Koolen (adrie@ica.philips.nl) Philips Innovation Centre Aachen
peter@ficc.ferranti.com (Peter da Silva) (07/24/90)
In article <878@sce.carleton.ca> graham@sce.carleton.ca (Doug Graham) writes: > For example, it used to be, that when FS > needed to generate a SIGPIPE, it would send a message to MM. The problem > was, that MM could have been simultaneously trying to send a message > to FS via. tell_fs. Deadlock! This isn't caused by multi-tasking in the kernel. It's caused by the kernel IPC being implemented using rendezvous rather than message queues. > This is all far too complicated, and it would all go away if MM and > FS were not separate tasks. Or if messages could be queued. > Note that when you get rid of all the extra tasks, you > can dump a fair chunk of duplicated code (e.g. printk only needs to be > loaded once, not thrice), Shared libraries would solve that problem. And you don't need sophisticated memory management hardware to support shared libraries... AmigaOS does it and a stock amiga has NO MMU. MINIX is deliberately designed to be a teaching system, and it's not a good system to use as a paradigm% for all message-passing operating systems. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com> % I'm using paradigm in its original sense, of an ideal model. --
peter@ficc.ferranti.com (Peter da Silva) (07/24/90)
In article <636@philica.ica.philips.nl> adrie@beitel.ica.philips.nl (Adrie Koolen) writes: > My SCSI task for Minix on the SparcStation consists of two > files, one header and one C file, with a total length of 30KB. The SCSI > driver for SunOS 4.0.3c is contained in 37 files, scaterred over 6 > directories for a total of more than 350KB. And this is one of the reasons I prefer System V to BSD. Try three files: a header file, a Driver file and a space.c file (which contains config parameters). Not that I don't prefer a message-passing kernel, but you don't have to go that route to get good modularity. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>